OpenVPN în tunel complet: adăugați o ieșire de internet pe partea serverului

Un client se autentifică, primește o adresă din pool și ajunge la serviciile de pe gazda VPN, însă fiecare destinație publică se termină în timeout. Așa arată un tunel fără ieșire și așa rămâne până când patru lucruri separate sunt adevărate. Clientul trebuie să accepte o rută implicită, serverul trebuie să redirecționeze, firewallul trebuie să permită tranzitul, iar răspunsurile au nevoie de o cale înapoi spre pool. Toate cele patru defecțiuni au un singur simptom, așa că schimbați un singur element pe încercare și notați rezultatul.

Împingeți ruta implicită și confirmați ce a instalat clientul

Linia din partea serverului este scurtă, și afectează doar clienții care acceptă opțiunile împinse. Forma def1 instalează două semi-rute implicite în loc să șteargă ruta implicită existentă, ceea ce menține conexiunea curentă activă și totodată capturează fiecare destinație.

push "redirect-gateway def1"

După reconectare, citiți tabelul de rutare al clientului în loc să aveți încredere în profil. Pe Linux cele două intrări /1 apar lângă ruta implicită originală, iar Windows arată aceeași pereche ca 0.0.0.0/1 și 128.0.0.0/1. Un client care ignoră opțiunile împinse, sau unul configurat să le refuze, își păstrează vechea rută implicită și nu trimite niciodată trafic de internet în tunel. Rezolvați această chestiune înainte de a schimba ceva pe server, pentru că nicio regulă din partea serverului nu poate compensa.

Redirecționarea este o setare a serverului, nu a VPN-ului

Citiți indicatorul de redirecționare înainte de a atinge rutarea. Un zero acolo înseamnă că nucleul primește pachetul clientului și refuză să îl transmită mai departe, ceea ce arată exact ca un blocaj al firewallului de la celălalt capăt. Setați valoarea prin directorul de configurare al sistemului, ca să supraviețuiască unei reporniri.

sysctl net.ipv4.ip_forward
echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-vpn-forward.conf
sudo sysctl --system

Apoi confirmați că gazda însăși are o rută funcțională către ieșirea de internet. O cerere din shell-ul serverului dovedește că calea din amonte este utilizabilă și nu spune absolut nimic despre redirecționarea pachetului unui client, așa că tratați-le ca două teste separate. Dacă serverul nu poate ajunge la destinație, nicio cantitate de configurare a redirecționării nu va ajuta.

Permiteți exact tranzitul pe care îl intenționați, și nimic altceva

Pachetele redirecționate traversează calea forward; traficul adresat gazdei VPN înseși traversează input. Sunt decizii diferite, iar deschiderea căii input nu permite tranzitul prin mașină. Confundarea lor este cel mai frecvent motiv pentru care un firewall pare să permită totul în timp ce clienții tot ajung în timeout.

O politică minimă acceptă conexiuni noi din pool către interfața de ieșire și acceptă răspunsuri care aparțin fluxurilor stabilite. Puneți-o la proprietarul setului de reguli pe care îl folosește distribuția voastră, în loc să adăugați o regulă duplicată la fiecare pornire; regulile duplicate se acumulează, iar contoarele nu mai înseamnă nimic.

sudo iptables -A FORWARD -i tun0 -o eth0 -s 10.90.0.0/24 -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Trecerea fiecărui lanț pe accept face testul să treacă și elimină motivul pentru care există firewallul. Păstrați domeniul pe pool și pe interfața de ieșire, și lăsați în pace redirecționarea nelegată.

Dați răspunsurilor un loc unde să meargă

Adresele pool-ului sunt private, așa că un server public nu le poate livra un răspuns direct. Fie gazda VPN traduce adresa sursă la ieșire, fie un dispozitiv din amonte deține o rută înapoi spre pool.

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

Adăugați exact un strat de traducere. Un al doilea NAT mai sus îl ascunde pe primul și face ambele jurnale aproape inutile când ceva se strică mai târziu. Dacă un router din amonte deja rutează pool-ul înapoi, adăugarea traducerii pe gazdă este redundantă, iar calea de întoarcere depinde atunci de configurația acelui router, nu de a voastră.

Instanțele din cloud adaugă încă o poartă, pentru că unele platforme aruncă pachetele a căror adresă sursă nu este a instanței decât dacă acea verificare este relaxată. Acea setare stă în afara invitatului și este ușor de uitat când o mașină de test locală funcționează.

Demonstrați-o din client, nu din shell-ul serverului

Începeți cu o cerere IPv4 numerică, apoi o căutare de nume, apoi aplicația. Un ping dovedește redirecționarea și traducerea;nu dovedește nimic despre rezolvarea numelor, pentru că opțiunile DNS intră în vigoare doar când integrarea clientului le instalează.

curl -4 -m 5 http://198.51.100.10/
dig +short example.com

Notați modificările și pasul de anulare pe parcurs, ca politica de ieșire să poată fi revertită cu o singură acțiune când un test eșuează. Această rețetă acoperă doar IPv4; inventariați IPv6 separat înainte de a afirma că implementarea transportă tot traficul.