Definition og overblik

Site-to-site VPN er en metode til at forbinde to netværk over internettet, så de kan kommunikere, som om der var en beskyttet forbindelse mellem netværkenes porte. Det centrale er, at trafikken lægges i en krypteret tunnel mellem de to endepunkter (typisk routere eller sikkerhedsappliances), hvorefter den bliver sendt videre til destinationer i det andet netværk.

I praksis bruges site-to-site VPN ofte mellem kontorer, datacentre eller filialer, hvor man ønsker et ensartet netværkssetup på tværs af lokationer. Det er “site” i den forstand, at løsningen er koblet til netværksgrænserne, ikke til en enkelt bruger i en app.

Eenvoudig model: tunnel, routing og adgang

Tænk site-to-site VPN som tre lag, der hænger sammen:

  1. Tunnelen: De to endepunkter etablerer en krypteret forbindelse. Først skal de kunne identificere sig over for hinanden og blive enige om parametre for beskyttelsen.

  2. Indkapsling og kryptering: Når der sendes trafik fra netværket ved “site A” mod et netværkssubnet ved “site B”, pakkes trafikken ind og krypteres. Den beskyttede pakke sendes derefter over den offentlige transport.

  3. Routing og policy: Når den krypterede trafik når “site B”, pakkes den ud og sendes videre som almindelig netværkstrafik til det rette subnet. Her spiller ruter, firewallregler og adgangspolitikker en stor rolle for, hvad der faktisk tillades.

Hvis én af disse dele ikke passer (fx forkert rute, uoverensstemmende krypteringsparametre eller for snævre adgangsregler), kan tunnelen måske stå op, men kommunikationen kan stadig fejle.

Hvad der typisk skal være sat op

Site-to-site VPN bliver normalt brugt til at forbinde bestemte netværksområder. Det betyder, at man typisk skal definere:

  • Hvilke lokale netværk/subnets der skal kunne nås på tværs (fx hvilke destinationer der skal rutes gennem tunnelen).
  • Hvilke endepunkter der er VPN’s “porte” (rollerne ligger normalt på netværksenhederne).
  • Krypterings- og forhandlingsparametre så de to ender kan etablere tunnelen.
  • Adgangskontrol (firewall/policy) i hvert site, så den relevante trafik tillades efter udpakning.

Bemærk: den helt konkrete opstilling varierer mellem udbydere og enhedsproducenter, så nogle detaljer kan være navngivet forskelligt. Det vigtige er at forstå sammenhængen mellem tunnel-etablering og den efterfølgende routing/adgang.

Undtagelser, forskelle og begrænsninger

Selv om idéen er enkel, er der klassiske grunde til, at det ikke altid virker “som man forventer”:

  • Tunnelen står, men trafikken gør ikke: Ofte skyldes det rute/policy-mismatch. Hvis destinationer ikke er defineret korrekt, eller hvis firewallregler blokerer på den anden side, opstår der fejl selv med en fungerende tunnel.

  • Asymmetrisk eller uforudsigelig transport: Hvis svarpakker ikke følger samme logiske vej tilbage, kan sessionsproblemer opstå. Den nøjagtige årsag afhænger af netdesign.

  • Protokoller og applikationer: Nogle applikationstyper kan reagere følsomt på ændringer i netværksadfærd (fx indgående forbindelser, NAT-situationer eller særlige portkrav). Her kan man have brug for ekstra justeringer eller en mere specifik arkitektur.

  • Designvalg om subnet og adressering: Hvis begge sites bruger samme interne IP-adresser i forskellige subnet, kan det skabe tvetydighed. Løsninger kræver typisk enten omdesign eller særlige tekniske tiltag.

Disse punkter er ikke udtømmende, men de er typiske steder, hvor “fungerer det?” bliver et spørgsmål om korrekt opsætning frem for selve konceptet.

Hvad du kan teste og kontrollere

For at verificere at site-to-site VPN fungerer efter hensigten, kan du fokusere på kontrolpunkter, der knytter sig direkte til hovedidéen:

  1. Er der en etableret tunnel? Tjek om VPN-endepunkterne faktisk kan forhandle og etablere en krypteret forbindelse.

  2. Rutes trafikken rigtigt? Undersøg om netværket ved site A har ruter/policy, der sender den ønskede destination via VPN, og om det modsatte site afleverer trafikken korrekt til modtageren.

  3. Bliver trafikken tilladt? Kontroller firewallregler/policies efter at tunnelen har leveret trafik ind i det andet netværk.

  4. Virker end-to-end for relevante cases: Test med de konkrete protokoller/flows, I har brug for (fx adgang til bestemte services eller almindelig kommunikation mellem kendte klient/server-IP’er).

Hvis du oplever udfald, så begynd ofte med at adskille “tunnelproblemet” fra “rute/firewall-problemet”. Det giver hurtigere klarhed, fordi site-to-site VPN netop består af både kryptering/tunnel og efterfølgende netværkslevering.