Hvad er en site-to-site VPN, og hvorfor fejler den?

En site-to-site VPN forbinder to netværk via en krypteret “tunnel”, så maskiner i hvert net kan kommunikere som om de var i samme private net. Når forbindelsen ikke virker, skyldes det ofte ikke selve krypteringen, men noget i kæden omkring tunnelen: netværksadresser, routing, firewall-regler, NAT, eller forkerte VPN-parameterkombinationer.

Det er nyttigt at tænke fejlen som et “hvor stopper trafikken”-problem. Typisk kan problemet ligge i:

  • Forhandling af VPN-tunnelen (fase/handshake)
  • Selve indkapslingen og krypteringen
  • Trafik inde i tunnelen (routing mellem delnet)
  • Mulige interferenser som MTU, fragmentering og NAT/portspecifikation

Da der ikke findes ét universelt mønster, er målet at reducere antallet af mulige årsager hurtigt ved at teste de mest almindelige kontrolpunkter i rækkefølge.

Almindelige symptomer og deres mest sandsynlige årsager

Tunnelen “kommer ikke op” (ingen forbindelse)

Hvis VPN-forbindelsen ikke etableres, er de mest almindelige årsager:

  • Forkerte identiteter eller legitimationsoplysninger (f.eks. nøgler/certifikater)
  • Portåbning mangler, eller firewall blokerer IKE/handshake-trafik
  • Uoverensstemmelse i VPN-parameterkombinationer (krypterings- eller autentifikationsindstillinger)
  • Routing tilbage til VPN-endepunkter mangler (selv om “det burde virke”, kan en forkert default-rute gøre den ene vej umulig)

Kontrolidé: Hvis tunnelen ikke etableres, skal du primært undersøge håndtrykket på begge ender, og om den ene side faktisk kan nå den anden på de relevante adresser og porte.

Tunnelen er oppe, men der er ingen netværksadgang

Her er tunnelen etableret, men trafikken inde i tunnelen stopper. Ofte skyldes det:

  • Manglende eller forkerte routes til de fjerneste undernet (routerne ved ikke, at de skal sende trafikken gennem VPN’en)
  • IP-adressekonflikt (samme undernetnummerering bruges begge steder)
  • Uoverensstemmelse i, hvilke delnet VPN-politikken dækker
  • Firewall-regler, der tillader VPN, men blokerer den interne trafik

Kontrolidé: Sammenlign “hvad tror routerne at de kan nå?” mellem enderne. En tunnel kan være korrekt etableret, men stadig være ubrugelig, hvis ruter og politikker ikke matcher.

Forbindelsen flapper (op/ned), timeouts eller periodisk drop

Intermitterende problemer kan komme af:

  • Skift i ruter eller gateways (f.eks. efter netværksændringer)
  • MTU/fragmenteringsproblemer (særligt hvis der sendes større pakker; det kan ligne “random” drop)
  • NAT eller firewall-state der ændrer sig over tid
  • Tidsindstillinger, session-liv og genforhandling som ikke håndteres stabilt

Kontrolidé: Kig efter et mønster. Hvis drop sker efter bestemte intervaller, kan det pege på genforhandling eller timeouts. Hvis drop korrelerer med bestemte typer trafik, kan MTU eller særlige protokoller være involveret.

Meget langsom hastighed eller høj latenstid

Når performance er dårlig, kan forklaringen ligge i:

  • Ineffektiv routing (trafik tager en længere eller forkert vej)
  • For mange “håbede” regler, der tvinger til at droppe og retransmitte
  • Overhead fra kryptering og dårlige CPU-forhold på gatewayen (generel mekanisme; den konkrete effekt afhænger af konfiguration og hardware)
  • MTU-problemer, der skaber fragmentering eller retransmission

Kontrolidé: Afklar om problemet er generelt (gælder al trafik) eller kun for visse protokoller/segmenter. Det reducerer hurtigt mulighederne.

Simple mentale modeller: tunnelen, undernettene og vejen tilbage

