Handshake-ul PiVPN funcționează, paginile se blochează: verificați MASQUERADE

Telefonul arată tunelul ca fiind conectat, clientul raportează o adresă privată, iar prima pagină se blochează totuși la jumătatea încărcării. Această combinație trimite majoritatea oamenilor la setările de criptare și la temperatura procesorului, unde de fapt nu e nimic stricat. Tunelul a pornit, deci negocierea s-a terminat; ce a eșuat este pasul următor, când serverul încearcă să predea pachetele clientului către internet. Urmați același drum pe care merg acele pachete, iar nepotrivirea se vede de obicei într-o singură linie a tabelului NAT.

Începeți cu ce poate și ce nu poate atinge clientul

Din clientul conectat, încărcați o pagină care se află pe internetul public și observați dacă eșuează imediat sau se blochează la jumătate. Apoi deschideți o resursă la adresa privată a serverului VPN și comparați cele două rezultate.

O adresă de tunel care răspunde la ping în timp ce site-urile publice expiră este semnul unei probleme de redirecționare sau de traducere, nu al unui handshake stricat. Panoul de stare al clientului nu le poate distinge, pentru că știe doar că canalul de control este activ. Verificați pe server interfața tunelului cu ip -br addr show tun0 și confirmați că adresa alocată clientului se află în grupul pe care l-ați configurat. Dacă grupul și adresa clientului nu coincid, corectați mai întâi asta, pentru că fiecare regulă de mai jos se potrivește cu grupul.

Apoi întrebați serverul ce interfață ar folosi pentru a ajunge la o adresă publică. ip route get 203.0.113.9 tipărește dispozitivul și sursa alese pe prima linie. Notați numele acelui dispozitiv, pentru că este valoarea pe care regula NAT trebuie să o conțină.

Citiți regula care decide dacă pachetele ies

MASQUERADE rescrie un pachet doar când pachetul iese prin interfața numită în regulă. O regulă limitată la un dispozitiv cu cablu nu face nimic pentru traficul care iese prin Wi-Fi, iar pachetul își păstrează adresa de sursă privată până la routerul superior. Acel router nu are rută înapoi către grupul tunelului, așa că renunță la răspuns, iar clientul vede o conexiune care se deschide și apoi moare. Simptomul crește cu cât de mult din pagină ajunge înainte de a fi nevoie de primul răspuns.

Listați tabelul activ și citiți coloana interfeței de ieșire în loc să căutați doar cuvântul MASQUERADE. Ieșirea în forma de adăugare este mai ușor de comparat decât o listă formatată:

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

Pe un Raspberry Pi care folosea cândva Ethernet și acum folosește Wi-Fi, numele învechit este aproape întotdeauna toată povestea. Instalatorul a înregistrat ce dispozitiv exista la configurare, iar setul de reguli salvat îl repetă la fiecare pornire. Comparați dispozitivul din căutarea rutei cu cel din regulă înainte de a schimba altceva. Dacă se potrivesc, interfața nu este problema dumneavoastră și ar trebui să treceți la contoarele din ultima secțiune. Dacă diferă, corectarea este o modificare de un singur cuvânt în fișierul de persistență.

Corectați setul de reguli salvat, nu doar pe cel în execuție

Editarea doar a tabelului activ rezistă până la următoarea repornire, exact suficient cât să vă convingă că problema este rezolvată. Regulile care se întorc la pornire stau într-un fișier pe care un pachet de persistență al firewallului îl reîncarcă. Pe imaginile Pi bazate pe Debian acel fișier este de obicei /etc/iptables/rules.v4.

Faceți o copie înainte să îl atingeți, apoi înlocuiți interfața de ieșire din linia MASQUERADE cu dispozitivul notat, de exemplu -o wlan0 în loc de -o eth0. Lăsați intervalul de sursă așa cum este, dacă grupul de clienți nu s-a schimbat. Reîncărcați și confirmați că regula indică acum dispozitivul corect:

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

Două setări vecine se uită ușor. sysctl net.ipv4.ip_forward trebuie să raporteze 1, iar routerul superior nu trebuie să filtreze singur adresele de sursă private.

Demonstrați că regula se declanșează, apoi izolați ce este încă lent

Contoarele sunt singura dovadă onestă că o regulă s-a potrivit. Rulați listarea detaliată, porniți o descărcare pe client și rulați-o din nou. Coloanele de pachete și octeți de lângă regula dumneavoastră ar trebui să crească, iar o regulă care rămâne la zero încă nu se potrivește. Dacă contoarele se mișcă dar paginile încă eșuează, comparați intervalul de sursă cu grupul real cu grep -n "^server " /etc/openvpn/server.conf. Dacă se mișcă și paginile se încarcă dar debitul este slab, traducerea este gata și problema rămasă este în altă parte.

Comparați două transferuri din același client, unul către un gazdă din rețeaua locală și unul prin tunel către aceeași gazdă. Lent în ambele cazuri indică legătura superioară a Pi sau conexiunea Wi-Fi, nu VPN-ul. Lent doar prin tunel indică MTU și retransmisii, pe care le puteți inspecta cu ip -s link show tun0 înainte de a schimba orice setare de criptare.

Pentru a anula experimentul, restaurați copia și reîncărcați-o, apoi confirmați că regula originală și contoarele ei au revenit. Scrieți dispozitivul de ieșire și comanda de reîncărcare în notele serverului, pentru că următoarea schimbare a legăturii superioare va redescoperi aceeași nepotrivire. O regulă care numește dispozitivul greșit rămâne invizibilă până când traficul are nevoie de ea.