OpenVPN LAN-tilgang ødelagt? Sjekk soner, ruter og returvei

Tunnelen rapporterer en vellykket tilkobling, ruteren sin egen side lastes, og stasjonskartleggingen til en maskin bak den går fortsatt ut på tid. Ingenting i den kombinasjonen er selvmotsigende: ruteren svarer som seg selv, og å nå noe bak den er en annen beslutning som tas et annet sted. Gå gjennom kontrollene nedenfor i rekkefølge og stopp ved første feil, fordi hver av dem hviler på den forrige. Når alle fire passerer, ligger feilen over tunnelen og ikke i den.

Hvilket filter ser en pakke på vei til LAN-et

En pakke adressert til ruteren forbrukes lokalt; en pakke adressert til en vert bak den må videresendes, og brannmurer vurderer de to tilfellene hver for seg. Tillatelse til å nå ruteren sier derfor ingenting om tillatelse til å krysse den. Fastvare som skjuler regelsettene sine implementerer likevel begge, vanligvis som en velger med LAN, internett eller begge. Hvis velgeren utelater LAN-et, vil ingen senere kontroll bety noe.

OpenWrt gjør denne delingen etterprøvbar, og forskjellen er verdt én gjennomlesning. Sonen som avslutter tunnelen trenger en videresendingsregel mot LAN-sonen, mens en inngangsregel bare styrer tjenester på ruteren selv. En fungerende administrasjonsside ved siden av et dødt LAN er det vanlige resultatet av den manglende videresendingsregelen.

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

Se på videresendingsmålet til sonen som bærer tunnelen: accept er det stigen trenger, og reject forklarer hver tidsavbrudd nedenfor. To nærliggende innstillinger gir samme symptom, så utelukk dem mens du er her. Trådløs isolasjon skjuler kablede verter for trådløse klienter, og en ruter som behandler inaktive LAN-verter som frakoblet, kan droppe svarene selv etter at videresendingen virker.

Hvorfor en delt tunnel trenger det pusha prefikset

En klient som sender all trafikk gjennom tunnelen har allerede LAN-prefikset gjennom standardruten sin, så det er ingenting å legge til. En delt tunnel er tilfellet som krever at prefikset angis eksplisitt, fordi ingenting annet i konfigurasjonen nevner det. Legg direktivet til serverkonfigurasjonen og last tjenesten på nytt.

push "route 192.168.50.0 255.255.255.0"

Profiler som inneholder route-nopull ignorerer pusha ruter, så samme prefiks hører i klientfilen i stedet. Bekreft uansett at oppføringen kom frem i stedet for å anta det, fordi en stille overstyring ser identisk ut med et brannmurproblem.

ip route show | grep 192.168.50

En site-til-site-partner ber om mer enn en push. Serveren må lære hvilke prefikser som ligger bak den partneren, noe en iroute -linje i client-config-dir-filen gjør, og dens egen tabell trenger en samsvarende rute inn i tunnelen.

Svaret trenger en adresse det kan nå

Videresending av forespørselen er bare halve utvekslingen, fordi LAN-verten må svare på en adresse i tunnelpoolen. Små rutere ordner det vanligvis ved å oversette kilden på tunnelsonen, slik at svaret er adressert til ruteren og ikke trenger konfigurasjon andre steder. Fjern den oversettelsen, og verten trenger sin egen rute til poolen, som den får gratis når ruteren er standardgatewayen. En vert med håndsatt adresse og en annen gateway svarer gjennom den gatewayen i stedet, og klienten ser en økt åpne seg og deretter stoppe.

tcpdump -ni tun0 host 192.168.50.20

Kjør dette på ruteren mens klienten gjentar forespørselen, og les svarets destinasjon i stedet for forespørselen. Et svar adressert til poolen betyr at returveien virker og at feilen er lenger inne. Helt uten svar betyr at verten aldri tok imot pakken, noe som sender deg tilbake til regelsettet.

En stige som ender på riktig sted

Fire kontroller lokaliserer laget, og hver er én kommando i stedet for en vurdering. Kjør dem i rekkefølge og stopp ved første feil. Rekkefølgen betyr mer enn kommandoene, fordi et senere trinn som passerer skjuler årsaken til at et tidligere feilet.

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

Navn hører hjemme på slutten av stigen, aldri i begynnelsen. En deling som svarer som 192.168.50.20 men ikke som nas.local, peker på navneoppslag eller et søketillegg, og brannmur-endringer kan ikke endre noen av dem.

Noter det første trinnet som feilet, og gi deretter tjenesteportene sin egen runde, fordi en lytter og en vertstillatelse er separate krav. Fildeling, eksternt skrivebord og kamerastrømmer trenger begge, og en vertsbrannmur som stoler på LAN-subnettet men ikke tunnelpoolen, dropper klienten mens ping fortsatt lykkes. Når alle kontroller passerer og programmet fortsatt feiler, ligger feilen over tunnelen: en tjeneste bundet til ett grensesnitt, eller en proxy konfigurert på klienten.