For at gøre fejlfinding mere kontrollerbar kan du bruge tre spørgsmål:

  1. Kan hver ende nå VPN-endepunktet? Selv med en korrekt VPN-konfiguration kan tunnelen ikke etableres, hvis der ikke er end-to-end netværksmulighed til endepunktsadresserne.

  2. Er de fjerneste delnet korrekt defineret og routet? Trafik inde i tunnelen afhænger af, at begge sider ved, hvilke undernet der skal sendes gennem VPN’en.

  3. Hvor stopper trafikken, hvis du tester i praksis? Hvis du kan sende til VPN-endepunktet, men ikke til et bestemt fjernsubnet, er problemet typisk i ruter/politikker eller firewall for interne flows.

Denne “vej tilbage” er særlig vigtig: Fejl opstår ofte fordi den ene retning (eller kontroltrafik) ikke når frem, selv om det ser ud til, at den anden retning gør.

Undtagelser og forskelle, der ofte forvirrer

IP-adresse overlap er et klassisk problem

Hvis begge sites bruger samme private undernet (eller overlappende CIDR), kan VPN’en blive etableret, men trafikken kan blive ubrugelig eller ramme forkert destination. Uanset kryptering og tunnelopsætning kan overlappet skabe tvetydighed i routing.

NAT og “hvem er afsenderen?”

Når NAT er involveret, kan tunneletablering og intern trafik blive påvirket, fordi afsender-/modtageradresser ændres. Det behøver ikke betyde, at VPN “ikke virker”, men det gør fejlbilledet mere komplekst, og du skal sikre, at regler, politikker og portåbninger matcher den faktiske adressering på begge sider.

MTU/fragmentering kan forklare “nogle typer trafik virker, andre ikke”

Hvis kun større pakker (eller specifikke protokoller) oplever problemer, er MTU en kandidat. I praksis kan symptomet være, at almindelig web virker, mens andre applikationer eller filoverførsler fejler eller bliver meget langsomme. Det er ikke sikkert, at det gælder alle miljøer, men det er en hyppig forklaring.

“Tunnelen er oppe” er ikke altid ensbetydende med “trafikken er oppe”

Mange fejler fordi de kun tjekker statusindikatoren på gatewayen. Du bør også verificere, at gatewayen faktisk forward’er trafik til de ønskede fjernsubnet via tunnelen.

Praktisk fejlsøgning: kontrolpunkter du kan teste uden gætteri

Start med dokumentation af det, der forventes at virke

Lav en kort liste over:

  • Hvilke delnet på site A skal nå hvilke delnet på site B
  • Hvilke protokoller/ports der er kritiske
  • Hvilke ændringer der er sket (konfig, firmware, certifikater, ruter, firewall)

Det gør det lettere at se, om en fejl er “ny” efter en konkret ændring.

Test tilgængelighed til VPN-endepunktet først

Før du dykker ned i interne regler, så afklar om den ene ende faktisk kan nå den anden på de nødvendige adresser/transportkanaler. Hvis dette ikke er opfyldt, kan resten af fejlsøgningen spildes.

Verificér tunnel-forhandlingens match

Hvis tunnelen ikke etableres eller etableres og falder igen, så sammenhold de centrale VPN-parametre på begge sider. Uoverensstemmelser er en hyppig årsag, og du får hurtigst fremdrift ved at kontrollere “match” frem for at justere tilfældigt.

Bekræft routes og politikker for fjernsubnet

Sørg for, at begge gatewaye har en tydelig rute/forwardinglogik for de fjerneste delnet gennem VPN’en. Hvis du har mistanke om ruteproblemer, så test en eller to konkrete destinationer og observer om trafik rammer korrekt next hop.

Kontrollér firewall-regler både for VPN-trafik og intern trafik

En firewall kan tillade selve tunnelet, men stadig blokere trafikken inden i tunnelen. Tjek derfor både:

  • Regler for etablering/handshake
  • Regler for den interne trafik mellem delnet

Overvej MTU, hvis problemet er “delvis”

Hvis nogle applikationer/protokoller fungerer, men andre fejler, så vurder MTU/fragmentering. Det kan være en mere praktisk løsning at teste større/ mindre payloads eller justere MTU i kontrollerede trin (hvor muligt i jeres miljø), end at ændre hele routingpolitikker.

Kig på fejlmønstre fra begge ender

Når noget flapper, er “hvorfor lige nu?” ofte i loggene. Sammenlign tidspunkter for:

  • Når tunnelen prøver at forhandle
  • Når trafik falder
  • Om der er samtidige ændringer i ruter eller firewall-state

Det hjælper med at afgrænse, om problemet starter i den ene eller anden ende.