Definition og grundidé

Site-to-site VPN er en opsætning, hvor to netværk (typisk “site” eller lokationer) forbindes via en sikker tunnel over et usikkert mellemliggende net. Formålet er at beskytte data i transit ved at kapsle trafikken og kryptere den, så den kan flyde som om den var på samme interne net.

I praksis består en implementering ofte af mindst to VPN-endepunkter (fx gatewaye), der forhandler en sikker forbindelse og derefter sender netværkstrafik gennem tunnelen efter de regler, du konfigurerer for routing og adgang.

Eenvoudig model: hvem gør hvad

Tænk site-to-site VPN som tre sammenhængende dele:

  1. Tunnelforhandling og nøgler: Endepunkterne etablerer en sikker kanal ved at blive enige om beskyttelsesmetode og nøgler.
  2. Kryptering og integritet: Når tunnelen er oppe, beskyttes pakker, så uønskede ændringer opdages, og fortrolighed understøttes.
  3. Trafikstyring (routing og politikker): Hvilke interne net (subnet) der skal sendes i tunnelen, bestemmes af adgangs- og rutningsregler.

Hvis én af disse dele er forkert, kan du få symptomer som: tunnelen etableres ikke, trafikken “forsvinder” (fordi den ikke matcher regler), eller dele af forbindelsen fungerer men andre prototyper fejler.

Underdele du skal få på plads

Adressering og net-overlap

Et hyppigt implementeringsproblem er overlappende IP-adresser mellem lokationerne. Hvis begge sites bruger samme interne adresser (fx 192.168.1.0/24), bliver det uklart, hvor trafikken skal hen. Best practice er derfor at planlægge, så subnettet i hvert site er entydigt, eller at definere tydelige translationer, hvis din løsning tillader det.

Routing: vælg konsekvent strategi

Du skal tage stilling til, hvordan trafik bliver valgt til tunnelen. To typiske mønstre (navne kan variere mellem leverandører) er:

  • Policy-/segmentbaseret: Kun bestemte subnet og protokoller sendes i tunnelen.
  • “Alt-i-tunnel” som princip: Større del af trafikken ledes gennem tunnelen.

Valget påvirker både sikkerhed og fejlsøgning. Segmentbaseret routing gør ofte kontrol lettere, mens en mere “altomfattende” model kan skabe uventede afhængigheder, hvis du ikke har styr på adgangsregler.

Firewallregler og adgangskontrol

Selv når tunnelen findes, er det ikke ensbetydende med fri adgang. Konfigurer derfor regler på begge sider, så kun den nødvendige trafik er tilladt. Tænk især på:

  • hvilke porte/protokoller der er nødvendige,
  • om der kræves spejlede regler begge veje,
  • og hvordan logning skal bruges til fejlfinding.

Undtagelser og forskelle, du bør kende

Site-to-site vs. “remote access”

Site-to-site handler primært om netværk mellem to lokationer, typisk med gatewaye. Remote access handler om brugere eller enheder. Selvom teknologien kan ligne hinanden, betyder forskelle i klienter, adressering og routing, at bedste praksis ikke kan kopieres 1:1.

Fuld tunnel vs delt tunnel (konsekvenser)

Fuld tunnel kan give mere ensartet sikkerhedspraksis, men kræver at du også har styr på, hvordan egress (trafik ud til internettet) håndteres. Delt tunnel kan være mere fleksibel, men øger kompleksiteten, fordi noget trafik går uden om tunnelen og derfor kan kræve ekstra politikker og monitorering.

NAT og kildelokationsproblemer

Hvis der bruges NAT i eller omkring site-løsningen, kan du få fejl som asymmetrisk routing (svaret finder ikke tilbage til den forventede sti). Derfor er det en god praksis at designe med “hvem ændrer adresser hvornår?” i tankerne og at validere, at svartrafik følger samme mønster.

Praktisk use: kontrolpunkter før og under drift

Du kan gøre implementeringen mere forudsigelig ved at teste i en rækkefølge, der adskiller sikkerheds- og trafikproblemer:

  1. Valider tunnelforhandling: Sikre at endepunkterne kan blive enige om de relevante sikkerhedsparametre.
  2. Valider at de rigtige subnet matcher: Tjek at den trafik du forventer, faktisk falder inden for de regler, der skal sende den i tunnelen.
  3. Valider routingvej og svarvej: Bekræft at trafik og respons følger samme logiske sti.
  4. Test protokoller gradvist: Start med simple tests (fx ping/ICMP hvor det er relevant i dit miljø) og udvid til de egentlige applikationer.
  5. Overvåg og log systematisk: Brug log og statistik til at afgøre om fejl skyldes forhandling, policy/routing eller applikationslag.

Begræns samtidig antallet af ændringer ad gangen. Hvis du foretager mange justeringer i én omgang, bliver det svært at afgøre, hvilken beslutning der påvirkede udfaldet.

Grænser og hvad der kan ændre svaret

Bedste praksis afhænger af dine rammer: nettopologi, adresseplan, om der er NAT, hvilke applikationer der skal bruge tunnelen, og hvor kritisk oppetid er. Derudover kan konkrete konfigurationsmuligheder være leverandørspecifikke (fx hvordan politikker eller segmentvalg udtrykkes).

Hvis du oplever vedvarende problemer, kan det være nødvendigt at revidere designet—ikke kun “tune” parametre. Særligt bør du se på adresseringsoverlap, routinglogik og firewall-politikker, fordi de ofte er de mest direkte årsager til at site-to-site VPN ikke fungerer som forventet.