Hvad er en site-to-site VPN, og hvornår giver den mening?

En site-to-site VPN forbinder to geografiske lokationer (eller netværkszoner) via en krypteret kommunikationskanal. Formålet er, at trafik mellem de to netværk kan sendes sikkert på tværs af internettet, uden at brugerne eller applikationerne nødvendigvis skal ændre deres måde at tilgå ressourcer på.

Den bruges typisk, når virksomheden har flere lokationer, der skal udveksle ressourcer som interne tjenester, filsystemer, databaser eller applikationer. I modsætning til fjernadgang for enkeltbrugere kan site-to-site gøre det enkelt at etablere netværkskommunikation mellem to faste endepunkter.

Et simpelt modelbillede: endepunkter, krypteringstunnel og trafikmatch

Tænk på implementeringen som tre sammenhængende dele:

  1. Endepunkter Der skal være en VPN-funktion ved begge sider (fx gatewaye/routere/firewalls), som kan opsætte og vedligeholde en tunnel.

  2. Krypteringstunnel Gateways forhandler en sikkerhedsaftale (via en valgt VPN-løsning) og etablerer en krypteret tunnel. Uanset detaljer handler det overordnet om at få en etableret, stabil og gensidigt accepteret sikkerhed.

  3. Trafikmatch (routing og selectors) Selve tunnelens nytte afhænger af, at den trafik der skal køre, faktisk identificeres og sendes ind i VPN’en. Det kræver normalt korrekt:

  • IP-adressering (hvilke net, der er “interne” på hver side)
  • routing (hvilken næste hop der bruges)
  • VPN-regler/“selectors” (hvilke kildes– og destinationsnet der skal gå igennem tunnelen)

Hvis ét af disse led ikke matcher, kan tunnelen godt være oppe, men trafikken kommer ikke igennem.

Hvilke dele skal du definere før du implementerer?

Før du rører konfigurationen, er det ofte planen der afgør, om projektet bliver glat. Følgende punkter bør afklares og dokumenteres:

  • Netdesign og IP-plan: Undgå overlappende subnets mellem lokationer. Hvis begge sider bruger samme private adresser, bliver trafikmatch og fejlfinding betydeligt sværere.
  • Hvilke net skal kobles: Beslut om du kobler “alle til alle” eller kun specifikke net (fx kun produktionsnet til datanet). Færre net reducerer kompleksitet.
  • Valg af rutning: Afklar om ruter skal være statiske, dynamiske eller en hybrid. Uanset metode skal det være tydeligt, hvilken vej pakkerne tager ved både afsender og modtager.
  • Firewallregler: På begge sider skal firewall tillade både VPN-relateret trafik (forhandlings- og vedligeholdelseskommunikation) og den efterfølgende trafik, der transporteres i tunnelen.
  • NAT/oversættelser: Hvis der findes NAT mellem internet og VPN-gateway, skal du forstå, hvad der oversættes, og hvordan det påvirker tunnelopsætning og trafikmatch.
  • Identitet og nøglehåndtering: Der skal være en aftale om hvordan endepunkterne identificerer hinanden (fx via nøgler/certifikater eller en anden gensidig godkendelse). Små forskelle her er ofte årsag til at tunnelen ikke etableres.

Udførselsfaser: opbyg, etabler, test og valider

En robust proces er at gå fra “kan vi etablere?” til “kan vi sende den rigtige trafik?” i klart afgrænsede trin.

  1. Konfigurer grundparametre ved begge endepunkter Sørg for at de centrale parametre er konsistente på begge sider: sikkerhedsaftale-konfiguration, identifikation, og hvilke net/tilladelser der skal gå i tunnel.

  2. Etabler tunnelen og overvåg logs Hvis tunnelen ikke kommer op, er næste skridt typisk at undersøge forbindelsesforhandling og eventuelle blokeringer i firewall/ACL. Uden fejlsøgning i logs bliver det ofte et gæt.

  3. Test routing og “internt net til internt net” Når tunnelen er oppe, test da målrettet kommunikation mellem det/de net du har defineret. Hvis en specifik applikation fejler, start med enkle kontroltests, så du kan afgøre om problemet er routing, adgangstilladelser eller applikationsniveau.

  4. Valider ændringer trinvis Hvis du ændrer flere komponenter samtidigt (routing, firewall og VPN-regler), bliver årsagsfinden vanskelig. En trinvis tilgang gør det lettere at gentage og dokumentere.

