Site-naar-site of remote access via VPN: wat de twee verbindt

Beide ontwerpen heten VPN en lossen verschillende problemen op. Een site-naar-site-tunnel verbindt twee gateways, zodat elke host daarachter toegestane adressen aan de andere kant kan bereiken zonder iets te installeren. Een remote-access-tunnel verbindt afzonderlijke apparaten met een netwerk, één client tegelijk. De vergelijking is belangrijk omdat de meeste uitrolfouten ontstaan door het ene ontwerp te configureren terwijl men het gedrag van het andere verwacht, en het symptoom is meestal een time-out bij een dienst die de tunnel wel degelijk heeft bereikt.

Twee ontwerpen, twee grenzen

Geen van beide ontwerpen breidt een LAN-broadcastdomein uit. Apparaten aan de andere kant verschijnen niet in een lokale ontdekkingslijst, en dat verwachten is de eerste aanname die je moet laten vallen. Privé-DNS-namen die je bewust publiceert zijn voorspelbaarder dan welk ontdekkingsprotocol dan ook, en ze overleven een wisseling van leverancier.

Neem 10.10.0.0/24 op de ene locatie en 10.20.0.0/24 op de andere. Gateway A heeft een route of een traffic-selector nodig die het prefix 10.20.0.0/24 de tunnel in stuurt, en gateway B heeft het spiegelbeeld daarvan nodig. Hosts aan beide kanten gebruiken dan gewone IP-connectiviteit en komen er nooit achter dat er een tunnel bestaat. Die onzichtbaarheid is de functie, en daarom lijken storingen op gewone netwerkfouten in plaats van tunnelfouten.

Op beleid gebaseerd en op route gebaseerd zijn niet dezelfde tunnel

Bij een op beleid gebaseerde IPsec-implementatie bepalen de onderhandelde traffic-selectors precies welke bron- en bestemmingsparen beschermd zijn. Als er achter één gateway een nieuw subnet verschijnt en geen selector dekt het, blijft de tunnel overeind en wordt het nieuwe subnet simpelweg niet vervoerd. Bij een op route gebaseerd ontwerp ontvangt een interface het verkeer en beslist de routingtabel, waardoor het toevoegen van een prefix een routewijziging is en geen nieuwe tunnelonderhandeling.

StrongSwan toont beide weergaven rechtstreeks, en ze samen lezen is de manier om erachter te komen welk model je werkelijk hebt uitgerold.

swanctl --list-sas
ip xfrm policy
ip -4 route show table all | grep -E '10\.(10|20)\.'

Een selectorlijst waarin het prefix dat je nodig hebt ontbreekt, verklaart de storing zonder enige packetcapture, en een route die naar de verkeerde interface wijst verklaart de spiegelstoring op de terugweg. Lees beide voordat je iets opnieuw onderhandelt, want een sleutelvernieuwing voegt geen selector toe die je nooit hebt geconfigureerd.

Plan de adressering vóór de tunnel

Overlappende bereiken zijn de ontwerpfout die niet met configuratie te herstellen is. Als beide locaties 192.168.1.0/24 gebruiken, heeft een host die 192.168.1.50 nodig heeft twee kandidaten en geen manier om te kiezen. De tunnel authenticeert, de beveiligingsassociaties komen tot stand, en de routingbeslissing is alsnog verkeerd of dubbelzinnig.

Kies een van drie eerlijke opties: één locatie hernummeren, het overlappende bereik bij de gateway vertalen zodat elke kant een eigen prefix ziet, of voor die hosts afzien van directe routing en de dienst op een andere manier publiceren. Elk heeft een prijs, en de eerste is meestal de goedkoopste over een horizon van twee jaar. Beslis voordat de tunnel bestaat, want achteraf raakt de wijziging elk apparaat met het oude adres.

Los ook de MTU-kwestie vroeg op. Een tunnel verkleint de bruikbare payload, en een ontwerp dat op fragmentatie leunt gedraagt zich anders dan een dat de MSS bij de gateways vastzet.

Doorsturen en beleid staan buiten de tunnel

De gateway moet bereid zijn pakketten door te sturen tussen de tunnelinterface en de LAN-interface, en beide richtingen hebben beleid nodig dat de dienst toestaat. Op Linux zijn dat twee afzonderlijke instellingen, plus de firewallregels die bepalen of de doorgestuurde stroom überhaupt is toegestaan.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -s 10.20.0.0/24 -d 10.10.0.0/24 -j ACCEPT
iptables -A FORWARD -s 10.10.0.0/24 -d 10.20.0.0/24 -j ACCEPT

De ontvangende host voegt een derde laag toe: zijn eigen firewall moet nog steeds een client uit het externe subnet accepteren. Een fileserver die alleen zijn lokale /24 toestaat, weigert doorgestuurd verkeer van 10.20.0.7, hoe gezond de tunnel er ook uitziet, en die weigering wordt gemakkelijk als routestoring gelezen.

Test vanaf een host, niet vanaf de gateway

Een ping die de gateway zelf verstuurt, kan een ander bronadres en een ander beleid volgen dan doorgestuurd gebruikersverkeer. Daardoor is het een zwakke test en soms een misleidende: hij slaagt terwijl de toepassing faalt, of faalt terwijl de toepassing werkt.

ip route get 10.10.0.5 from 10.20.0.7
ping -I 10.20.0.7 10.10.0.5
curl -sv --max-time 5 http://files.10-10.internal/ -o /dev/null

Gebruik een echte host, een echt bronadres en het echte protocol dat de toepassing gebruikt. Lees daarna de retourweg apart, want een werkende voorwaartse richting zonder retourroute levert een time-out op die er identiek uitziet als een geblokkeerde dienst.

Kies het ontwerp op basis van de vraag die je beantwoordt: verbind je netwerken of laat je apparaten toe? Al het andere, inclusief welke leverancier je configureert, volgt uit dat antwoord.