Přístup do LAN přes OpenVPN nefunguje? Zkontrolujte zóny, trasy a zpáteční cestu

Tunel hlásí úspěšné připojení, stránka samotného routeru se načte, a mapování disku na počítač za ním stále vyprší. V této kombinaci není nic protichůdného: router odpovídá sám za sebe a dosažení čehokoli za ním je jiné rozhodnutí učiněné na jiném místě. Proveďte níže uvedené kontroly v pořadí a zastavte se u prvního selhání, protože každá stojí na předchozí. Když projdou všechny čtyři, závada je nad tunelem, ne v něm.

Který filtr vidí paket určený pro LAN

Paket adresovaný routeru se spotřebuje lokálně; paket adresovaný hostiteli za ním se musí předat, a firewally tyto dva případy posuzují odděleně. Povolení dosáhnout router tedy nic neříká o povolení projít skrz. Firmware, který skrývá své sady pravidel, přesto obojí implementuje, obvykle jako volič nabízející LAN, internet nebo obojí. Pokud volič LAN vynechá, žádná další kontrola už nebude důležitá.

OpenWrt činí toto rozdělení prohlédnutelným a rozdíl stojí za jedno přečtení. Zóna, která ukončuje tunel, potřebuje pravidlo předávání směřující do zóny LAN, zatímco vstupní pravidlo řídí jen služby na samotném routeru. Fungující administrační stránka vedle mrtvé LAN je obvyklým výsledkem chybějícího pravidla předávání.

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

Podívejte se na cíl předávání zóny, která nese tunel: accept je to, co žebřík potřebuje, a reject vysvětluje každé vypršení níže. Dvě sousední nastavení dávají stejný příznak, takže je zde rovnou vylučte. Bezdrátová izolace skrývá kabelové hostitele před bezdrátovými klienty a router, který nečinné hostitele LAN považuje za offline, může odpovědi zahazovat i poté, co předávání funguje.

Proč rozdělený tunel potřebuje protlačený prefix

Klient, který posílá veškerý provoz tunelem, už prefix LAN má díky své výchozí trase, takže není co přidávat. Rozdělený tunel je případ, který vyžaduje výslovné uvedení prefixu, protože nic jiného v konfiguraci ho nezmiňuje. Přidejte direktivu do konfigurace serveru a znovu načtěte službu.

push "route 192.168.50.0 255.255.255.0"

Profily obsahující route-nopull ignorují protlačené trasy, takže stejný prefix patří do souboru klienta. V každém případě potvrďte, že záznam dorazil, místo abyste to předpokládali, protože tiché přepsání vypadá stejně jako problém s firewallem.

ip route show | grep 192.168.50

Protějšek síť-síť žádá víc než protlačení. Server se musí naučit, které prefixy jsou za tímto protějškem, což dělá řádek iroute v jeho souboru client-config-dir, a jeho vlastní tabulka potřebuje odpovídající trasu do tunelu.

Odpověď potřebuje adresu, na kterou dosáhne

Předání požadavku je jen polovina výměny, protože hostitel LAN musí odpovědět na adresu z fondu tunelu. Malé routery to obvykle zařizují překladem zdroje v zóně tunelu, takže odpověď je adresována routeru a nepotřebuje konfiguraci jinde. Odstraňte tento překlad a hostitel potřebuje vlastní trasu do fondu, kterou zdarma získá, když je router jeho výchozí bránou. Hostitel s ručně nastavenou adresou a jinou bránou odpovídá přes tuto bránu a klient sleduje, jak se relace otevře a pak se zasekne.

tcpdump -ni tun0 host 192.168.50.20

Spusťte to na routeru, zatímco klient opakuje svůj požadavek, a čtěte cílovou adresu odpovědi, ne samotného požadavku. Odpověď adresovaná fondu znamená, že zpáteční cesta funguje a závada je hlouběji. Úplná absence odpovědi znamená, že hostitel paket nikdy nepřijal, což vás vrací k sadě pravidel.

Žebřík, který končí na správném místě

Čtyři kontroly určují vrstvu a každá je jediný příkaz, ne úsudek. Spusťte je v pořadí a zastavte se u prvního selhání. Pořadí je důležitější než příkazy, protože úspěšný pozdější krok skrývá důvod selhání dřívějšího.

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

Jména patří na konec žebříku, nikdy na začátek. Sdílená složka, která odpovídá jako 192.168.50.20, ale ne jako nas.local, ukazuje na překlad jmen nebo na příponu hledání, a úpravy firewallu nemohou změnit ani jedno.

Zaznamenejte první selhaný krok, poté dejte portům služeb vlastní průchod, protože naslouchající proces a povolení hostitele jsou oddělené požadavky. Sdílení souborů, vzdálená plocha a streamy z kamer potřebují obojí a firewall hostitele, který důvěřuje podsíti LAN, ale ne fondu tunelu, zahodí klienta, zatímco ping stále prochází. Když všechny kontroly projdou a aplikace stále selhává, závada je nad tunelem: služba vázaná na jedno rozhraní nebo proxy nastavená na klientovi.