Hvad er en site-to-site VPN, og hvad skal den bruges til?

En site-to-site VPN er en krypteret forbindelse mellem to netværk (fx et kontornet og et filialnet). Formålet er, at udvalgte tjenester og ressourcer i det ene net skal kunne nås fra det andet, typisk via private IP-adresser, som om nettene var forbundet internt.

Det er vigtigt at skelne site-to-site fra fjernadgang (remote access). Ved fjernadgang forbindes individuelle enheder (laptops/mobiler) til et net via en bruger- eller enhedsorienteret VPN. Ved site-to-site er logikken i stedet netværk-til-netværk.

Eenvoudigt model: hvor trafikken krypteres, og hvem bestemmer adgang

Tænk på en site-to-site VPN som tre samspillende dele:

  1. VPN-endepunkter: Udstyret i hvert net (ofte routere eller firewalls) etablerer forbindelsen og håndterer kryptering/dekryptering.
  2. Tunnelling: Trafik fra de valgte net sendes ind i en “tunnel” over det underliggende internet.
  3. Adgangskontrol i nettene: Selv når trafikken kører i krypteret tunnel, skal de relevante firewallregler og routingregler på begge sider stadig tillade den ønskede kommunikation.

Praktisk betyder det, at du både skal få VPN-forbindelsen op at køre og sikre, at netværkenes egne regler ikke stopper trafikken. VPN’en “flytter” ikke automatisk sikkerhedsmæssige beslutninger—den transporterer bare trafikken krypteret.

Hvilke dele skal du typisk konfigurere?

De konkrete menuer varierer mellem leverandører, men opsætningen følger ofte samme mønster. Når du forbereder dig, kan du bruge følgende kontrolpunkter:

1) Netværksplan og IP-adresser

Start med at afklare hvilke undernet der skal kunne nå hinanden. Notér:

  • Hvilke interne net (LAN-subnet) der skal indgå i VPN’et.
  • Om der findes overlappende IP-adresser (samme IP-range i begge sites). Overlap kan give routing- og navneløsningsproblemer.

Hvis du har overlap, skal du normalt enten om-adressere (bedst på sigt) eller ændre designet, så de net ikke “kolliderer”.

2) Routing: hvordan ved nettene, hvor trafikken skal hen?

Når VPN’en er etableret, skal den trafikken, der skal gå mellem nettene, have en rute hen til VPN-endepunktet. Det kan ske via statiske ruter, dynamisk routing (hvis I vælger det), eller en kombination.

Minimalt set skal du sikre, at:

  • Trafik fra hver sides relevante subnet faktisk sendes mod VPN-tunnellen.
  • Returntrafik også har den korrekte vej tilbage.

3) Autentificering og kryptering

VPN’en kræver en form for autentificering mellem endepunkterne og et sæt krypteringsparametre. Hvilke muligheder du har, afhænger af udstyret, men du bør kende disse principper:

  • Begge ender skal matche hinanden på de centrale VPN-parametre.
  • Jo mere restriktive og velvalgte indstillinger, jo bedre—men sørg for kompatibilitet og forudsigelig drift.

4) Firewallregler på begge sider

Et klassisk fejlspor er, at VPN-tunnellen er oppe, men trafikken stoppes af firewall.

Sørg derfor for, at du kan dokumentere (og teste):

  • Hvilke porte/protokoller der må tilgås på fjernnettet.
  • Om reglerne er baseret på undernet, brugere, eller “tunnel-interface”.
  • At tilladelse også gives i den relevante retning og ikke kun én vej.

5) DNS og navneløsning (hvis nødvendigt)

Hvis brugere eller systemer bruger hostnavne frem for IP-adresser, skal du sikre, at DNS fungerer på tværs. Det kan betyde, at I enten:

  • bruger samme DNS-infrastruktur, eller
  • konfigurerer DNS-foroverførsel/videreformidling,
  • eller sikrer lokale navn/opslag.

Forskelle og begrænsninger: når site-to-site ikke er nok

Der er flere situationer, hvor du bør justere forventningerne eller vælge et andet design.

Overlap i IP-ranges

Som nævnt kan overlappende subnet gøre det svært at skelne trafikken. Det er ofte den mest praktiske grund til, at et VPN “virker” delvist og alligevel føles som om det er brudt.

Tidskritisk trafik og performance

VPN introducerer overhead (kryptering/dekryptering og eventuelt ekstra behandling). Hvis I forventer høj gennemstrømning eller meget lav latenstid, kan det kræve ekstra kapacitet eller tuning. Planlæg derfor ikke ud fra “100% af linjens hastighed”.

NAT og asimmetrisk routing

Hvis der er NAT i vejen flere steder, kan returtrafik blive asymmetrisk. Det kan give “stoppede forbindelser”, selv når regler ser rigtige ud.

Som tommelfingerregel: vær opmærksom på, hvordan kilde- og destinationsadresser håndteres, og om VPN-endepunkterne kan se og rout’e returntrafikken korrekt.

Intet “automatisk” failover

Nogle setup giver mulighed for redundans, men det er ikke givet. Hvis I har krav om høj tilgængelighed, bør I planlægge failover/logik og teste, at forbindelsen faktisk skifter på den måde, I forventer.

Praktisk brug: sådan kan du tjekke, om det virker

Du kan reducere risikoen for fejl ved at teste i et kontrolleret, trinvis mønster.

  1. Bekræft basal reachability Start med at verificere, at VPN-endepunkterne kan nå hinanden på det underliggende net/internet (typisk via deres eksterne adresser).

  2. Test én enkel trafikstrøm Vælg en kort og kendt kommunikation: fx ping eller et enkelt TCP-setup fra et enkelt klient-/server-subnet til et enkelt målsubnet.

  3. Tjek ruter og firewall Hvis trafikken ikke går igennem, så undersøg:

  • Har kildesiden en rute til målnettets subnet via VPN?
  • Har målsiden en rute/regel for returntrafik?
  • Stopper firewallregler trafikken på den ene eller begge sider?

  1. Udvid gradvist Når basis fungerer, udvid med flere porte og flere subnet. Det gør det lettere at lokalisere, hvad der ændrede sig, når noget ikke længere fungerer.

  2. Overvåg og dokumentér Saml logik og beslutninger: hvilke subnet indgår, hvilke regler er aktive, og hvilke VPN-parametre er matchet. Ved fejl senere er det ofte dokumentationen, der forkorter fejlsøgningen.

Hvorfor kan to tilsyneladende “ens” opsætninger fejle?

Selv når to sites synes at følge samme principper, kan små forskelle skabe problemer: IP-planen, routingprioriteter, NAT-adfærd, firewallplacering (på selve endepunktet eller bagved), og hvordan navneopløsning håndteres.

Hvis du rammer et problem, er det derfor ofte mest effektivt at systematisere: isolér om fejlen er i VPN-etableringen, i ruter, i firewall, eller i navneløsning—og test derefter ét element ad gangen.

Afsluttende tjekliste før du går live

  • IP-ranges og subnet der indgår i VPN’et er bevidst planlagt og dokumenteret.
  • Routing for både frem- og returntrafik er forstået og testet.
  • Firewallregler tillader den ønskede trafik, uden at åbne unødigt.
  • Autentificering/krypteringsparametre er matchende i begge ender.
  • I har en plan for fejlscenarier (fx hvad sker der ved ændringer eller nedbrud?).
  • I har testet med mindst én realistisk trafikstrøm før fuld udrulning.