Een tweede subnet toevoegen aan een site-to-site VPN: twee wegen

Een tweede subnet toevoegen aan een werkende site-to-site tunnel kost vijf minuten in het ene ontwerp en bijna een hele middag in het andere. Als de tunnel routes installeert voor de prefixen die u noemt, voegt u een route toe en het verkeer volgt die. Als hij één vast selectorpaar onderhandelt, blijft het nieuwe prefix onbeschermd tot beide kanten het eens zijn over een passend paar. Drie dingen beslissen: wat de configuratie van elke kant werkelijk beschrijft, of het onderhandelde verkeer wordt vernauwd tot het kleinste passende paar, en wie de retourroute voor het nieuwe bereik bezit.

Lees de kernel, niet het statuslabel

Een tunnel die verbinding meldt heeft minstens één kindassociatie geïnstalleerd, maar niet noodzakelijk degene die u denkt. Op Linux toont de kernel wat wordt toegepast: ip xfrm policy somt de selectorparen op en swanctl --list-sas (of de oudere ipsec statusall) toont wat de kanten hebben onderhandeld, inclusief de verkeersselectors per richting. Staat het nieuwe prefix in geen van beide, dan is het onbeschermd, wat het configuratiebestand ook zegt.

Vergelijk dat met de routetabel. In een routegebaseerde opzet is het tunnelapparaat de volgende hop voor de beschermde prefixen. Een beleidsgebaseerde opzet heeft vaak geen specifieke route voor het externe subnet, alleen de standaardroute, omdat het beleid het verkeer kiest en niet de tabel.

Beleidsgebaseerd: beide kanten moeten het nieuwe prefix vermelden

In strongSwan-termen zit de selector in local_ts en remote_ts onder de kindconfiguratie, de opvolgers van leftsubnet en rightsubnet. Het nieuwe prefix moet aan beide kanten spiegelbeeldig verschijnen: wat site A lokaal noemt, noemt site B extern. Een afwijking geeft zelden een schone fout. De kanten vernauwen tot de doorsnede, het oude prefix blijft werken en alleen het nieuwe faalt stil.

swanctl --load-conns
swanctl --initiate --child <child-name>
swanctl --list-sas
ip xfrm policy

Op pfSense of OPNsense betekent dat een tweede Phase 2-item dat het nieuwe lokale subnet aan het nieuwe externe koppelt, en dan toepassen. Houd het oude item; vervangen verplaatst het oorspronkelijke subnet in plaats van het toe te voegen. Als een bestaande Phase 2 al een supernet zoals 0.0.0.0/0 of een samengevat bereik dekt, voeg dan geen smaller item ernaast toe: overlappende selectors installeren concurrerende beleidsregels en de evaluatievolgorde bepaalt de winnaar.

IKEv1 maakt van elk subnetpaar een eigen Phase 2, en een kant die één paar per uitwisseling neemt, laat de rest vallen. IKEv2 kan meerdere selectorparen in één kind dragen, maar alleen als beide implementaties ze accepteren. De lijst uit swanctl --list-sas is de waarheid; wat u typte is een verzoek.

Routegebaseerd: de route is het beleid

Een XFRM-interface of VTI-apparaat draagt verkeer volgens de routetabel. U richt het nieuwe prefix op het apparaat op beide sites, en de toestand die aan de transformatie van de interface is gebonden, geldt. Er is geen selectorpaar te synchroniseren, daarom schaalt dit ontwerp beter naarmate subnetten toenemen. De strongSwan-doorstuurhandleiding gaat dieper in op de kernelkant.

ip route add 192.168.60.0/24 dev xfrm0
ip route get 192.168.60.10

WireGuard gaat verder. AllowedIPs is tegelijk de crypto-toestemmingslijst en, via wg-quick, het item in de routetabel. Voeg het prefix maar aan één kant toe en u krijgt een handdruk, uitgaande pakketten en stilte, omdat de andere kant pakketten laat vallen waarvan de bron niet op zijn lijst staat. De vorm wg set vervangt de hele lijst, dus herhaal de prefixen die al werkten, anders snijdt u ze af:

