Připojeni k OpenVPN, ale žádný ping ani SMB sdílení? Prověřte tři brány

Tunel se zvedne, klient dostane adresu a nic na vzdálené LAN neodpovídá. Ping selhává, sdílení se neotevře a protokol VPN vypadá čistě, protože z jeho pohledu je relace zdravá. Mezi touto relací a souborem na serveru stojí tři nezávislé brány: politika forwardování, porty, které služba potřebuje, a jméno, které jste napsali místo adresy.

Každá brána selhává s jiným příznakem a jen ta první je na serveru VPN.

Forwardování je politika na řetězu FORWARD

Přijetí listeneru OpenVPN probíhá na INPUT, a proto se tunel může připojit, i když se každý paket směřující do LAN zahodí. Provoz, který přichází na tun0 a odchází přes rozhraní LAN, prochází FORWARD, a hostitel s výchozí politikou DROP ho tam tiše zahodí. Než sáhnete na cokoli jiného, zkontrolujte sysctl i řetěz: sysctl net.ipv4.ip_forward a iptables -L FORWARD -v -n.

Povolte směr, který zamýšlíte, i odpovědi, které k němu patří, například pravidlo accept z rozhraní tunelu do rozhraní LAN plus stateful pravidlo pro established a related provoz. Pokud LAN stojí za dalším routerem, ten router potřebuje cestu zpět do poolu klientů nebo source NAT na serveru VPN. Potvrďte tu cestu jediným pingem, než přidáte další pravidla, protože pravidlo, ke kterému se nedá dojít, se v čítači nikdy neobjeví.

SMB potřebuje víc než jeden port

Sdílení souborů není jediná konverzace na TCP 445. Zjišťování používá UDP 137 a 138, starší relace NetBIOS používají TCP 139 a moderní relace SMB používají TCP 445. Pravidlo, které otevře jen 445, vytváří zoufalý případ, kdy mapovaná jednotka funguje a procházení sítě ne, nebo naopak.

Velké přenosy tunelem také narážejí na problémy s MSS, které vypadají jako rozbité sdílení. SYN, který inzeruje plnou velikost segmentu LAN, se zahodí kvůli menšímu MTU tunelu a spojení po handshake visí. Omezení MSS na cestě forwardování, iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu, tuto třídu zaseknutí odstraní. Ověřte to kopií několika megabajtů místo výpisu adresáře, protože malé odpovědi projdou, i když velké přenosy ne.

Adaptér tunelu přichází jako nový síťový profil

Windows zařazuje každý adaptér do síťového profilu a nový adaptér tunelu obvykle skončí v Public, kde jsou pravidla pro sdílení souborů a tiskáren blokována. To je rozhodnutí hostitelského firewallu na souborovém serveru, ne problém směrování na serveru VPN. Změňte kategorii záměrně pomocí Set-NetConnectionProfile -InterfaceAlias "Ethernet 3" -NetworkCategory Private poté, co potvrdíte, že to politika dovoluje, protože kategorie mění i to, která příchozí pravidla platí.

Stejný profil vysvětluje ping, který selhává, zatímco TCP 445 prochází: echo požadavky se v profilu Public ve výchozím nastavení zahazují.

Jména sama přes routovaný tunel neprojdou

Překlad jmen NetBIOS a místní zjišťování spoléhají na broadcasty, které routovaný tunel nepřenáší. Napsání krátkého jména serveru proto selhává, zatímco jeho adresa funguje, a sdílení vypadá rozbité, i když je rozbité jen vyhledávání. Přidejte DNS záznam pro server na resolveru, který tunel přiděluje, nebo v zástupci použijte adresu.

Pokud nasazení stále závisí na WINS, nakonfigurujte ho na klientu, místo abyste doufali, že se broadcast provoz objeví. Testujte nejdřív adresou, aby se selhání jména nepletlo se selháním firewallu.

Testujte po jedné vrstvě a čtěte první selhání

Postupujte zdola nahoru: pingněte bránu tunelu, pingněte hostitele v LAN podle adresy, pak otevřete port služby pomocí Test-NetConnection -ComputerName 10.8.0.5 -Port 445, a teprve potom se autentizujte ke sdílení. První krok, který selže, je vrstva k opravě, a každý další krok je šum, dokud ten předchozí neprojde. Ping, který odpovídá, zatímco port zůstává zavřený, ukazuje na vlastní firewall souborového serveru, zatímco port, který se otevře i přes tiché pingy, ukazuje na filtrování ICMP. Zapište první selhávající krok, než cokoli změníte, protože druhý zásah skryje výsledek prvního.

Pokud server VPN není routerem LAN, potvrďte zpětnou cestu na tom routeru než na server přidáte další pravidla. Bez toho požadavky dojdou k hostiteli a odpovědi odejdou výchozí cestou k internetu, což ze strany klienta vypadá přesně jako zahazování firewallem.

Uchovávejte účet pro sdílení odděleně od přihlášení VPN ve svých poznámkách, protože úspěšný tunel nic neříká o oprávněních k souborům. Vystavovat SMB internetu, abyste obejšli chybějící pravidlo, není řešení.