Handshake PiVPN funguje, stránky zamŕzajú: skontrolujte MASQUERADE

Telefón ukazuje tunel ako pripojený, klient hlási privátnu adresu a prvá stránka napriek tomu visí v polovici načítania. Táto kombinácia posiela väčšinu ľudí do nastavení šifier a k teplote procesora, kde v skutočnosti nič nie je pokazené. Tunel sa zdvihol, takže vyjednávanie sa skončilo; zlyhal krok po ňom, keď sa server snaží odovzdať pakety klienta do internetu. Prejdite tou istou cestou, ktorou idú tieto pakety, a nesúlad je zvyčajne viditeľný v jednom riadku tabuľky NAT.

Začnite tým, na čo klient dosiahne a na čo nie

Z pripojeného klienta načítajte stránku, ktorá sídli na verejnom internete, a všimnite si, či padá okamžite alebo sa zasekne v polovici. Potom otvorte zdroj na vlastnej privátnej adrese servera VPN a oba výsledky porovnajte.

Adresa tunela, ktorá odpovedá na ping, kým verejné weby končia časovým limitom, je znakom problému s preposielaním alebo prekladom, nie rozbitého handshake. Vlastný stavový panel klienta ich nedokáže rozlíšiť, pretože vie len to, že riadiaci kanál je hore. Skontrolujte na serveri rozhranie tunela pomocou ip -br addr show tun0 a potvrďte, že pridelená adresa klienta leží v rozsahu, ktorý ste nastavili. Ak sa rozsah a adresa klienta nezhodujú, opravte to najskôr, pretože každé pravidlo nižšie sa páruje s rozsahom.

Ďalej sa servera opýtajte, ktoré rozhranie by použil na dosiahnutie verejnej adresy. ip route get 203.0.113.9 vypíše zvolené zariadenie a zdroj na prvom riadku. Zapíšte si názov toho zariadenia, pretože presne táto hodnota musí byť v pravidle NAT.

Prečítajte pravidlo, ktoré rozhoduje, či pakety odídu

MASQUERADE prepisuje paket len vtedy, keď paket opustí rozhranie uvedené v pravidle. Pravidlo viazané na káblové zariadenie nič nerobí pre prevádzku, ktorá odchádza cez Wi-Fi, a paket si drží privátnu zdrojovú adresu až k nadradenému routeru. Ten router nemá spätnú trasu do vášho rozsahu tunela, takže odpoveď zahodí, a klient vidí spojenie, ktoré sa otvorí a potom zomrie. Príznak rastie s tým, koľko stránky dorazí, kým je potrebná prvá odpoveď.

Vypíšte živú tabuľku a čítajte stĺpec odchádzajúceho rozhrania namiesto toho, aby ste len hľadali slovo MASQUERADE. Výstup v pridávacej forme sa porovnáva ľahšie ako formátovaný zoznam:

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

Na Raspberry Pi, ktoré kedysi používalo Ethernet a teraz Wi-Fi, je zastaraný názov takmer vždy celý príbeh. Inštalátor zaznamenal, aké zariadenie bolo pri nastavení prítomné, a uložená sada pravidiel ho pri každom štarte znovu nasadí. Predtým, ako zmeníte čokoľvek iné, porovnajte zariadenie z vyhľadania trasy s tým v pravidle. Ak sa zhodujú, rozhranie nie je váš problém a mali by ste prejsť k počítadlám v poslednej časti. Ak sa líšia, oprava je úprava jedného slova v súbore trvalosti.

Opravte uloženú sadu pravidiel, nie len tú bežiacu

Úprava len živej tabuľky vydrží do ďalšieho reštartu, čo je presne dosť dlho na to, aby vás presvedčilo, že problém je vyriešený. Pravidlá, ktoré sa pri štarte vracajú, žijú v súbore, ktorý znovu načíta balík trvalosti firewallu. Na obrazoch Pi založených na Debiane je tým súborom zvyčajne /etc/iptables/rules.v4.

Predtým, ako naň siahnete, urobte kópiu, potom nahraďte odchádzajúce rozhranie na riadku MASQUERADE zariadením, ktoré ste si zapísali, napríklad -o wlan0 namiesto -o eth0. Rozsah zdroja nechajte tak, ako je, ak sa váš rozsah klientov nezmenil. Znovu načítajte a potvrďte, že pravidlo teraz uvádza správne zariadenie:

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

Dve susedné nastavenia sa ľahko zabudnú. sysctl net.ipv4.ip_forward musí hlásiť 1 a nadradený router nesmie sám filtrovať privátne zdrojové adresy.

Dokážte, že pravidlo zaberá, a potom izolujte, čo je ešte pomalé

Počítadlá sú jediný čestný dôkaz, že pravidlo zabralo. Spustite podrobný výpis, začnite na klientovi sťahovanie a spustite ho znova. Stĺpce paketov a bajtov vedľa vášho pravidla by mali rásť a pravidlo, ktoré zostáva na nule, stále nezodpovedá. Ak sa počítadlá hýbu, ale stránky stále padajú, porovnajte rozsah zdroja so skutočným rozsahom pomocou grep -n "^server " /etc/openvpn/server.conf. Ak sa hýbu a stránky sa načítavajú, ale priepustnosť je slabá, preklad je hotový a zostávajúci problém je inde.

Porovnajte dva prenosy z toho istého klienta, jeden k hostiteľovi v miestnej sieti a jeden tunelom k tomu istému hostiteľovi. Pomalé v oboch prípadoch ukazuje na odchádzajúci link Pi alebo Wi-Fi spojenie, nie na VPN. Pomalé len tunelom ukazuje na MTU a opakované prenosy, ktoré môžete prezrieť pomocou ip -s link show tun0 pred zmenou akéhokoľvek nastavenia šifrovania.

Ak chcete experiment vrátiť, obnovte kópiu a znovu ju načítajte, potom potvrďte, že pôvodné pravidlo aj jeho počítadlá sú späť. Zapíšte odchádzajúce zariadenie a príkaz na načítanie do poznámok servera, pretože najbližšia zmena linku znovu objaví ten istý nesúlad. Pravidlo, ktoré uvádza nesprávne zariadenie, zostáva neviditeľné, kým ho prevádzka nepotrebuje.