VPN-client op een LAN-server: waarom antwoorden de verkeerde kant op gaan

De symptomen volgen één patroon: een host werkt, dan maakt hij als client verbinding met een VPN, en nu bereiken LAN-clients hem terwijl zijn antwoorden verdwijnen. Een opname op de host laat zien dat de antwoorden via het tunnelapparaat vertrekken in plaats van via de LAN-interface. Aan de tunnel is niets kapot, en de oplossing is een route, geen herverbinding. Werk de vier controles hieronder in volgorde af en stop bij de eerste die faalt.

Een antwoord is een nieuw pakket, geen omkering

Het helpt om het idee los te laten dat een antwoord terugreist langs de weg die een verzoek nam. Routing wordt per pakket, per richting, op de verzendende host beslist. Een verzoek dat van 10.64.0.23 in de tunnel binnenkwam, maakt geen retourpad; wanneer de host antwoordt, wordt dat antwoord als nieuw pakket tegen de tabel gehouden en verlaat het via de route die wint.

Daarom levert een full-tunnelclient op een machine die ook een LAN bedient zo een verwarrende storing op. De client installeert een standaardroute, of de twee halve standaardroutes die sommige clients verkiezen, en het antwoord aan een LAN-client past nu bij de tunnel. Het gaat naar de provider, die geen reden heeft om het door te sturen, en de LAN-client ziet een time-out terwijl de host draait en lokaal antwoordt. De opname maakt het duidelijk, en de routetabel verklaart het.

Houd twee subnetten in gedachten terwijl u de rest leest. Het ene is de VPN-adrespool waar de externe clients vandaan komen, in dit voorbeeld 10.64.0.0/24. Het andere is het LAN dat moet blijven werken, 172.16.24.0/24 met zijn router op 172.16.24.1. De fout is dat het verkeer tussen beide door de standaardroute wordt beslist.

Bewijs het met de opname en de opzoeking

Controleer voordat u iets wijzigt welk apparaat het antwoord zal gebruiken. Een opzoeking is sneller dan een opname en beantwoordt precies de vraag die de kernel beantwoordt wanneer het pakket wordt gebouwd.

ip route get 10.64.0.23 from 172.16.24.10
tcpdump -ni any -c 6 icmp

Lees het antwoord in twee delen. Noemt het dev tun0, dan inkapselt de host het antwoord en geeft het aan de provider, en de LAN-client zal het nooit zien. Noemt het dev eth0 maar loopt de client nog steeds in een time-out, dan is de route al juist en wordt het pakket later weggegooid, wat een ander probleem met een andere oplossing is.

De opname in dezelfde stap beslecht de twijfel die een ping niet kan. Een echo-antwoord dat de LAN-client bereikt, bewijst dat een of andere weg werkt, niet welke interface hem droeg, dus voer de opname op de host zelf uit en kijk waar de frames vertrekken. Een printer op hetzelfde subnet blijft antwoorden, omdat zijn directe route specifieker is dan de standaardroute van de tunnel. Een doorgestuurde poort faalt precies zoals elke andere stroom, omdat de tabel de interface kiest en de verbinding niet.

Installeer de smalste route die de tunnel verslaat

De prefixlengte beslist, niet de metriek, dus een route voor de clientpool via de LAN-router wint van elke standaardroute die de VPN-client installeert. Metriekchirurgie is niet nodig, en de standaardroute kan precies blijven waar de client hem heeft neergezet.

ip route replace 10.64.0.0/24 via 172.16.24.1 dev eth0
ip route get 10.64.0.23 from 172.16.24.10

Gebruik replace in plaats van add, omdat een client die opnieuw verbindt zijn eigen vermelding al heeft geïnstalleerd en een tweede add faalt met een fout over een bestaande route die leest als een rechtenprobleem. Op een Windows-host is het equivalent route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p, waarbij -p de vermelding over herstarts heen bewaart, omdat de client de tabel opnieuw kan opbouwen wanneer de tunnel weer opkomt. Op een moderne Windows-host is het ondersteunde equivalent New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore, terwijl het oudere route-commando als oude vorm behouden blijft.

Eén detail beslist of dit juist is of slechts aannemelijk: de volgende hop moet de router zijn die werkelijk de weg terug naar de clients bezit. De route naar een adres wijzen dat zelf via de tunnel wordt bereikt, maakt een lus die zich als periodiek verlies voordoet in plaats van als een schone fout. Bevestig dat de volgende hop op het LAN-subnet ligt voordat u de regel vastlegt.

Behoud het antwoord na een herverbinding

Een met de hand toegevoegde route overleeft op zijn best tot de volgende herverbinding. Als de clientpool dynamisch is, zet hem dan vast in de serverconfiguratie zodat de prefix die u hebt gerouteerd de prefix blijft die clients ontvangen; anders wijst de vermelding naar een leeg bereik en komt het symptoom weken later terug zonder duidelijke oorzaak. De route in het eigen up-script van de client schrijven is de andere betrouwbare optie, omdat het draait nadat de client de tabel heeft herschreven.

Een stateful firewall kan een juiste route nog steeds verslaan. Als de opname nu laat zien dat het antwoord via eth0 vertrekt en de client loopt nog steeds in een time-out, controleer dan of de host het pakket vóór verzending weggooit. Strikte reverse-path-filtering en net.ipv4.conf.all.rp_filter op 1 gezet gooien pakketten weg waarvan de bron niet via de interface zou worden teruggerouteerd waarop ze aankwamen, en dat is precies het asymmetrische geval dat u zojuist hebt gemaakt en daarna hebt opgelost, en de conntrack-status vertelt hetzelfde verhaal voor doorgestuurde poorten.

De laatste controle is degene die mensen overslaan: herhaal de opzoeking nadat de tunnel omlaag en weer omhoog is geweest. Vier waarden moeten overeenkomen met wat u hebt opgeschreven: de bestemming, de volgende hop, het apparaat en de gekozen bron. Als een ervan is verschoven, heeft de client de tabel herschreven en hoort de oplossing in zijn hooks en niet in een shell-geschiedenis.