wg set wg0 peer <PUBKEY> allowed-ips 192.168.10.0/24,192.168.60.0/24
ip route add 192.168.60.0/24 dev wg0

Dat tweede commando is niet optioneel wanneer u wg set in plaats van wg-quick gebruikte. De kernel accepteert de nieuwe lijst meteen, maar niets voegt er een route aan toe, dus lokaal gegenereerd verkeer verlaat nog steeds de standaardgateway. Dat is de meest voorkomende reden dat een nieuw WireGuard-subnet werkt vanaf de tunnelhost en niet vanaf een laptop.

De retourroute faalt vaker dan de tunnel

Hosts op het nieuwe externe subnet moeten antwoorden via de VPN-gateway terugsturen. Wanneer die gateway niet hun standaardrouter is, gaat het antwoord naar de LAN-router, die het laat vallen of met een privébronadres naar het internet doorstuurt. Test vanaf een host aan de andere kant, niet vanaf de gateway: ip route get 10.30.20.15 op Linux of Find-NetRoute -RemoteIPAddress 10.30.20.15 in PowerShell toont de volgende hop die de host echt gebruikt. Als het antwoord niet het tunneleindpunt is, voeg daar een statische route voor het nieuwe prefix toe.

Bron-NAT op de site zonder retourroute is een legitiem alternatief en de manier waarop veel hub-and-spoke-implementaties elke server ongemoeid laten. Pas het ook toe op het nieuwe prefix op de gateway aan de bestemmingskant:

iptables -t nat -A POSTROUTING -s 10.30.20.0/24 -d 192.168.60.0/24 -j MASQUERADE

De prijs is reëel. Externe logboeken tonen geen individuele bronadressen meer en firewallregels op basis van het oorspronkelijke subnet vallen samen tot één regel voor de gateway. Kies dat bewust, niet omdat een route ontbrak.

Firewalls zijn de andere helft van de retourroute. Zonegebaseerde apparaten breiden de zone van een bestaande tunnelinterface niet automatisch uit naar een nieuw subnet, en een regel voor het oude prefix zal niet passen. Voeg het nieuwe subnet toe aan de zone of het regelpaar in beide richtingen voordat u IPsec de schuld geeft.

Beslis met drie vragen en verifieer met verkeer

De korte versie: noemt de configuratie van de kant prefixen (beleidsgebaseerd), of wordt verkeer naar een interface gerouteerd (routegebaseerd)? Vermelden beide uiteinden het nieuwe prefix? Is er een weg terug van het nieuwe subnet naar het oorspronkelijke bronbereik?

Verificatie is waar de meeste wijzigingen te vroeg worden gesloten. Een ping vanaf de gateway bewijst weinig, omdat de gateway vanaf zichzelf stuurt en vaak bij een ander beleid past dan een host. Ping vanaf een host op het nieuwe subnet, start dan de toepassing die de wijziging motiveerde en kijk naar tellers in plaats van een statuspictogram.

tcpdump -ni any host 192.168.60.10 and (esp or udp port 4500)
ip xfrm state
wg show

Op een beleidsgebaseerde tunnel moeten de tellers van ip xfrm state in beide richtingen stijgen; vlakke tellers betekenen dat het pakket wordt gerouteerd maar niet geselecteerd. Op WireGuard meldt wg show de overdracht per kant, en een handdruk zonder ontvangen bytes wijst op de lijst van de andere kant of zijn retourroute.

Sluit af met het vastleggen van het prefix, de selector of route van de kant, de beslissing over de retourroute en het firewall-item samen met de rest van de tunnelinventaris. Herstart dan één gateway en test opnieuw: een met de hand toegevoegde route verdwijnt, en de volgende persoon zou dat niet opnieuw moeten ontdekken.