Hvad er site-to-site VPN, og hvad løser den
En site-to-site VPN forbinder to netværk (typisk to lokationer) via en krypteret tunnel, så maskiner i hvert net kan nå hinanden som om de var på samme private netværk. Formålet er normalt at skabe en beskyttet kommunikationsvej mellem lokationer, uden at hver enkelt bruger skal opsættes separat.
I praksis består løsningen af tre sammenhængende dele:
- en tunnel (det krypterede “rør”),
- en krypterings- og nøgleopsætning, og
- en routing-/policy-del, der bestemmer hvilke IP-net (subnet) der skal sendes ind i tunnelen, og hvordan trafikken skal håndteres.
Det er vigtigt at forstå afgrænsningen: En site-to-site VPN er primært et netværks-til-netværkslink. Hvis du i stedet skal håndtere mange individuelle brugere eller skiftende klienter, passer andre VPN-typer typisk bedre.
Et simpelt modelbillede af konfigurationen
Tænk på konfigurationen som et “match” mellem to endepunkter og en trafikregel.
- I hver ende definerer du tunnelens parametre (fx hvilke krypteringsalgoritmer og nøgle-/autentificeringsmetoder der bruges).
- Du definerer også “hvad” tunnelen skal bære: ofte som liste over lokale og fjerne subnet, der må/skal gå gennem VPN.
- Derefter skal routing i og omkring VPN’en stemme overens, så svartrafik finder tilbage til den rigtige lokation.
Hvis krypteringstunnel og trafikregler ikke matcher, ser du typisk symptomer som manglende forbindelser mellem bestemte net, periodiske udfald eller trafik der går “udenom” tunnelen.
Konfigurationspunkter: parametre, subnet og routing
Når du bygger en site-to-site VPN, er de mest kontrolbare punkter normalt følgende.
1) Endepunkter og tunnel-identitet
Du skal sikre, at begge sider peger på hinanden (IP/adresser) og at tunnelopsætningen findes på begge ender. Selv små uoverensstemmelser i navne/ID eller hvilke parametre der forhandles, kan forhindre tunnelen i at komme op.
2) Hvilke net skal i tunnelen
En klassisk fejl er at “låse tunnelen op” for for lidt eller for meget.
- For lidt: du kan ikke nå de adresser, du forventer.
- For meget: du kan ende med uønsket adgang mellem net, eller mere trafik end nødvendigt i tunnelen.
Hold listen over subnet, der skal være gennem VPN, målrettet. Jo mere præcist scope er, desto lettere bliver fejlfinding og drift.
3) Routing og returtrafik (asymmetri)
Selv hvis selve tunnelen kører, kan forbindelser fejle pga. routing.
- Sørg for, at trafik fra det lokale subnet til det fjerne subnet sendes til VPN’en.
- Sørg for, at svartrafik fra den fjerne side også sendes tilbage via den samme logik.
Asymmetrisk routing (hvor forespørgsel går via VPN, men svar ikke gør) kan give meget “mærkelig” adfærd: sessions oprettes ikke, eller bestemte forbindelser virker kun nogle gange.
4) NAT-overvejelser
Om der er NAT involveret, påvirker ofte hvilke IP-adresser der faktisk udveksles. Hvis en side NAT’er, kan det kræve ekstra omtanke for at sikre, at den anden side kan finde tilbage til den rigtige kilde/destination. Uden at gå ind i specifikke produkter: princippet er, at “hvem der er hvem” i IP-lagene skal matche dine tunnel- og policy-regler.
Forskelle og begrænsninger: hvor løsningen ændrer sig
Nogle valg kan ændre, hvordan konfigurationen bør tænkes.
IP-adresseplan og overlap
Hvis begge lokationer bruger de samme private IP-intervaller (fx 10.0.0.0/24 i begge steder), opstår der konflikt. Så kan du ikke entydigt afgøre, hvilket net der er “lokalt” og hvilket der er “fjernt” for VPN’en. I sådanne tilfælde kræver en løsning typisk adresseringsomlægning eller en strategi, der håndterer overlap.
Driftssikkerhed og afhængighed af underliggende net
Site-to-site VPN er så stabil som transportforbindelsen og de underliggende netværksforhold. Hvis linket mellem lokationerne er ustabilt, kan tunnelen fluktuere, selv om VPN-parametrene er korrekte. Det betyder, at optimering ofte bør inkludere kontrol af latenstid, packet loss og kapacitet på “underlaget”.
MTU og fragmentering
Over VPN kan overhead ændre den effektive MTU. Hvis MTU ikke passer, kan du få symptomer som langsom browsing, fejl ved bestemte protokoller eller “kun nogle” typer trafik. At justere MTU/MSS (med forsigtighed) kan derfor være en reel del af optimeringen.
Brug og optimering: sådan tester og strammer du op
Optimering bør være målebaseret: først få tunnelen til at stå stabilt, derefter verificere rækkevidde, og til sidst finjustere performance.
Trin 1: Bekræft at tunnelen etableres
Brug log-/statusvisningen til at kontrollere, at tunnelens forhandling kører på begge sider. Fokusér på at få “tunnel op” og stabilt, før du antager at routing virker.
Trin 2: Verificér reachability pr. subnet
Test derefter direkte mellem lokationernes subnet (fx fra et vært i lokalt net til et vært i fjernt net). Gå gerne målrettet: hvis alt virker, er scope og returtrafik sandsynligvis korrekt; hvis ikke, hjælper det med at lokalisere hvilke adresser der mangler.
Trin 3: Tjek routingbeslutninger
Hvis der er adgangsproblemer, så tjek at trafikken faktisk følger den rute, du forventer. Hold særligt øje med:
- ruter der peger væk fra VPN ved destinationen,
- manglende ruter tilbage (returtrafik),
- utilsigtede policy-regler.
Trin 4: Performance-sanity-check
Når tunnelen virker og subnet-nåelighed er på plads, kan du kigge på:
- om links har tilstrækkelig kapacitet til den forventede trafik,
- om overhead fra kryptering og encapsulation påvirker throughput,
- om MTU-relateret adfærd giver problemer.
Trin 5: Logbaseret fejlfinding
Ved periodiske fejl er logning ofte det vigtigste værktøj. Søg efter mønstre: falder tunnelen ved bestemte tidspunkter, falder kun bestemte protokoller, eller ser du forhandling/timeout? En god strategi er at ændre én ting ad gangen og dokumentere effekten.
Sådan kan du “kontrollere rigtigheden” før du kan stole på den
Hvis du vil være sikker på, at din site-to-site VPN reelt svarer til behovet, kan du lave en enkel tjekliste baseret på konfigurationens kerne.
- Er krypteringstunnel og forhandling sat korrekt op på begge sider?
- Stemmer listen over lokale/fjerne subnet med det, du faktisk skal kunne nå?
- Løber trafikken ind og tilbage via samme logiske VPN-path?
- Er der adresseoverlap, der kan skabe tvetydighed?
- Indikerer tests, at MTU eller fragmentering skaber problemer?
Hvis du kan svare “ja” på de punkter for de relevante subnet og test-case, er du typisk langt i retning af en løsning, der er både brugbar og lettere at drive.
Bemærk: Der findes mange varianter af site-to-site VPN-implementeringer, og nogle detaljer afhænger af netudstyr og valgte VPN-typer. Brug derfor denne tekst som en kontrolramme, og mål resultaterne i dit eget miljø.