Prístup do LAN cez OpenVPN nefunguje? Skontrolujte zóny, trasy a spiatočnú cestu

Tunel hlási úspešné pripojenie, stránka samotného routera sa načíta, a mapovanie disku na počítač za ním stále vyprší. V tejto kombinácii nie je nič protirečivé: router odpovedá ako on sám a dosiahnuť niečo za ním je iné rozhodnutie prijaté na inom mieste. Prejdite kontroly nižšie v poradí a zastavte sa pri prvom zlyhaní, pretože každá stojí na predchádzajúcej. Keď prejdú všetky štyri, porucha je nad tunelom, nie v ňom.

Ktorý filter vidí paket určený pre LAN

Paket adresovaný routeru sa spotrebuje lokálne; paket adresovaný hostiteľovi za ním sa musí preposlať, a firewally tieto dva prípady posudzujú oddelene. Povolenie dostať sa k routeru teda nehovorí nič o povolení prejsť cezeň. Firmvér, ktorý skrýva svoje sady pravidiel, napriek tomu implementuje oboje, zvyčajne ako volič ponúkajúci LAN, internet alebo oboje. Ak volič vynechá LAN, žiadna ďalšia kontrola už nebude dôležitá.

OpenWrt robí toto rozdelenie preskúmateľným a rozdiel stojí za jedno prečítanie. Zóna, ktorá ukončuje tunel, potrebuje pravidlo preposielania do zóny LAN, zatiaľ čo vstupné pravidlo riadi len služby na samotnom routeri. Fungujúca administračná stránka vedľa mŕtvej LAN je obvyklým výsledkom chýbajúceho pravidla preposielania.

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

Pozrite sa na cieľ preposielania zóny, ktorá nesie tunel: accept je to, čo rebrík potrebuje, a reject vysvetľuje každé vypršanie nižšie. Dve susedné nastavenia dávajú rovnaký príznak, preto ich tu vylúčte. Bezdrôtová izolácia skrýva káblových hostiteľov pred bezdrôtovými klientmi a router, ktorý nečinných hostiteľov LAN považuje za offline, môže odpovede zahodiť aj po tom, ako preposielanie funguje.

Prečo delený tunel potrebuje pretlačený prefix

Klient, ktorý posiela všetku prevádzku cez tunel, už má prefix LAN vďaka svojej predvolenej trase, takže nie je čo pridávať. Delený tunel je prípad, ktorý vyžaduje výslovné uvedenie prefixu, pretože nič iné v konfigurácii ho nespomína. Pridajte direktívu do konfigurácie servera a znova načítajte službu.

push "route 192.168.50.0 255.255.255.0"

Profily obsahujúce route-nopull ignorujú pretlačené trasy, takže rovnaký prefix patrí do súboru klienta. V každom prípade potvrďte, že záznam dorazil, namiesto toho, aby ste to predpokladali, pretože tiché prepísanie vyzerá rovnako ako problém s firewallom.

ip route show | grep 192.168.50

Partner lokalita-lokalita žiada viac než pretlačenie. Server sa musí naučiť, ktoré prefixy sú za týmto partnerom, čo robí riadok iroute v jeho súbore client-config-dir, a jeho vlastná tabuľka potrebuje zodpovedajúcu trasu do tunela.

Odpoveď potrebuje adresu, na ktorú sa dostane

Preposlanie požiadavky je len polovica výmeny, pretože hostiteľ LAN musí odpovedať na adresu z fondu tunela. Malé routery to zvyčajne riešia prekladom zdroja v zóne tunela, takže odpoveď je adresovaná routeru a nepotrebuje konfiguráciu inde. Odstráňte tento preklad a hostiteľ potrebuje vlastnú trasu do fondu, ktorú získa zadarmo, keď je router jeho predvolenou bránou. Hostiteľ s ručne nastavenou adresou a inou bránou odpovedá cez tú bránu a klient vidí, ako sa relácia otvorí a potom zasekne.

tcpdump -ni tun0 host 192.168.50.20

Spustite to na routeri, kým klient opakuje svoju požiadavku, a čítajte cieľ odpovede, nie samotnú požiadavku. Odpoveď adresovaná fondu znamená, že spiatočná cesta funguje a porucha je hlbšie. Úplná absencia odpovede znamená, že hostiteľ paket nikdy neprijal, čo vás vráti k sade pravidiel.

Rebrík, ktorý končí na správnom mieste

Štyri kontroly určujú vrstvu a každá je jediný príkaz, nie úsudok. Spustite ich v poradí a zastavte sa pri prvom zlyhaní. Poradie je dôležitejšie ako príkazy, pretože úspešný neskorší krok skrýva dôvod zlyhania skoršieho.

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

Mená patria na koniec rebríka, nikdy na začiatok. Zdieľanie, ktoré odpovedá ako 192.168.50.20, ale nie ako nas.local, ukazuje na preklad mien alebo na príponu hľadania, a úpravy firewallu nemôžu zmeniť ani jedno.

Zaznamenajte prvý neúspešný krok, potom dajte portom služieb vlastný priechod, pretože počúvajúci proces a povolenie hostiteľa sú oddelené požiadavky. Zdieľanie súborov, vzdialená plocha a streamy z kamier potrebujú oboje a firewall hostiteľa, ktorý dôveruje podsieti LAN, ale nie fondu tunela, zahodí klienta, kým ping ešte prechádza. Keď všetky kontroly prejdú a aplikácia stále zlyháva, porucha je nad tunelom: služba viazaná na jedno rozhranie alebo proxy nastavené na klientovi.