Conectat la OpenVPN, dar nimic nu se încarcă: un parcurs de la client spre exterior

Fereastra clientului spune Connected, adresa tunelului există, iar browserul se învârte în continuare. Această combinație este normală, pentru că un handshake reușit dovedește doar că tunelul a fost construit; nu spune nimic despre dacă serverul va redirecționa pachetele tale, le va rescrie sursa sau va răspunde la interogările DNS. Greșeala pe care o fac cei mai mulți este să deschidă mai întâi configurația serverului. În schimb, lucrează de la client spre exterior, pentru că fiecare pas de mai jos îți spune dacă următorul merită verificat.

Începe la client și mergi spre exterior

Fă trei teste în această ordine și notează unde eșuează primul. Fă ping la adresa tunelului serverului, ceea ce dovedește că tunelul însuși transportă trafic. Fă ping la o adresă publică după număr, ceea ce dovedește redirecționarea și traducerea fără a implica rezolvarea numelor. Apoi încearcă să rezolvi un nume de gazdă, singurul test care folosește DNS. Fiecare rezultat elimină un strat întreg din suspiciuni.

Nu sări la al treilea test pentru că browserul pare mai rapid. O încărcare de pagină eșuată acoperă toate cele trei straturi deodată, și de acolo încep oamenii și apoi reconstruiesc un tunel care funcționa. O pagină care eșuează nu îți spune care dintre cele trei s-a rupt.

Două capturi arată unde se opresc pachetele

Cât timp un ping către o adresă publică rulează din client, fă o captură pe interfața tunelului și una pe legătura superioară care ar trebui să ajungă la internet. Rulează ambele simultan ca marcajele de timp să coincidă.

sudo tcpdump -ni tun0 -c 20 icmp
sudo tcpdump -ni enp1s0 -c 20 icmp

Dacă cererile apar pe tunel și niciodată pe legătura superioară, serverul le-a aruncat între tunel și cablu, iar cauza este redirecționarea sau politica de firewall pentru redirecționare, nu NAT. Dacă apar pe ambele, serverul și-a făcut partea, iar răspunsul lipsește mai departe, ceea ce indică traducerea, un filtru mai sus sau o restricție din partea furnizorului.

Ia numele legăturii superioare din tabela de rutare, nu dintr-un tutorial. Imaginile cloud și adaptoarele redenumite rareori corespund interfeței de exemplu dintr-un ghid, iar o captură făcută pe dispozitivul greșit arată exact ca un server care nu redirecționează:

ip -4 route get 9.9.9.9

Câmpul dev din acea ieșire este numele de care regula NAT va avea nevoie mai târziu, așa că păstrează-l.

Redirecționarea este un comutator în nucleu și o politică de firewall

Nucleul trebuie să fie de acord să redirecționeze, ca să începem cu asta. Citește valoarea curentă și apoi fă setarea permanentă în loc să o scrii doar în nucleul care rulează:

sysctl net.ipv4.ip_forward
printf 'net.ipv4.ip_forward=1\n' > /etc/sysctl.d/70-vpn-forward.conf
sysctl --system

Redirecționarea este doar jumătate. Pe o gazdă cu UFW politica de redirecționare se setează în /etc/default/ufw și trebuie să fie ACCEPT înainte ca o reîncărcare să aibă efect. O aruncare implicită pe calea de redirecționare lasă handshake-ul perfect sănătos, dar aruncă în tăcere fiecare pachet care încearcă să iasă prin tunel, iar acesta este exact simptomul cu care ai început.

Gazdele care administrează nftables direct au aceeași întrebare într-o altă sintaxă. Urmărește contoarele de pe lanțul de redirecționare cât timp rulează un test din client, pentru că un lanț consultat și un lanț care aruncă arată identic într-un fișier de configurare.

Numește interfața reală de ieșire în regula NAT

Traducerea sursei aparține interfeței care chiar părăsește gazda, cu pool-ul pe care serverul îl distribuie. Ambele jumătăți ale acelei reguli trebuie să descrie realitatea, și niciuna nu este opțională.

iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o enp1s0 -j MASQUERADE

Eșecul clasic este o regulă copiată dintr-un ghid care spune -o eth0 pe o mașină al cărei adaptor se numește altfel. Regula se instalează fără avertisment, nu se potrivește cu nimic, iar clientul tot nu are internet. Pool-ul este cealaltă jumătate a aceleiași greșeli: dacă serverul distribuie 10.44.0.0/24 și regula acoperă 10.8.0.0/24, nimic nu se va potrivi vreodată.

Urmărește contoarele în loc să te bazezi pe textul regulii. Listarea raportează pachete pe regulă, iar o regulă care nu se potrivește niciodată rămâne la zero oricât de corectă ar părea. Dă-i un minut de trafic real din client înainte de a citi ceva în acel număr:

iptables -t nat -L POSTROUTING -v -n

Un contor de pachete zero după un test real din client înseamnă că potrivirea este greșită, nu că tunelul este rupt. Odată ce se potrivește, salvează setul de reguli ca să supraviețuiască unei reporniri; o reparație care trăiește doar în istoricul shell-ului tău dispare la prima repornire.

Dacă serverul este și o instanță NAT în cloud, platforma are și ea un cuvânt. O instanță care traduce adrese are de obicei nevoie de verificarea sursei și destinației dezactivată acolo unde furnizorul oferă această setare, iar portul VPN în sine trebuie să fie accesibil din exterior.

DNS este al doilea eșec din spatele primului

Ping-ul după adresă care funcționează în timp ce numele eșuează este o problemă a resolverului, și are propria cauză. Un client care își păstrează resolverul local trimite acele interogări într-un tunel complet și așteaptă un răspuns care nu vine niciodată, pentru că resolverul local este acum de partea greșită a rutei.

Împinge un resolver de la server ca clientul să știe unde să întrebe. Două intrări îi dau clientului o rezervă dacă prima nu este accesibilă, și ambele ar trebui să fie resolvere pe care tunelul le permite cu adevărat.

push "dhcp-option DNS 9.9.9.9"
push "dhcp-option DNS 149.112.112.112"

Clienții Windows pot apoi să revină oricum la resolverul local, și exact asta există block-outside-dns ca să prevină, cu prețul pierderii numelor pe care doar rețeaua locală le poate rezolva. Clienții Linux cu systemd-resolved ignoră adesea un resolver împins dacă un script nu îl instalează, așa că verifică resolvectl status pentru dispozitivul tunelului înainte de a concluziona că împingerea a fost ignorată.

Încheie parcursul așa cum îl trăiește un utilizator. Încarcă o pagină reală din client, confirmă adresa de unde iese, repornește serverul, reconectează-te și repetă cele trei teste. Doar acea a doua rundă dovedește că regulile salvate, politica de firewall și resolverul împins au supraviețuit toate împreună.