Clienții VPN se conectează, dar nu au internet: trei piese lipsă

Clientul primește o adresă, serverul răspunde la ping, și totuși fiecare pagină expiră. Majoritatea oamenilor încep în acest punct să editeze profilul clientului, ceea ce de obicei este efort irosit: odată ce tunelul este ridicat, serverul trebuie să se comporte ca un router. Trei condiții trebuie să fie valabile simultan înainte ca un pachet să iasă și un răspuns să revină, iar simptomul este identic oricare ar lipsi.

De ce un tunel funcțional tot nu are ieșire

Kernelul trebuie să redirecționeze pachete între interfețe, ceea ce este dezactivat implicit pe majoritatea distribuțiilor Linux. Traficul trebuie tradus într-o adresă la care lumea exterioară poate răspunde, cu excepția cazului în care fiecare router din amonte cunoaște deja ruta de întoarcere către subrețeaua tunelului. Calea de redirecționare a firewall-ului trebuie să permită traficul în ambele direcții, inclusiv răspunsurile.

Fiecare dintre acestea poate fi reparată separat, și exact aceasta este capcana. Activarea redirecționării fără o regulă de traducere lasă pachetele să iasă cu o sursă privată și fără cale de întoarcere. Adăugarea traducerii fără o regulă de redirecționare lasă kernelul să renunțe la pachet un pas mai târziu.

Deci testați cele trei straturi, nu clientul, și schimbați unul pe rând ca rezultatul să însemne ceva.

Redirecționarea este un comutator al kernelului pe care trebuie să îl faceți permanent

Verificați valoarea curentă înainte de a o schimba, apoi setați-o și confirmați că modificarea a intrat în vigoare.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
sysctl net.ipv4.ip_forward

Prima comandă raportează valoarea curentă, a doua o setează la rulare, iar a treia dovedește că scrierea a funcționat. Valoarea de rulare dispare la următoarea repornire, motiv pentru care o sesiune funcțională poate ceda după mentenanță fără nicio modificare de configurație.

Faceți-o permanentă într-un fișier sub /etc/sysctl.d/, apoi aplicați acel fișier în loc să reporniți ca să aflați. Pe FreeBSD echivalentul este net.inet.ip.forwarding, cu gateway_enable=YES în rc.conf pentru persistență. Un echipament care raportează redirecționarea dezactivată explică o întreagă clasă de rapoarte „pachetele sosesc și nimic nu se întoarce”. Verificați setarea și după fiecare actualizare, fiindcă un kernel reconstruit sau o imagine de echipament înlocuită o pot reseta fără să spună nimănui.

Alegeți masquerade sau o singură adresă de traducere fixă

Cu o adresă exterioară dinamică, masquerading este cea mai simplă formă corectă. Numiți subrețeaua tunelului drept sursă și interfața exterioară drept ieșire.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -o eth0 -j MASQUERADE

Cu o adresă publică statică, traducerea sursei către exact acea adresă este mai previzibilă și mai ușor de auditat.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -j SNAT --to-source 198.51.100.10

A doua formă poartă o capcană de mentenanță: o adresă codată fix care se schimbă mai târziu ține tunelul funcțional în timp ce accesul la internet se oprește în tăcere. Fie folosiți masquerade, fie actualizați regula de fiecare dată când furnizorul vă mută. Interfața contează și ea, fiindcă un router care împarte propriul tunel din amonte trebuie să traducă prin acel tunel, nu prin WAN-ul fizic.

Tabelul de filtrare este a treia poartă

Redirecționarea și traducerea pot fi ambele corecte în timp ce pachetul moare totuși în tabelul de filtrare. ufw este un vinovat frecvent: politica sa de redirecționare vine ca DROP, iar restul configurației poate părea perfect corect în timp ce acea singură setare ucide traficul. Ridicarea ei este o decizie de securitate deliberată, nu o casetă de bifare.

iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Prima regulă permite trafic nou din tunel spre exterior, iar a doua doar răspunsurile înapoi. Îngustați ambele la subrețeaua tunelului și la destinația dorită, fiindcă o acceptare generală pe interfața tunelului transformă VPN-ul într-un punct de ieșire deschis pentru oricine se poate autentifica.

Un tunel punte are nevoie de alt răspuns. Adresa aparține punții, nu portului fizic, așa că înrobirea interfeței elimină adresa pe care o avea înainte și gazda pare inaccesibilă până când puntea însăși primește una, ceea ce dhclient br0 poate furniza. Acea defecțiune arată ca o problemă VPN și este o problemă de nivel doi. Verificați adresa proprie a punții înainte de a atinge firewall-ul, fiindcă o modificare de filtru nu poate repara o gazdă care nu mai are adresă de pe care să trimită.

Unde să priviți când o pagină nu se încarcă niciodată

Faceți ping la adresa tunelului serverului pentru a dovedi că tunelul există. Apoi rulați un traceroute de la client la o adresă publică și citiți unde se oprește: la server pachetul sosește dar nu este redirecționat sau tradus; dincolo de server problema este în amonte și în afara mâinilor dumneavoastră.

ping -c 3 10.9.0.1
traceroute -n 198.51.100.10

Prima comandă dovedește că tunelul duce trafic până la serverul însuși, iar a doua arată cât de departe ajunge un pachet spre exterior. O urmă care se termină la adresa tunelului indică redirecționare sau traducere pe server, în timp ce o urmă care se oprește un salt mai târziu indică furnizorul sau ruta de întoarcere a routerului din amonte.

Pe server, urmăriți interfața exterioară în timp ce un client încarcă o pagină. Traficul care iese cu o adresă de sursă privată înseamnă că lipsește traducerea, iar absența totală a răspunsului înseamnă că calea de redirecționare sau ruta de întoarcere din amonte îl aruncă.

Dacă clienții la distanță trebuie să ajungă și la gazde din LAN-ul serverului, rețineți că LAN-ul are nevoie de o rută de întoarcere către subrețeaua tunelului. Aceasta este rutare, nu traducere, și este pasul cel mai des uitat după ce calea spre internet funcționează în sfârșit.