Definition og formål

Site-to-site VPN er en type VPN, hvor to adskilte netværk forbindes over et offentligt eller delt transportnet (ofte internettet) ved hjælp af en krypteret tunnel. Formålet er, at netværkene kan udveksle trafik på en kontrolleret måde, som om der var en mere direkte og lokal sammenkobling.

Man bruger typisk site-to-site VPN, når man vil forbinde en virksomheds hovedkontor og filialer, integrere et eksternt netværk med interne systemer, eller give netværksbaseret adgang mellem lokationer. Det er netværks-til-netværks fokus: i stedet for at hver enkelt bruger opretter en VPN-session, er det selve netværkets gateway(e), der etablerer forbindelsen.

Eenvoudig model: gateways, tunnel og kryptering

Tænk på site-to-site VPN som en “sikker rute” mellem to VPN-gateways (fx routere, firewall-apparater eller dedikerede VPN-enheder).

  1. En gateway modtager trafik fra sit lokale netværk, som skal sendes til et andet netværk.
  2. Trafikken kapsles ind i en VPN-tunnel.
  3. Tunnelens indhold krypteres, så andre ikke kan aflæse indholdet undervejs.
  4. Den anden gateway dekrypterer trafikken og sender den videre til det lokale netværk på den anden side.

Selve “hvordan” der forbindes, afhænger af konfiguration og valgte protokoller, men grundideen er den samme: en kontrolleret, krypteret kommunikationskanal mellem to endepunkter.

Hvilke dele indgår (typisk)

Selv om implementering varierer, består en site-to-site VPN-løsning ofte af følgende elementer:

  • To VPN-endepunkter (gateways): De enheder, der opretter og håndterer tunnelen.
  • Kryptering og nøglehåndtering: Sikrer at data i tunnelen beskyttes, og at endepunkterne kan verificeres.
  • Trafikstyring (routing/ACL’er): Fortæller hvilke netværk/adresser der må sendes gennem VPN’en, og hvordan svartrafik håndteres.
  • Netværksplanlægning: Adresseringsområde(r) og eventuelle overlappende IP-net bør håndteres, så trafikken rammer korrekt.

Et vigtigt praktisk punkt er, at VPN ikke automatisk “forstår alt”. Gateways skal have regler og routing, der matcher netop de netværk, man ønsker at forbinde.

Hvad er “tunneling” i praksis

Når tunnelen er aktiv, behandles pakker som om de sendes over en særlig, beskyttet forbindelse. Konsekvensen er, at:

  • Trafik mellem de net man har defineret, kan passere på tværs af lokationer.
  • Trafik uden for de definerede net eller uden matchende regler typisk ikke går gennem forbindelsen.
  • Netværksadfærd kan påvirkes af overhead fra kryptering og indkapsling.

Hvor godt det fungerer i praksis afhænger derfor ofte ikke kun af “VPN er tændt”, men af korrekt opsætning af netværksregler, adresser og den valgte måde at styre trafikken på.

Forskelle og begrænsninger: hvad site-to-site ikke er

Site-to-site VPN er ikke det samme som en ren “bruger-VPN”, hvor individuelle enheder opretter sessions. Her er fokus på netværksforbindelsen mellem gateways.

Derudover er der centrale grænser, man skal være opmærksom på:

  • Overlappende IP-adresser: Hvis begge lokationer bruger samme IP-områder, kan det kræve ekstra designvalg, så trafikken kan skelnes.
  • Routing og netværksregler: Hvis routing eller adgangsregler ikke stemmer, kan dele af trafikken fejle, selvom tunnelen er oppe.
  • Performance og kapacitet: Kryptering og overhead kan påvirke gennemstrømning og responstid; det er en del af enhver krypteret tunnel.
  • Kompatibilitet med protokoller: Ikke al trafiktype opfører sig ens, og visse applikationskrav kan kræve ekstra overvejelser.

Der kan også være variationer i, hvordan nøgler og forbindelser etableres og vedligeholdes. Uden at kende jeres specifikke setup kan man ikke garantere, hvordan præcis alle detaljer opfører sig—men modellen med gateways, tunnel og trafikstyring er fælles.

Hvor du selv kan teste og kontrollere, at det virker

Hvis du vil verificere forståelsen af en site-to-site VPN-forbindelse uden at hoppe direkte til avanceret fejlfinding, kan du kontrollere følgende kontrolpunkter:

  • Er tunnelen etableret mellem de to gateways? Hvis endepunkterne ikke kan danne en sikker kanal, kommer trafikken ikke gennem.
  • Matcher netværksreglerne de net, du vil nå? Kontroller at de adresser/segmenter, der skal kommunikeres, faktisk er tilladt.
  • Stemmer routingveje og “svartrafik” overens? Det er ikke nok, at forespørgsler går gennem—returtrafik skal også kunne finde vej.
  • Kan du teste med kendt trafik? Brug typisk enkle forbindelser (fx adgang til en kendt tjeneste eller et kendt subnet), før du udvider.

Ved at gøre disse punkter systematisk kan du afgøre, om problemet ligger i tunnelen, i trafikstyringen eller i selve netværksdesignet.