OpenVPN LAN-toegang stukkend? Kontroleer sones, roetes en terugpad

Die tonnel meld 'n suksesvolle verbinding, die roeteerder se eie bladsy laai, en 'n skyfkoppeling na 'n masjien agter hom verstryk steeds. Niks in dié kombinasie is teenstrydig nie: die roeteerder antwoord as homself, en om iets agter hom te bereik is 'n ander besluit wat op 'n ander plek geneem word. Werk die kontroles hieronder in volgorde deur en stop by die eerste fout, want elkeen berus op die een voor hom. Wanneer al vier slaag, sit die fout bo die tonnel eerder as binne-in dit.

Watter filter sien 'n pakket na die LAN

'n Pakket gerig aan die roeteerder word plaaslik verteer; 'n pakket gerig aan 'n gasheer agter hom moet aangestuur word, en firewalls beoordeel dié twee gevalle afsonderlik. Toestemming om die roeteerder te bereik sê dus niks oor toestemming om dit te kruis nie. Firmware wat sy reëlstelle verberg, implementeer steeds albei, gewoonlik as 'n keuse wat die LAN, die internet of albei bied. As die keuse die LAN uitlaat, sal geen latere kontrole saak maak nie.

OpenWrt maak die verdeling ondersoekbaar, en die onderskeid is werd om een keer te lees. Die sone wat die tonnel termineer, het 'n aanstuur-reël nodig wat na die LAN-sone wys, terwyl 'n invoerreël slegs dienste op die roeteerder self beheer. 'n Werkende administrasiebladsy langs 'n dooie LAN is die gewone gevolg van daardie ontbrekende aanstuur-reël.

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

Kyk na die aanstuur-teiken van die sone wat die tonnel dra: accept is wat die leer nodig het, en reject verduidelik elke verstryking hieronder. Twee naburige instellings veroorsaak dieselfde simptoom, so skakel hulle hier uit terwyl jy hier is. Draadlose isolasie verberg bedrade gashere vir draadlose kliënte, en 'n roeteerder wat ledige LAN-gashere as vanlyn beskou, kan die antwoorde laat val selfs nadat aanstuur werk.

Waarom 'n gesplete tonnel die voorvoegsel nodig het

'n Kliënt wat alle verkeer deur die tonnel stuur, het die LAN-voorvoegsel reeds deur sy verstekroete, so daar is niks om by te voeg nie. 'n Gesplete tonnel is die geval wat die voorvoegsel eksplisiet vereis, want niks anders in die konfigurasie noem dit nie. Voeg die richtlijn by die bedienerkonfigurasie en herlaai die diens.

push "route 192.168.50.0 255.255.255.0"

Profiele wat route-nopull bevat, ignoreer aangestuurde roetes, so dieselfde voorvoegsel hoort eerder in die kliëntlêer. Bevestig in elk geval dat die inskrywing aangekom het eerder as om dit te aanvaar, want 'n stil oorskrywing lyk identies aan 'n firewallprobleem.

ip route show | grep 192.168.50

'n Werf-tot-werf-eweknie vra meer as 'n push. Die bediener moet leer watter voorvoegsels agter daardie eweknie sit, wat 'n iroute-reël in sy client-config-dir-lêer doen, en sy eie tabel het 'n ooreenstemmende roete in die tonnel nodig.

Die antwoord het 'n adres nodig wat dit kan bereik

Om die versoek aan te stuur is slegs die helfte van 'n uitruiling, want die LAN-gasheer moet 'n adres in die tonnelpoel antwoord. Klein roeteerders reël dit gewoonlik deur die bron op die tonnel-sone te vertaal, so die antwoord word aan die roeteerder gerig en het nêrens anders konfigurasie nodig nie. Verwyder daardie vertaling en die gasheer benodig sy eie roete na die poel, wat hy gratis kry wanneer die roeteerder sy verstekportaal is. 'n Gasheer met 'n handmatig ingestelde adres en 'n ander portaal antwoord eerder deur daardie portaal, en die kliënt sien 'n sessie oopgaan en dan stagneer.

tcpdump -ni tun0 host 192.168.50.20

Voer dit op die roeteerder uit terwyl die kliënt sy versoek herhaal, en lees die bestemming van die antwoord eerder as die versoek self. 'n Antwoord aan die poel beteken die terugpad werk en die fout is verder in. Geen antwoord hoegenaamd beteken die gasheer het die pakket nooit aanvaar nie, wat jou terugstuur na die reëlstel.

'n Leer wat op die regte plek eindig

Vier kontroles lokaliseer die laag, en elkeen is 'n enkele opdrag eerder as 'n oordeel. Voer hulle in volgorde uit en stop by die eerste fout. Die volgorde maak meer saak as die opdragte, want 'n slaag later verberg die rede waarom 'n vroeëre een misluk het.

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

Name hoort aan die einde van die leer, nooit aan die begin nie. 'n Deling wat as 192.168.50.20 antwoord maar nie as nas.local nie, wys op resolusie of op 'n soek-agtervoegsel, en firewall-wysigings kan nie een van dié verander nie.

Teken die eerste mislukte stap aan, gee dan dienspoorte hul eie ronde, want 'n luisteraar en 'n gasheer-toestemming is aparte vereistes. Lêerdeling, afstandbeheer oor die skerm en kamerastrome het elkeen albei nodig, en 'n gasheer-firewall wat die LAN-subnet vertrou maar nie die tonnelpoel nie, laat die kliënt val terwyl ping steeds slaag. Wanneer elke kontrole slaag en die toepassing steeds misluk, sit die fout bo die tonnel: 'n diens wat aan een koppelvlak gebind is, of 'n instaanbediener wat op die kliënt gekonfigureer is.