Geen LAN-toegang via OpenVPN? Controleer zones, routes en retourpad

De tunnel meldt een geslaagde verbinding, de eigen pagina van de router laadt, en de netwerkschijf naar een machine erachter loopt nog steeds vast. Niets aan die combinatie is tegenstrijdig: de router antwoordt als zichzelf, en iets erachter bereiken is een andere beslissing die ergens anders wordt genomen. Werk de controles hieronder in volgorde af en stop bij de eerste fout, want elke controle rust op de vorige. Als alle vier slagen, zit de fout boven de tunnel en niet erin.

Welk filter ziet een pakket richting het LAN

Een pakket dat aan de router is geadresseerd, wordt lokaal verbruikt; een pakket dat aan een host erachter is geadresseerd, moet worden doorgestuurd, en firewalls beoordelen die twee gevallen apart. Toestemming om de router te bereiken zegt dus niets over toestemming om hem te passeren. Firmware die zijn regelsets verbergt, implementeert beide nog steeds, meestal als keuzemogelijkheid met het LAN, internet of beide. Als de keuze het LAN weglaat, doet geen enkele latere controle ertoe.

OpenWrt maakt die splitsing inspecteerbaar, en het onderscheid is één keer lezen waard. De zone die de tunnel beëindigt, heeft een doorstuurregel naar de LAN-zone nodig, terwijl een invoerregel alleen diensten op de router zelf regelt. Een werkende beheerpagina naast een dood LAN is het gewone gevolg van die ontbrekende doorstuurregel.

uci show firewall | grep -E "zone\[[0-9]+\]\.(name|input|forward|output)"

Kijk naar het doorstuurdoel van de zone die de tunnel draagt: accept is wat de ladder nodig heeft, en reject verklaart elke time-out hieronder. Twee naburige instellingen geven hetzelfde symptoom, sluit ze dus uit terwijl je hier bent. Draadloze isolatie verbergt bedrade hosts voor draadloze clients, en een router die inactieve LAN-hosts als offline behandelt, kan de antwoorden alsnog laten vallen nadat het doorsturen werkt.

Waarom een gesplitste tunnel het gepushte prefix nodig heeft

Een client die al het verkeer door de tunnel stuurt, heeft het LAN-prefix al via zijn standaardroute, dus er valt niets toe te voegen. De gesplitste tunnel is het geval dat het prefix uitdrukkelijk vereist, omdat niets anders in de configuratie het noemt. Voeg de richtlijn toe aan de serverconfiguratie en herlaad de dienst.

push "route 192.168.50.0 255.255.255.0"

Profielen die route-nopull bevatten, negeren gepushte routes, dus hetzelfde prefix hoort in het clientbestand. Bevestig in elk geval dat de vermelding is aangekomen in plaats van het aan te nemen, want een stille overschrijving ziet er precies zo uit als een firewallprobleem.

ip route show | grep 192.168.50

Een site-naar-site-partner vraagt meer dan een push. De server moet leren welke prefixen achter die partner liggen, wat een iroute-regel in zijn client-config-dir-bestand doet, en zijn eigen tabel heeft een passende route de tunnel in nodig.

Het antwoord heeft een adres nodig dat het kan bereiken

Het verzoek doorsturen is maar de helft van een uitwisseling, want de LAN-host moet antwoorden op een adres in de tunnelpool. Kleine routers regelen dat meestal door de bron op de tunnelzone te vertalen, zodat het antwoord aan de router is gericht en nergens anders configuratie nodig heeft. Verwijder die vertaling en de host heeft zijn eigen route naar de pool nodig, die hij gratis krijgt wanneer de router zijn standaardgateway is. Een host met een handmatig adres en een andere gateway antwoordt via die gateway, en de client ziet een sessie opengaan en daarna stokken.

tcpdump -ni tun0 host 192.168.50.20

Voer dit op de router uit terwijl de client zijn verzoek herhaalt, en lees de bestemming van het antwoord in plaats van het verzoek. Een antwoord aan de pool betekent dat de retourweg werkt en dat de fout dieper zit. Geen enkel antwoord betekent dat de host het pakket nooit heeft aangenomen, wat je terugstuurt naar de regelset.

Een ladder die op de juiste plek eindigt

Vier controles lokaliseren de laag, en elk is één commando in plaats van een oordeel. Voer ze in volgorde uit en stop bij de eerste fout. De volgorde is belangrijker dan de commando's, want een latere stap die slaagt verbergt de reden waarom een eerdere faalde.

ping -c1 10.8.0.1
ping -c1 192.168.50.20
nc -vz 192.168.50.20 445
getent hosts nas.local

Namen horen aan het einde van de ladder, nooit aan het begin. Een share die antwoordt als 192.168.50.20 maar niet als nas.local wijst op naamresolutie of een zoeksuffix, en firewallaanpassingen kunnen geen van beide veranderen.

Noteer de eerste mislukte stap en geef de servicepoorten daarna hun eigen ronde, want een listener en een hosttoestemming zijn aparte vereisten. Bestandsdeling, extern bureaublad en camerastreams hebben beide nodig, en een hostfirewall die het LAN-subnet vertrouwt maar niet de tunnelpool, laat de client vallen terwijl ping nog slaagt. Wanneer alle controles slagen en de toepassing toch faalt, zit de fout boven de tunnel: een dienst die aan één interface is gebonden, of een proxy die op de client is geconfigureerd.