Publicarea unui server de acasă printr-un VPS când CGNAT blochează porturile

Am început din exterior, așa cum ar face un utilizator: am tastat numele în browserul unui telefon pe date mobile și am privit conexiunea cum atârna până a expirat. Numele se rezolva, deci DNS-ul era în regulă. Nici pagina de redirecționare de porturi a routerului de acasă nu ducea nicăieri, pentru că adresa ei WAN afișa 100.64.31.42, iar aceea nu este o adresă către care un furnizor să mă ruteze din internet. Acel număr explică întreaga defecțiune: linia se află în spatele carrier-grade NAT, deci adresa publică din partea mea a tunelului aparține furnizorului. Ce urmează este drumul pe care l-am parcurs de la acel tab blocat până la un serviciu care răspunde.

Începe de la client și mergi spre interior

Înainte de a schimba vreo regulă, dovedește unde se oprește lanțul. Pe laptop am rulat dig +short files.example.net și am primit adresa VPS-ului, ceea ce excludea un DNS învechit pe mașina mea. Apoi curl -v --connect-timeout 5 files.example.net:5022 a expirat în loc să fie refuzat. Diferența contează: un timeout înseamnă de obicei că pachetele sunt aruncate pe drum, în timp ce un refuz înseamnă că ceva a răspuns și a spus nu.

Următorul salt spre interior era VPS-ul însuși. ss -ltnp nu arăta nimic care să asculte pe 5022, ceea ce era de așteptat înainte să existe regula DNAT. Pe aceeași mașină, wg show (sau ip -br a show tun0 pentru OpenVPN) a confirmat că peer-ul de acasă era activ, cu un handshake recent. Dacă peer-ul este jos, nicio regulă NAT nu ajută, iar lumina verde de pe pagina VPN a routerului de acasă nu înseamnă nimic.

Confirmă că linia de acasă este într-adevăr în spatele CGNAT

Compară adresa pe care routerul o raportează pe interfața WAN cu ceea ce vede un serviciu extern. Tot ce se află în 100.64.0.0/10, adică 100.64.x.x până la 100.127.x.x, este intervalul de adrese partajate din RFC 6598 și nu poate fi atins din internet. Ajungi la aceeași concluzie când routerul susține că are o adresă privată obișnuită, iar o căutare publică returnează ceva fără legătură. O linie CGNAT poate veni și cu o adresă publică valabilă doar până la următorul lease, astfel încât o redirecționare de port pare să funcționeze o oră și apoi moare în tăcere.

Unii furnizori oferă într-adevăr o adresă publică reală, dar blochează porturile de intrare 80 și 443 pe conturile rezidențiale. Dacă serviciul tău este doar web și adresa WAN este cu adevărat publică, întreabă suportul înainte de a construi un relay. Dacă nu este, proiectarea de mai jos se aplică la fel pentru fiecare port, și merită să oprești experimentul din partea routerului: translatorul din rețeaua furnizorului închide conexiunea înainte ca ea să ajungă la interfața ta WAN.

Îndreaptă numele spre adresa VPS-ului

DNS-ul nu retransmite trafic, deci înregistrarea A a serviciului trebuie să conțină adresa publică a VPS-ului. O înregistrare A către 192.168.1.20 se rezolvă util doar pentru clienții care sunt deja în VPN; din internet se rezolvă către o adresă pe care nimeni nu o poate ruta. Pentru accesul de administrare al VPS-ului păstrez un nume separat, ca să nu confund niciodată către ce host duce o înregistrare.

Dacă atât VPS-ul, cât și calculatorul de acasă servesc HTTP, dă fiecăruia propriul nume și lasă VPS-ul să decidă cine răspunde. Să le unești într-un singur nume și să speri că proxy-ul alege backend-ul corect este exact modul în care ajungi să depanezi hostul greșit o după-amiază întreagă.

Un port prin DNAT, SSH rămâne pe 22

Opțiunea directă este NAT de destinație pe VPS. Activează forwarding-ul pentru kernelul care rulează și păstrează adresa de tunel a serverului de acasă în regulă, nu adresa lui LAN:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -p tcp -d 198.51.100.10 --dport 5022 -j DNAT --to-destination 10.8.0.2

Lasă SSH către VPS pe 22 și redirecționează alt port, de exemplu 5022, către mașina de acasă. Dacă redirecționezi 22 către o mașină oprită, pierzi singura cale care ar fi putut să o repare. Aceeași logică se aplică proxy-ului: ține portul de administrare al VPS-ului în afara regulilor de relay.

Fă regulile persistente odată ce funcționează. Pe Debian sau Ubuntu, apt install iptables-persistent și apoi netfilter-persistent save le scriu în /etc/iptables/rules.v4. Pe un host cu firewalld, echivalentul este un forward-port permanent pe zonă, care are nevoie de firewall-cmd --reload înainte de a se aplica. Regulile care trăiesc doar în memorie dispar la prima repornire de mentenanță a furnizorului, de obicei la o oră proastă.

Repară ruta de întoarcere sau evită nevoia de ea

DNAT rescrie doar destinația. Serverul de acasă vede o conexiune de la adresa clientului original, iar dacă ruta lui implicită duce către routerul de acasă, răspunsul pleacă prin WAN-ul casei, unde translatorul furnizorului îl aruncă. Acea asimetrie a fost a doua defecțiune pe care am întâlnit-o, după ce regula DNAT părea complet corectă.

Două remedii funcționează. Dă mașinii de acasă o rută de politică, astfel încât traficul din tunel să se întoarcă prin tunel:

ip rule add from 10.8.0.2 table 100
ip route add default dev wg0 table 100

Sau lasă VPS-ul să rescrie sursa, astfel încât răspunsul să aibă o adresă pe care o poate atinge, și lasă conntrack să o inverseze la ieșire:

iptables -t nat -A POSTROUTING -d 10.8.0.2 -p tcp --dport 5022 -j SNAT --to-source 10.8.0.1

Versiunea SNAT ascunde adresa reală a clientului față de serverul de acasă, așa că logurile aplicației arată 10.8.0.1 ca peer. Transmite adresa originală la nivelul aplicației sau acceptă pierderea logării per client, dar decide deliberat, în loc să descoperi asta în timpul unui incident.

Verifică tot traseul din exterior

Verifică dintr-o rețea care nu este nici VPS-ul, nici casa: un telefon pe date mobile sau un shell ieftin în altă parte. nc -vz files.example.net 5022 ar trebui să raporteze o conexiune reușită, iar openssl s_client -connect files.example.net:443 -servername files.example.net ar trebui să arate certificatul pentru numele public. Apoi verifică security group-ul sau firewall-ul cloud al furnizorului. O regulă DNAT care nu vede niciodată un pachet este de obicei blocată cu un nivel deasupra hostului.

În final, decide ce se întâmplă când tunelul cade. O regulă DNAT continuă să accepte conexiuni și le împinge în tăcere într-un tunel mort, ceea ce arată exact ca un serviciu stricat. Un health check pe VPS care refuză portul cât timp peer-ul este jos costă câteva linii și economisește o oră de presupuneri. După aceea, nu mai edita reguli și urmărește-l o zi înainte să te bazezi pe el.