Forskelle og vigtige grænser: hvad kan ændre resultatet?

Der er nogle forhold, som ofte skaber forskelle mellem et “teoretisk” design og en faktisk stabil implementering:

  • Overlappende IP-adresser: Selv når tunnelen etableres, kan overlappende subnets gøre, at trafik ikke rammer det rigtige sted.
  • Ufuldstændig trafikmatch: Hvis selectors/regel-scope ikke dækker de net du tester, kan du få “tunnel oppe, trafik udebliver”.
  • NAT og policy-routing: NAT kan ændre pakke-egenskaber, så det kræver korrekt forståelse af hvordan gatewayen ser kildedestinationer.
  • Firewall asymmetri: Hvis reglerne ikke tillader samme trafik i begge retninger (eller hvis der er forskellige policyer), kan forbindelsen fungere halvt.
  • Performance og stabilitet: Kryptografi og tunnelopsætning påvirker typisk CPU/throughput afhængigt af udstyr og belastning. Det er ikke nødvendigvis synligt i små tests, men kan blive vigtigt ved større datamængder.
  • Drifts- og vedligeholdelsesbillede: Hvis nøgle-/certifikater skal udskiftes, eller hvis en gateway opgraderes, kan konfigurationen kræve omhyggelig planlægning for at undgå nedetid.

Fejlkilder i praksis og kontrollerbare checkpunkter

Når noget ikke fungerer, er det ofte muligt at afgrænse problemet uden at ændre alt på én gang. Her er kontrollerbare checkpunkter:

  • Er tunnelen faktisk etableret? Brug enhedens tilgængelige status/logindikatorer for at se, om sikkerhedsaftalen kommer op.
  • Matcher det net du tester, de net der er tilladt i VPN-reglerne? Tjek om kilde- og destinationsnet er dækket.
  • Er der en logisk rute tilbage? En typisk fejl er, at den ene side sender trafikken “ind i VPN”, men modtagersiden ikke har en passende rute tilbage.
  • Er firewallregler konsekvente? Kontroller tilladelser på begge sider for både VPN-relateret og efterfølgende trafik.
  • Er NAT håndteret korrekt? Hvis der er NAT, verificér at gatewayen har den forventede syn på adresserne.
  • Er der IP-overlap? Sammenlign adresser/områder på begge sider før og efter implementering.

Skal du vælge statisk eller dynamisk rutehåndtering?

Valget afhænger af virksomhedens netstruktur og ønsket kontrol. Statisk rutning kan være tilstrækkelig, hvis nettene er få, stabile og lette at dokumentere. Dynamisk rutning kan reducere manuel vedligeholdelse, men kræver disciplin i design, filtrering og fejlsøgning.

Uanset valg gælder samme kerneprincip: VPN’en skal understøtte den måde ruterne distribueres/benyttes på, og firewall skal tillade den trafik der følger af rutevalgene.

Hvad bør du kunne efter implementeringen?

Når site-to-site VPN er sat op korrekt, bør du kunne:

  • forklare hvilke interne net der er koblet, og hvilke der ikke er
  • dokumentere hvordan trafik finder vej (ruter og firewalltilladelser)
  • teste en kendt kommunikationsstrøm og reproducere resultatet
  • afgøre om fejl skyldes tunnelen, trafikmatch/routing eller adgangstilladelser

Hvis du ikke kan svare på disse punkter, er det en god indikation af, at implementeringen mangler en klar afgrænsning eller validering.