De ce un server VPN din spatele CGNAT nu acceptă niciodată conexiuni

O adresă 100.64, un nume DNS dinamic care se rezolvă în altă parte și nicio strângere de mână de intrare sunt o singură problemă: NAT-ul operatorului. Confirmați-o, apoi retransmiteți traficul de ieșire.

Routerul raportează o adresă WAN care începe cu 100.72, numele DNS dinamic se rezolvă la o altă adresă publică, iar serverul VPN de pe acel router nu finalizează niciodată o strângere de mână din exterior. Redirecționarea porturilor este configurată, serviciul rulează, iar un test din LAN funcționează în continuare. Nimic din jurnalul routerului nu arată ca o eroare. Această combinație este NAT de nivel de operator, iar nicio regulă de firewall nu poate deschide un port pe o adresă pe care ISP-ul o deține.

Confirmarea adresei partajate durează două minute și previne o săptămână de modificări de configurare.

Semnele care indică NAT-ul operatorului

Comparați adresa WAN din pagina de stare a routerului cu adresa raportată de o interogare externă. O adresă WAN în 100.64.0.0/10 este semnul obișnuit, iar intervalele private 10/8, 172.16/12 și 192.168/16 înseamnă același lucru. Dacă traceroute arată același salt public repetat sau un salt timpuriu răspunde cu o adresă privată, între router și internet se află încă un traducător. Unii ISP listează adresa atribuită doar în portalul clienților, așa că exportați acea valoare împreună cu traceroute.

Schimbarea protocoalelor sau porturilor nu ajută, pentru că problema este accesibilitatea de intrare, nu un port închis.

De ce redirecționarea și DNS-ul dinamic nu o pot remedia

O regulă de redirecționare a portului mapează un port pe interfața WAN a routerului, dar traficul de intrare nu ajunge niciodată la acea interfață: ISP-ul îl traduce mai întâi și transmite doar ce permite propriul său tabel. Publicarea adresei partajate în DNS dinamic îndreaptă clienții spre o poartă a ISP-ului folosită de mulți abonați, de aceea numele se rezolvă, iar strângerea de mână tot eșuează. Testele hairpin reușesc pentru că routerul răspunde propriei reguli din interior, iar UPnP are exact același punct orb.

Nici reconfigurarea clientului nu va ajuta, deoarece defecțiunea apare înainte de a fi citită vreo setare a clientului.

Retransmitere printr-un VPS cu rute explicite

Puneți o adresă publică în față închiriind cel mai mic VPS care poate transporta traficul, apoi faceți routerul de acasă să se conecteze în ieșire către el. UDP-ul de ieșire din rețeaua de acasă trece prin NAT-ul operatorului, așa că tunelul se stabilește din interior, iar VPS-ul devine punctul final accesibil. Partea de acasă devine un client cu adresă fixă de tunel, nu un server.

Pe VPS, adăugați o intrare de director specifică clientului ca serverul să știe ce peer deține subrețeaua de acasă, și adăugați o rută de kernel corespunzătoare.

# /etc/openvpn/server/ccd/home-site.conf
ifconfig-push 10.8.0.10 255.255.255.0
iroute 192.168.50.0 255.255.255.0

# server.conf
client-config-dir /etc/openvpn/server/ccd
route 192.168.50.0 255.255.255.0
push "route 10.8.0.0 255.255.255.0"

Linia iroute spune OpenVPN care client primește traficul pentru subrețeaua de acasă; linia route pune acea subrețea în tabelul de kernel al VPS-ului ca pachetele să intre în tunel. Pentru un serviciu publicat, adăugați o regulă NAT de destinație care redirecționează portul public către 10.8.0.10 și activați net.ipv4.ip_forward.

Testați calea din exterior

Verificați fiecare salt pe partea publică, pentru că un tunel reușit nu dovedește că serviciul este accesibil. Starea de ascultare și captura de pachete pe VPS separă „nu a ajuns nimic” de „a ajuns și a fost aruncat”.

ss -lunp | grep 1194
tcpdump -ni any udp port 1194
nft list ruleset | grep -A4 dnat

# from a phone on mobile data, not the home Wi-Fi
nc -vz -u 203.0.113.10 1194

Dacă captura arată pachete de la telefon dar niciun răspuns, următoarea oprire este configurația serverului sau firewallul. Dacă captura nu arată nimic, clientul încă rezolvă sau trimite la adresa greșită.

Alternative care merită evaluate mai întâi

O adresă IPv4 dedicată de la ISP este cea mai scurtă soluție și de obicei costă o mică taxă lunară. IPv6 nativ elimină traducerea la ambele capete atunci când VPN-ul, rețeaua clientului și înregistrările DNS îl susțin toate. O suprapunere mesh cu un router de subrețea în rețeaua de acasă obține aceeași retransmitere fără VPS, cu prețul dependenței de un serviciu de coordonare.

Alegeți retransmiterea când cerința este acces de intrare stabil și fiecare regulă trebuie să rămână sub controlul dvs. Alegeți adresa ISP când bugetul permite și scopul este pur și simplu să nu vă mai gândiți la asta.

Articole similare