VPN verbindt, maar LAN-apparaten zijn niet bereikbaar: wat je moet controleren

Verkeer komt de tunnel binnen, de gateway antwoordt op zijn eigen adres en niets erachter antwoordt. Dat patroon is gebruikelijk en het is geen tegenspraak: een antwoord van de gateway bewijst dat de tunnel is beëindigd, en het bewijst niets over wat er gebeurt met een pakket dat er voorbij is geadresseerd. De twee tests gebruiken verschillende codepaden op dezelfde machine.

Test vanaf nu iets aan de andere kant van de gateway. Het eigen adres van de gateway blijft antwoorden, hoe kapot de doorsturing ook is.

De gateway antwoordt uit zijn eigen stack

Een pakket dat aan de gateway is geadresseerd, wordt aan zijn lokale invoerpad afgeleverd, waar de kernel beslist of een luisterende socket het accepteert. Een pakket dat aan een host achter de gateway is geadresseerd, wordt in plaats daarvan aan het doorstuurpad afgeleverd, waar een andere reeks controles geldt. Doorsturen kan volledig zijn uitgeschakeld, of door de kernel zijn ingeschakeld en vervolgens door een filterregel die de tunnel nooit noemt worden afgewezen. Niets daarvan beïnvloedt het eigen antwoord van de gateway, daarom misleidt het symptoom zo betrouwbaar.

Beheerpagina’s die via de tunnel worden bereikt, horen ook bij de eerste categorie. Ze zijn bewijs over de tunnel, niet over het netwerk erachter.

Volg de stroom tot de eerste grens die hem laat vallen

Begin bij de client en bevestig de route en het bronadres dat de stroom zal gebruiken. Kijk dan op de gateway naar de aankomst van precies die stroom, en opnieuw naar dezelfde stroom die richting LAN vertrekt. Als die nooit aankomt, ligt het probleem aan de clientkant of bij de toegestane prefixen van de tunnel. Als die aankomt en nooit vertrekt, ligt het probleem bij het doorsturen of bij een filter op het voorwaartse pad, en de opname heeft al gezegd welke van de twee.

Dezelfde test vanaf de gateway uitvoeren verbergt de interessante helft, omdat een pakket dat van de gateway afkomstig is een andere bron en een andere retourvereiste heeft. Gebruik de stroom van de client, met zijn eigen bronadres, bij elke stap. Een opname op de verkeerde interface levert zelfverzekerde onzin.

Retourroutes en host-firewalls falen afzonderlijk

Zodra het pakket de host bereikt, moeten er nog drie dingen gelden. De dienst moet luisteren op het adres waarnaar het pakket is verzonden, de firewall van de host moet het accepteren, en het antwoord moet een route terug naar de clientpool hebben. Dat laatste faalt vaak, omdat de standaardroute van de host wijst naar een router die nog nooit van het tunnelbereik heeft gehoord. Het resultaat is een verbinding die vanuit het perspectief van de host tot stand komt en in de andere richting stil sterft.

Test het retourpad bewust door vanaf de client te sturen en op de terugkeer te letten. Een eenrichtingsopname beslist in seconden wat een uur speculatie niet zal beslissen.

Bevestig elke hop met het bronadres van de client

Voer de controles in volgorde uit en bewaar elke uitvoer, want de waarde zit in de vergelijking en niet in één enkele regel. De opdrachten hieronder zetten het bronadres vast, tonen de gekozen route en leggen beide kanten van het doorsturen vast. Vervang je eigen LAN-host en tunnelinterface.

ip route get 192.168.50.20 from 10.8.0.2
ping -I 10.8.0.2 -c 3 192.168.50.20
sudo tcpdump -ni tun0 host 192.168.50.20
sudo tcpdump -ni br0 host 192.168.50.20

De routequery laat zien of de client dat pakket überhaupt de tunnel in zou sturen, en de ping laat zien of er iets van de host terugkwam. Het vergelijken van de twee opnamen scheidt aankomst van vertrek, want een frame op de tunnelinterface zonder tegenhanger op de LAN-interface is een beslissing over doorsturen en geen dienststoring. Wanneer beide opnamen het verzoek tonen en slechts één het antwoord, is de retourroute de overgebleven verdachte.

Noteer welk adres antwoordde en welke doorgestuurde bestemming faalde. Die zin maakt het rapport uitvoerbaar in plaats van de bewering dat de server onbereikbaar is.