Volgende hop in een VPN-route: waarom de gateway lokaal bereikbaar moet zijn

Een route naar een VPN-netwerk draagt twee adressen die gemakkelijk te verwarren zijn: het bestemmingsprefix dat het pakket probeert te bereiken en de volgende hop die het een stap dichterbij brengt. Op een LAN-host moet die volgende hop een router zijn die u daadwerkelijk op dezelfde link kunt bereiken. Het externe VPN-adres is geen volgende hop, hoe netjes het ook past bij de bestemming die u in gedachten hebt.

Dit draaiboek behandelt het gewone geval: een laptop op 192.168.20.0/24, een VPN-gateway met LAN-adres 192.168.20.5 en een extern netwerk 10.70.0.0/24 achter die gateway. Alle onderstaande opdrachten gaan ervan uit dat u op de laptop werkt, tenzij anders vermeld.

Twee adressen, één route

Het bedoelde item is 10.70.0.0/24 via 192.168.20.5. Het prefix zegt waar het pakket heen gaat; het via-adres zegt wie het daarheen draagt. De kernel weigert een route te installeren waarvan hij de gateway niet via de door u genoemde interface kan bereiken, en die weigering is het hele punt: een volgende hop die de tunnel nodig heeft om bereikbaar te zijn, kan niet de volgende hop zijn die de tunnel bouwt.

De eerste controle is dus niet «is de gateway up» maar «staat de gateway op deze link». Het eigen subnet van de laptop, zijn ARP- of buurvermelding en de interface in de route moeten allemaal overeenkomen. Een adres dat alleen binnen 10.70.0.0/24 bestaat, kan de bestemming van een tweede route zijn, maar nooit het via van de eerste.

Waartoe de volgende hop de gateway verplicht

De route op de laptop installeren bepaalt alleen de eerste overdracht. Daarna heeft de gateway zijn eigen pad nodig: doorsturen ingeschakeld, een tunnelroute voor 10.70.0.0/24 en elk toegangsbeleid dat bepaalt wie ervan gebruik mag maken. Op Linux is dat net.ipv4.ip_forward=1 plus een tunnelroute; een firewall ervoor heeft een regel nodig die de doorgestuurde stroom toestaat.

De terugweg is het deel dat mensen vergeten. De externe kant moet een route terug naar 192.168.20.0/24 hebben, of het ontwerp moet de bron van de laptop vertalen naar iets wat de externe kant kent. Een werkende ping vanaf de gateway bewijst dat de gateway het externe netwerk bereikt; hij zegt niets over de vraag of de pakketten van de laptop de terugreis overleven.

Controleer de opzoeking vanaf de host die verstuurt

Vraag de kernel welke volgende hop hij zou kiezen, en lees de interface in het antwoord:

ip route get 10.70.0.10
ip route show 10.70.0.0/24
ip neigh show 192.168.20.5

Als de opzoeking de gateway en de LAN-interface meldt, is het eerste stuk geconfigureerd zoals bedoeld. Als hij het tunnelapparaat meldt, is iets eerder in de tabel specifieker en wint. Als de route helemaal niet installeert, vertelt de kernel u dat de gateway onbereikbaar is, en die melding is nuttiger dan welke pakketopname dan ook.

Herhaal de test dan vanaf de juiste plek. Een verzoek dat op de gateway wordt gemaakt, gebruikt het eigen bronadres van de gateway, wat een ontbrekende terugroute of een beleid dat alleen bepaalde bronnen toestaat kan verbergen. De ip-route-handleiding scheidt bestemming, gateway en de onlink-overschrijving, en de overschrijving is het waard te begrijpen voordat u hem gebruikt.

Gebruik onlink niet om bereikbaarheid te veinzen

onlink vertelt de kernel de bereikbaarheidscontrole voor een gateway over te slaan en er toch naartoe te sturen. Het maakt geen pad, lost geen ARP op voor een adres dat er niet is en zorgt er niet voor dat een externe router op uw Ethernet-segment antwoordt. Het is legitiem voor gateways die antwoorden maar niet in een aangesloten subnet zitten, en het is een valkuil wanneer het wordt gebruikt om een fout te dempen die u niet hebt uitgelegd.

Als de route alleen met onlink installeert, is de volgende vraag waarom de gateway niet is waar u denkt. Een verkeerde VLAN, een tweede adres op de verkeerde interface of een typefout in het laatste octet veroorzaken dit allemaal, en elk ervan breekt ook de terugweg zodra het verkeer begint te stromen.

Punt-tot-punt-tunnels zijn geen Ethernet

Een tunnelapparaat doet geen ARP en heeft vaak geen zinvol subnet van buren. De routes ervan zien er vaak uit als 10.70.0.0/24 dev tun0, zonder enige via, omdat de peer het enige andere eindpunt is. Een via in LAN-stijl naar die tabel kopiëren levert een route op die de kernel kan weigeren of, erger, een die wijst naar een adres waarop de peer nooit antwoordt.

Houd de twee modellen gescheiden in het draaiboek: een LAN-route heeft een bereikbare gateway, een tunnelroute heeft een interface en een peer. WireGuard, OpenVPN en IPsec tonen allemaal iets andere vormen, dus noteer de vorm die u werkelijk hebt gebruikt in plaats van te generaliseren vanaf één host.

Toevoegen, bevestigen, terugdraaien

De hele wijziging is drie opdrachten en één controle, en hij moet in die volgorde worden opgeschreven:

sudo ip route add 10.70.0.0/24 via 192.168.20.5
ip route get 10.70.0.10
ping -c 3 10.70.0.10
sudo ip route del 10.70.0.0/24 via 192.168.20.5

Bevestig het pad, bevestig één bestemming en houd dan de verwijderregel gereed voor het geval de wijziging de host onbereikbaar maakt op een manier die u niet had voorzien. Als de route een herstart moet overleven, zet hem dan in de netwerkconfiguratie van de host in plaats van in een shell-profiel, en test de herstart voordat u erop vertrouwt. Een route die alleen bestaat in de shell die hem heeft toegevoegd, is een route die u twee keer zult debuggen.