Grundidéen: NAT og VPN gør hver sin del

NAT (Network Address Translation) er en funktion i netværket, der oversætter IP-adresser (og ofte porte) mellem “internt” og “eksternt” net. Formålet er eksempelvis at lade mange interne enheder dele en mindre mængde offentlige adresser.

Et VPN (Virtual Private Network) tilføjer typisk en krypteret tunnel mellem to endepunkter. Når data sendes gennem VPN’et, bliver de først “kapslet” (indpakket) i VPN-protokollen og derefter sendt som almindelige IP-pakker gennem netværket.

Det vigtige samspil er derfor ikke, at VPN erstatter NAT, men at VPN trafikken skal fungere, når den passerer gennem NAT-enheder.

Et simpelt gennemløbsbillede

Tænk på forbindelsen i to lag:

  1. NAT-laget: En klient på et privat net sender udgående trafik. NAT-enheden omskriver kilde-IP (og ofte kildeport) til en offentlig adresse/port, så svaret senere kan leveres tilbage til den rigtige interne enhed.

  2. VPN-laget: Klienten etablerer en tunnel til VPN-serveren/peer. Den krypterede trafik går i praksis over en bestemt VPN-protokol og dermed typisk over bestemte porte eller transportmuligheder.

Når VPN-klientens tunneletablering sendes “udad”, vil NAT stadig omskrive adresser. Når VPN-serveren sender svar tilbage, skal NAT kunne matche svaret til den tidligere oprettede oversættelse. Hvis NAT ikke håndterer VPN-trafikken korrekt, kan tunnelen fejle eller forbindelsen falde ud.

Hvad kan ændre sig for NAT, når der er VPN?

Når VPN-trafik passerer NAT, kan følgende forhold blive afgørende:

  • Protokol- og portforbrug: Mange VPN-opsætninger bruger bestemte transportmekanismer. Hvis den netværksport eller det transportmønster, VPN forventer, ikke er åbent/planlagt, kan NAT eller firewall stoppe trafikken.

  • Kapsling og “hvilken pakke NAT ser”: NAT-enheden ser de ydre IP-pakker. Den kan derfor kun oversætte det, der fremgår af den ydre pakkestruktur. Eventuelle indlejrede adresser inde i tunnelens kapsling håndteres typisk ikke af NAT på samme måde som de ydre adresser.

  • Tidsbegrænsning og sessioner: NAT holder som regel styr på “sessioner” (oversættelser) i en begrænset periode. Hvis VPN-tunnelen kræver periodisk keepalive eller der opstår lange inaktivitetsintervaller, kan NAT overse “tunnelens livstegn” og lukke oversættelsen.

  • Endepunktsidentitet og peer-estimering: Hvis VPN-løsningen forsøger at nå tilbage til “den rigtige” peer-adresse, kan NAT-oversættelsen betyde, at den adresse, VPN ser, ikke matcher den interne adresse. Det kan kræve korrekt konfiguration, så VPN endepunkter bruger adresser, der matcher den faktiske vej gennem NAT.

Undtagelser og grænser: Når NAT ikke bare “er usynligt”

Der er situationer, hvor VPN + NAT kræver ekstra omtanke:

  • NAT-to-NAT (flere lag NAT): Hvis trafikken passerer igennem mere end én NAT-enhed, kan der opstå flere samtidige oversættelser. Det øger kompleksiteten for, hvordan svar pakkes korrekt tilbage.

  • Restriktive firewall-regler: NAT alene handler om adresse/port-oversættelse, men det er ofte firewall-regler, der afgør om bestemte typer VPN-trafik må igennem. Resultatet kan ligne NAT-fejl, men den reelle årsag er policy/filtrering.

  • Aktive netværk der ændrer trafik: Nogle netværksenheder kan lave ekstra inspektion eller “omskrivning” ud over standard NAT, hvilket kan påvirke, om VPN-pakker bevares i en form, tunnelen forventer.

  • Manglende eller uforenelig konfiguration: Hvis VPN-protokollen forventer én form for routing eller porte, men netværket leverer en anden, kan tunnelen ikke etableres. I sådanne tilfælde er det ikke et generelt “VPN virker/virker ikke”-spørgsmål, men et kompatibilitets- og konfigurationsspørgsmål.

Praktisk: Hvad kan du tjekke uden at gætte?

Du kan gøre din fejlsøgning mere målrettet ved at kontrollere, at NAT og VPN stemmer overens i grundpunkterne:

  1. Er den VPN-transport, der bruges, tilladt gennem det net, hvor NAT findes? Kig efter om der er åbenhed for den relevante type trafik (ofte forstået som protokol/port-mønstre) mellem klient-net og VPN-endepunkt.

  2. Kan der etableres en tunnel, og falder den igen hurtigt? Hurtige udfald kan indikere, at NAT-oversættelsen udløber, eller at keepalive ikke fungerer som forventet.

  3. Stemmer “udgående” og “indgående” trafik overens med NAT-matching? Hvis svarpakker ikke finder tilbage til den oprindelige oversættelse, vil tunnelen typisk ikke holde.

  4. Er der flere NAT-lag eller ændringer undervejs? Hvis der er en ekstra router, som også laver NAT, kan du få et andet billeddannelse af hvilke adresser/porte der faktisk bruges.

Hvis du vil kunne forklare problemet præcist, er det ofte nok at skelne mellem: (a) om tunnelen kan etableres gennem netværket, og (b) om tunnelen kan holde gennem NAT-sessioner og netværkets filtrering. Det gør det lettere at forstå, hvor samspillet mellem VPN og NAT bryder sammen.