Clientul OpenVPN ajunge la server, dar nu la gazdele din LAN: listă de verificare

Clientul spune conectat, adresa tunelului răspunde la ping, iar nimic din LAN-ul biroului nu răspunde. Văd asta după aproape fiecare actualizare a clientului, iar primul instinct este să deschizi firewallul, ceea ce de obicei este mișcarea greșită: tunelul este în regulă, iar ruptura este pe unul dintre cele trei salturi pe care pachetul trebuie să le treacă. Parcurgeți calea în ordinea în care o ia pachetul, mai întâi ruta clientului, apoi forwardarea pe server, apoi călătoria de întoarcere, și veți găsi vinovatul defecțiunii în câteva minute.

Primul pas: observați decizia de rutare a clientului

Înainte de a atinge serverul, demonstrați că clientul trimite pachetul în tunel. Întrebați nucleul ce interfață ar folosi pentru o gazdă LAN anume, în loc să citiți tot tabelul:

ip route get 192.168.50.10

Dacă răspunsul numește adaptorul fizic și gateway-ul biroului, nicio modificare pe partea serverului nu poate ajuta. OpenVPN distribuie rute doar când serverul le împinge, așa că căutați push "route 192.168.50.0 255.255.255.0" în configurația serverului și apoi reconectați clientul. Majoritatea clienților aplică rutele împinse la conectare, nu când reîncărcați profilul.

În Windows aceeași întrebare are altă comandă. Find-NetRoute -RemoteIPAddress 192.168.50.10 afișează interfața și următorul salt pe care le-ar alege stiva, iar route print -4 arată dacă prefixul împins există măcar.

Al doilea pas: confirmați că serverul va forwarda pachetul

Dacă ruta clientului este corectă, pachetul ajunge la server, iar serverul trebuie să accepte să îl forwardeze. Comutatorul nucleului este prima poartă, iar sysctl net.ipv4.ip_forward trebuie să returneze 1. Setarea lui cu echo 1 > /proc/sys/net/ipv4/ip_forward funcționează până la următoarea repornire, și exact de aceea aceeași reclamație revine săptămâni mai târziu.

Notați-o undeva care supraviețuiește unei reporniri:

echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-openvpn-forward.conf
sysctl --system

A doua poartă este tabelul de filtre. O gazdă cu Docker instalat are adesea o politică FORWARD de DROP, iar tunelul moștenește acea decizie. iptables -L FORWARD -v -n arată atât politica, cât și contoarele de pachete; dacă politica este DROP, forwardarea are nevoie de o permisiune explicită pentru direcția tunel către LAN și una pentru răspuns.

Al treilea pas: urmați pachetul până în LAN și căutați răspunsul

Urmăriți ambele părți ale serverului simultan. Capturați pe tunel și pe interfața LAN, filtrat pe un client și o gazdă ca ieșirea să rămână lizibilă:

tcpdump -ni tun0 host 192.168.50.10
tcpdump -ni eth0 host 192.168.50.10

Cererile care apar pe tun0 și din nou pe eth0 cu sursă 10.8.0.x, urmate de tăcere, înseamnă că pachetul a ajuns și răspunsul a plecat în altă parte. Gazda din LAN răspunde gateway-ului său implicit, acel gateway nu are rută pentru pool-ul VPN, iar răspunsul moare pe routerul din LAN. Pingul către gazda din LAN de pe server nu dovedește nimic despre această cale, pentru că traficul respectiv nu traversează niciodată tunelul.

Al patrulea pas: alegeți între traducere și o rută de întoarcere

Două reparații astupă gaura, iar alegerea are consecințe dincolo de dacă pingul funcționează. Traducerea sursei face serverul expeditorul aparent:

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

Limitați regula la pool și la interfața LAN, apoi faceți-o permanentă, altfel următoarea reîncărcare a firewallului vă elimină în tăcere corectura. Costul este identitatea: fiecare client arată ca serverul VPN în jurnalele LAN și în regulile de acces, și per-client policy becomes guesswork.

O rută statică pentru 10.8.0.0/24 pe routerul din LAN, îndreptată spre serverul VPN, păstrează adresele clienților vizibile și este răspunsul mai bun pe termen lung când acel router este al dumneavoastră. Multe locații rulează ambele o vreme, NAT pentru reparația imediată și ruta după ce politica firewallului este scrisă. Dacă serverul este un peer site-to-site și nu un pool, partea serverului are nevoie și de un iroute pentru subrețeaua îndepărtată, altfel ruta peerului există, dar traficul clienților nu este niciodată asociat cu ea.

Al cincilea pas: verificați din client și notați ce s-a schimbat

Închideți bucla din client, nu din server. Conectați-vă la un serviciu real pe gazda din LAN, apoi confirmați că contoarele de traducere s-au mișcat cu iptables -t nat -L POSTROUTING -v -n, pentru că o regulă fără pachete este o regulă care nu s-a potrivit niciodată. conntrack -L -s 10.8.0.5 arată fluxul și starea lui când aveți nevoie de dovada că direcția de întoarcere este urmărită.

Lăsați o notă în configurația serverului: ce subrețea, ce interfață, ce regulă și dacă routerul din LAN are o rută înapoi. Data viitoare când o actualizare a clientului șterge o rută împinsă, nota aceea transformă o sesiune de stingere a incendiilor într-o corectură de o linie.