Definition og grundidé

Site-to-site VPN er en opsætning, hvor to netværk (”sites”) etablerer en krypteret forbindelse over et andet net, typisk internettet. Formålet er, at enheder i det ene net kan kommunikere med enheder i det andet net, som om de var forbundet internt—men uden at private netværksdata sendes ukrypteret.

I praksis fungerer det ofte ved, at en gateway (fx en virksomhedsrouter eller firewall) på hvert site opretter tunnelen og håndterer kryptering/dekryptering samt videresendelse af trafikken.

Et simpelt modeloverblik: tunnel, kryptering og routing

Tænk site-to-site VPN som tre lag i drift:

  1. Etablering af forbindelsen: Gatewayne forhandler parametre for tunnelen. Hvilke præcise valg der bruges (fx protokoller og krypteringsopsætning) afhænger af leverandør og teknologi.
  2. Krypteret tunnel: Når tunnelen er oppe, sendes trafik mellem nettene gennem en krypteret ”transport” mellem gatewayne. Det betyder, at selve data ikke sendes som klar tekst over det underliggende net.
  3. Routing/forwarding efter regler: Kun trafikken, der matcher de konfigurerede net (typisk IP-subnet/prefixer), videresendes gennem tunnelen. Hvis du vælger for brede eller for snævre net, kan du enten få uønsket trafik i tunnelen eller manglende adgang.

Et vigtigt praktisk punkt er, at site-to-site VPN ikke automatisk ”tillader alt”. Det er typisk kombinationen af VPN-konfiguration (hvilke net der går via tunnelen) og firewallregler (hvilken trafik der må passere) der bestemmer resultatet.

Hvad der typisk indgår i en site-to-site opsætning

Selvom konkrete menuer varierer, er disse elementer ofte centrale:

  • To endepunkter: Hver side har en gateway med en offentlig/tilgængelig adresse (eller et kendt adgangs-/transportsetup).
  • Identifikation og sikkerhed: Der skal være en metode til at identificere endepunkterne og beskytte forbindelsen mod uvedkommende.
  • Hvilke net der skal forbindes: Du definerer typisk lokale og fjerne subnet, så gatewayne ved, hvilken trafik der skal i tunnelen.
  • DHCP/DNS-forhold: Site-to-site VPN påvirker ofte, hvordan DNS-forespørgsler og navneopslag skal håndteres. Afhængigt af opsætning kan du være nødt til at sikre, at klienter på begge sider kan finde hinandens navne.
  • Firewallpolicy: Selve tunnelen kan være oppe, men hvis firewallreglerne ikke matcher, kan trafikken stadig blive droppet.

Forskelle og typiske grænser: site-to-site vs. remote access

Det er let at forveksle site-to-site VPN med fjernadgang (remote access VPN). Forskellen handler især om ”hvem” og ”hvad” der oprettes adgang for:

  • Site-to-site: én forbindelse mellem to netværk/gateways. Fokus er netværks-til-netværks kommunikation.
  • Remote access: typisk adgang for individuelle brugere/klienter til et virksomhedsnet.

En anden praktisk begrænsning, der ofte overrasker: IP-adresseplan. Hvis begge sites bruger samme private IP-subnet (fx begge har 192.168.10.0/24), kan routing gennem tunnelen blive problematisk, fordi systemerne ikke kan skelne nettene entydigt. I sådanne tilfælde skal du enten ændre adresseplan eller arbejde med en løsning, der håndterer overlap (detaljerne afhænger af din VPN- og netværksløsning).

Undtagelser og usikkerheder du bør afklare før du implementerer

Da der ikke er ét enkelt universelt setup, bør du betragte følgende som punkter, der kan variere fra løsning til løsning:

  • Valg af VPN-type/protokol: Nogle implementeringer bruger forskellige protokoller og forhandlingsmekanismer. Det påvirker, hvordan du konfigurerer og fejlsøger.
  • Kompatibilitet mellem udstyr: To forskellige gateway-producenter kan kræve, at du matcher konfigurationer (fx krypteringsvalg og forhandlingsparametre). Generelle begreber kan være de samme, men detaljerne kan ikke altid kopieres direkte.
  • Transport-nettet og NAT: Hvis der er NAT, firewalls eller andre mellemlag mellem gateways, kan det kræve ekstra opmærksomhed i forhold til portvalg og adgang.

Hvis du kun har overordnet information, er en god tommelfinger at planlægge med antagelsen om, at en opsætning kan kræve tilpasninger for at blive kompatibel. Af hensyn til korrekthed er det fornuftigt at kontrollere dokumentation for dine konkrete gateways eller teknologivalg.

Praktisk fremgangsmåde: sådan kan du kontrollere, om opsætningen virker

Du kan bruge en struktureret tjekliste, uden at det bliver en afhængighed af ”hemmelige” instillinger:

  1. Afklar adresseplan og hvilke net der skal forbindes: Notér lokale og fjern subnet/prefixer, så du kan forklare, hvad der er meningen.
  2. Sørg for at routing og firewallregler matcher: Tunnelen kan være etableret, men trafik kræver stadig tilladelse på tværs af relevante lag.
  3. Start med begrænset trafik: Aktivér eller test med et lille sæt protokoller/hoste for at reducere kompleksitet.
  4. Test navneopslag og applikationsadfærd: Ikke kun ping/grundforbindelse—tjek også DNS (hvis relevant) og de protokoller, applikationer bruger.
  5. Hold øje med logning og fejl: Når noget ikke virker, er logfiler ofte vigtigere end gæt. Kig efter mønstre som ”tunnelen etableres ikke” versus ”tunnelen er oppe men trafik droppes”.

Hvis du systematisk adskiller ”tunnel-etablering” fra ”trafikpolicy”, kan du typisk finde fejlkilden hurtigere.

Hvad du skal have styr på, før du kan sammenligne løsninger

Når du vurderer forskellige site-to-site VPN-tilgange (interntudstyr, hosted gateways eller managed setup), så sammenlign ikke kun på markedsføring, men på de konkrete kontrollpunkter:

  • Hvilken trafik er inkluderet (hvilke net/prefixer går via tunnelen)
  • Hvordan endpoint-id og sikkerhed forhandles
  • Hvordan NAT/mellemlag håndteres
  • Hvilken logning/fejlsøgning der er tilgængelig
  • Hvordan DNS og adgang til services planlægges

På den måde får du et realistisk billede af, hvad der skal konfigureres, og hvor fejl typisk opstår.