Handshake PiVPN funguje, stránky zamrzají: zkontrolujte MASQUERADE

Telefon ukazuje tunel jako připojený, klient hlásí privátní adresu, a první stránka přesto visí v polovině načítání. Tahle kombinace posílá většinu lidí do nastavení šifer a teplot procesoru, kde ve skutečnosti nic špatně není. Tunel se zvedl, takže vyjednávání skončilo; selhal krok po něm, kdy se server snaží předat pakety klienta do internetu. Projděte stejnou cestu, kterou ty pakety jdou, a nesoulad je obvykle vidět v jednom řádku tabulky NAT.

Začněte tím, na co klient dosáhne a na co ne

Z připojeného klienta načtěte stránku, která sídlí na veřejném internetu, a všimněte si, zda padá okamžitě, nebo se zasekne v polovině. Potom otevřete zdroj na vlastní privátní adrese serveru VPN a oba výsledky porovnejte.

Adresa tunelu, která odpovídá na ping, zatímco veřejné weby končí časovým limitem, je známkou problému s předáváním nebo překladem, ne rozbitého handshake. Vlastní stavový panel klienta je nedokáže rozlišit, protože ví jen to, že řídicí kanál je nahoře. Zkontrolujte na serveru rozhraní tunelu pomocí ip -br addr show tun0 a potvrďte, že přidělená adresa klienta leží v rozsahu, který jste nastavili. Pokud se rozsah a adresa klienta neshodují, opravte to nejdřív, protože každé pravidlo níž se páruje s rozsahem.

Dále se serveru zeptejte, kterým rozhraním by dosáhl veřejné adresy. ip route get 203.0.113.9 vypíše zvolené zařízení a zdroj na prvním řádku. Zařízení si zapište, protože přesně tato hodnota musí být v pravidle NAT.

Přečtěte pravidlo, které rozhoduje, zda pakety odejdou

MASQUERADE přepisuje paket jen tehdy, když paket opustí rozhraní uvedené v pravidle. Pravidlo vázané na kabelové zařízení nedělá nic pro provoz, který odchází přes Wi-Fi, a paket si drží privátní zdrojovou adresu až k nadřazenému routeru. Ten router nemá zpáteční trasu do vašeho rozsahu tunelu, takže odpověď zahodí, a klient vidí spojení, které se otevře a pak umře. Příznak roste s tím, kolik stránky dorazí, než je potřeba první odpověď.

Vypište živou tabulku a čtěte sloupec odchozího rozhraní, místo abyste jen hledali slovo MASQUERADE. Výstup v přidávací formě se porovnává snáz než formátovaný seznam:

ip -br addr show tun0
ip route get 203.0.113.9
sudo iptables -t nat -S POSTROUTING

Na Raspberry Pi, které dřív používalo Ethernet a teď Wi-Fi, je zastaralé jméno skoro vždy celý příběh. Instalátor zaznamenal, jaké zařízení bylo při instalaci k dispozici, a uložená sada pravidel ho při každém startu znovu nasadí. Než cokoli jiného změníte, porovnejte zařízení z vyhledání trasy s tím v pravidle. Pokud se shodují, rozhraní není váš problém a měli byste přejít k čítačům v poslední části. Pokud se liší, oprava je úprava jednoho slova v souboru trvalosti.

Opravte uloženou sadu pravidel, ne jen tu běžící

Úprava jen živé tabulky vydrží do dalšího restartu, což je přesně dost dlouho na to, abyste uvěřili, že je problém vyřešený. Pravidla, která se při startu vracejí, žijí v souboru, který znovu načítá balík trvalosti firewallu. Na obrazech Pi založených na Debianu je tím souborem obvykle /etc/iptables/rules.v4.

Než na něj sáhnete, udělejte kopii, pak nahraďte odchozí rozhraní na řádku MASQUERADE zařízením, které jste si zapsali, například -o wlan0 místo -o eth0. Rozsah zdroje nechte, jak je, pokud se váš rozsah klientů nezměnil. Znovu načtěte a potvrďte, že pravidlo teď uvádí správné zařízení:

sudo cp /etc/iptables/rules.v4 /root/rules.v4.bak
sudo iptables-restore < /etc/iptables/rules.v4
sudo iptables -t nat -L POSTROUTING -v -n

Dvě sousední nastavení se snadno zapomenou. sysctl net.ipv4.ip_forward musí hlásit 1 a nadřazený router nesmí sám filtrovat privátní zdrojové adresy.

Dokažte, že pravidlo zabírá, a pak izolujte, co je ještě pomalé

Čítače jsou jediný poctivý důkaz, že pravidlo zabralo. Spusťte podrobný výpis, začněte na klientovi stahování a spusťte ho znovu. Sloupce paketů a bajtů vedle vašeho pravidla by měly růst a pravidlo, které zůstává na nule, stále neodpovídá. Pokud se čítače hýbou, ale stránky pořád padají, porovnejte rozsah zdroje se skutečným rozsahem pomocí grep -n "^server " /etc/openvpn/server.conf. Pokud se hýbou a stránky se načítají, ale propustnost je slabá, překlad je hotový a zbývající problém je jinde.

Porovnejte dva přenosy z téhož klienta, jeden k hostiteli v místní síti a jeden tunelem k témuž hostiteli. Pomalé v obou případech ukazuje na odchozí link Pi nebo Wi-Fi spojení, ne na VPN. Pomalé jen tunelem ukazuje na MTU a opakované přenosy, které můžete prohlédnout pomocí ip -s link show tun0 než změníte jakékoli nastavení šifrování.

Chcete-li experiment vrátit, obnovte kopii a znovu ji načtěte, pak potvrďte, že původní pravidlo i jeho čítače jsou zpět. Zapište odchozí zařízení a příkaz k načtení do poznámek serveru, protože příští změna linku znovu objeví stejný nesoulad. Pravidlo, které uvádí špatné zařízení, zůstává neviditelné, dokud ho provoz nepotřebuje.