OpenVPN LAN-tilgang øydelagd? Sjekk soner, ruter og returveg

Tunnelen rapporterer ei vellukka tilkopling, sida til rutaren sjølv blir lasta, og stasjonskartlegginga til ei maskin bak han går framleis ut på tid. Ingenting i den kombinasjonen er sjølvmotsigande: rutaren svarar som seg sjølv, og å nå noko bak han er eit anna vedtak som blir teke på ein annan stad. Gå gjennom kontrollane nedanfor i rekkjefølgje og stopp ved første feil, fordi kvar av dei kviler på den førre. Når alle fire passerer, ligg feilen over tunnelen og ikkje i han.

Kva filter ser ein pakke på veg til LAN-et

Ein pakke adressert til rutaren blir brukt lokalt; ein pakke adressert til ein vert bak han må vidaresendast, og brannmurar vurderer dei to tilfella kvar for seg. Løyve til å nå rutaren seier derfor ingenting om løyve til å krysse han. Fastvare som gøymer regelsetta sine, implementerer likevel båe, vanlegvis som ein veljar med LAN, internett eller båe. Viss veljaren utelèt LAN-et, vil ingen seinare kontroll bety noko.

OpenWrt gjer denne delinga etterprøvbar, og skilnaden er verdt éi gjennomlesing. Sona som avsluttar tunnelen treng ei vidaresendingsregel mot LAN-sona, medan ei inngangsregel berre styrer tenester på rutaren sjølv. Ei fungerande administrasjonsside ved sida av eit dødt LAN er det vanlege resultatet av den manglande vidaresendingsregelen.

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

Sjå på vidaresendingsmålet til sona som ber tunnelen: accept er det stigen treng, og reject forklarer kvar tidsavbrot nedanfor. To nærliggande innstillingar gir same symptom, så utelukk dei medan du er her. Trådlaus isolasjon gøymer kabelbundne vertar for trådlause klientar, og ein rutar som behandlar inaktive LAN-vertar som fråkopla, kan sleppe svara sjølv etter at vidaresendinga verkar.

Kvifor ein delt tunnel treng det pusha prefikset

Ein klient som sender all trafikk gjennom tunnelen har allereie LAN-prefikset gjennom standardruta si, så det er ingenting å leggje til. Ein delt tunnel er tilfellet som krev at prefikset blir sagt eksplisitt, fordi ingenting anna i konfigurasjonen nemner det. Legg direktivet til serverkonfigurasjonen og last tenesta på nytt.

push "route 192.168.50.0 255.255.255.0"

Profilar som inneheld route-nopull ignorerer pusha ruter, så same prefiks høyrer i klientfila i staden. Stadfest uansett at oppføringa kom fram i staden for å gå ut frå det, fordi ei stille overstyring ser identisk ut med eit brannmurproblem.

ip route show | grep 192.168.50

Ein site-til-site-partnar ber om meir enn ein push. Serveren må lære kva prefiks som ligg bak den partnaren, noko ei iroute -linje i client-config-dir-fila gjer, og tabellen hans treng ei samsvarande rute inn i tunnelen.

Svaret treng ei adresse det kan nå

Vidaresending av førespurnaden er berre halve utvekslinga, fordi LAN-verten må svare på ei adresse i tunnelpoolen. Små rutarar ordnar det vanlegvis ved å oversetje kjelda på tunnelsona, slik at svaret er adressert til rutaren og ikkje treng konfigurasjon andre stader. Fjern den oversetjinga, og verten treng si eiga rute til poolen, som han får gratis når rutaren er standardgatewayen. Ein vert med handsett adresse og ein annan gateway svarar gjennom den gatewayen i staden, og klienten ser ei økt opne seg og deretter stogge.

tcpdump -ni tun0 host 192.168.50.20

Køyr dette på rutaren medan klienten gientar førespurnaden, og les destinasjonen til svaret i staden for førespurnaden. Eit svar adressert til poolen betyr at returvegen verkar og at feilen er lenger inne. Helt utan svar betyr at verten aldri tok imot pakken, noko som sender deg tilbake til regelsettet.

Ein stige som endar på rett stad

Fire kontrollar lokaliserer laget, og kvar er éin kommando i staden for ei vurdering. Køyr dei i rekkjefølgje og stopp ved første feil. Rekkjefølgja betyr meir enn kommandoane, fordi eit seinare trinn som passerer gøymer årsaka til at eit tidlegare feila.

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

Namn høyrer heime på slutten av stigen, aldri i byrjinga. Ei deling som svarar som 192.168.50.20 men ikkje som nas.local, peikar på namneoppslag eller eit søkjetillegg, og brannmur-endringar kan ikkje endre nokon av dei.

Noter det første trinnet som feila, og gi deretter tenesteportane sin eigen runde, fordi ein lyttar og ein vertsløyve er separate krav. Fildeling, eksternt skrivebord og kamerastraumar treng båe, og ein vertsbrannmur som stolar på LAN-subnettet men ikkje tunnelpoolen, slepper klienten medan ping framleis lukkast. Når alle kontrollar passerer og programmet framleis feilar, ligg feilen over tunnelen: ei teneste bunden til eitt grensesnitt, eller ein proxy konfigurert på klienten.