Objavljivanje kućnog poslužitelja preko VPS-a kad CGNAT blokira portove

Počeo sam izvana, kako bi to učinio korisnik: upisao sam ime u preglednik telefona na mobilnim podacima i gledao kako veza visi dok nije istekla. Ime se razrješavalo, pa je DNS bio u redu. Ni stranica za prosljeđivanje portova kućnog usmjerivača nije bila rješenje, jer je njezina adresa WAN pokazivala 100.64.31.42, a to nije adresa na koju me pružatelj usmjerava s interneta. Taj broj objašnjava cijeli kvar: linija je iza carrier-grade NAT, pa javna adresa na mojoj strani tunela pripada pružatelju. Ono što slijedi je put koji sam prešao od tog zaglavljenog taba do usluge koja odgovara.

Počni kod klijenta i idi prema unutra

Prije nego promijeniš bilo koje pravilo, dokaži gdje se lanac zaustavlja. Na prijenosniku sam pokrenuo dig +short files.example.net i dobio adresu VPS-a natrag, što je isključilo zastarjeli DNS na mom stroju. Zatim je curl -v --connect-timeout 5 files.example.net:5022 istekao umjesto da bude odbijen. Ta razlika je važna: istek obično znači da se paketi na putu odbacuju, dok odbijanje znači da je nešto odgovorilo i reklo ne.

Sljedeći skok prema unutra bio je sam VPS. ss -ltnp nije pokazao ništa što sluša na 5022, što se očekivalo prije nego što je pravilo DNAT postojalo. Na istom stroju wg show (ili ip -br a show tun0 za OpenVPN) potvrdio je da je kućni peer aktivan sa svježim handshakeom. Ako je peer dolje, nijedno NAT pravilo ne pomaže, a zeleno svjetlo na VPN stranici kućnog usmjerivača ne znači ništa.

Potvrdi da je kućna linija doista iza CGNAT-a

Usporedi adresu koju usmjerivač prijavljuje na svom WAN sučelju s onim što vidi vanjska usluga. Sve u 100.64.0.0/10, dakle od 100.64.x.x do 100.127.x.x, je raspon dijeljenih adresa iz RFC 6598 i nije dostupan s interneta. Do istog zaključka dolaziš kad usmjerivač tvrdi da ima običnu privatnu adresu, a javno pretraživanje vraća nešto nepovezano. Linija CGNAT može imati i javnu adresu koja vrijedi samo do sljedećeg leasea, pa prosljeđivanje porta izgleda da radi sat vremena i onda tiho umre.

Neki pružatelji doista daju pravu javnu adresu, ali blokiraju dolazne portove 80 i 443 na stambenim računima. Ako je tvoja usluga samo web i adresa WAN je uistinu javna, pitaj podršku prije nego izgradiš relay. Ako nije, donji dizajn vrijedi jednako za svaki port, i vrijedi zaustaviti eksperiment na strani usmjerivača: prevoditelj u mreži pružatelja prekida vezu prije nego što ikad stigne do tvog WAN sučelja.

Usmjeri ime na adresu VPS-a

DNS ne prenosi promet, pa zapis A usluge mora sadržavati javnu adresu VPS-a. Zapis A na 192.168.1.20 korisno se razrješava samo za klijente koji su već u VPN-u; s interneta se razrješava na adresu koju nitko ne može usmjeriti. Za administrativni pristup samom VPS-u držim zasebno ime, da nikad ne pobrkam na koje se računalo zapis odnosi.

Ako i VPS i kućni stroj poslužuju HTTP, daj svakome vlastito ime i pusti VPS da odluči tko odgovara. Spojiti ih u jedno ime i nadati se da će proxy odabrati pravi backend točno je kako provedeš cijelo poslijepodne otklanjajući pogreške na pogrešnom računalu.

Jedan port kroz DNAT, SSH ostaje na 22

Izravna opcija je odredišni NAT na VPS-u. Uključi forwarding za jezgru koja radi i drži adresu tunela kućnog poslužitelja u pravilu, ne njegovu LAN adresu:

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

Pusti SSH prema samom VPS-u na 22 i proslijedi drugi port, primjerice 5022, na kućni stroj. Ako proslijediš 22 na ugašen stroj, gubiš jedini put koji ga je mogao popraviti. Ista logika vrijedi za proxy: drži upravljački port VPS-a izvan pravila relayja.

Učini pravila trajnima kad prorade. Na Debianu ili Ubuntuu apt install iptables-persistent i zatim netfilter-persistent save zapisuju ih u /etc/iptables/rules.v4. Na računalu s firewalldom ekvivalent je trajno prosljeđivanje porta u zoni, koje prije primjene treba firewall-cmd --reload. Pravila koja žive samo u memoriji nestaju pri prvom servisnom restartu pružatelja, obično u loše doba.

Popravi povratnu rutu ili izbjegni potrebu za njom

DNAT prepisuje samo odredište. Kućni poslužitelj vidi vezu s izvorne adrese klijenta, a ako njegova zadana ruta pokazuje na kućni usmjerivač, odgovor izlazi kroz kućni WAN gdje ga prevoditelj pružatelja odbacuje. Ta asimetrija bila je drugi kvar na koji sam naišao, nakon što je pravilo DNAT izgledalo potpuno ispravno.

Dvije popravke djeluju. Daj kućnom stroju politiku rute da promet iz tunela ide natrag kroz tunel:

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

Ili pusti VPS da prepiše izvor kako bi odgovor imao adresu koju može dosegnuti, i pusti conntrack da ga na izlazu okrene:

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

Verzija SNAT skriva pravu adresu klijenta od kućnog poslužitelja, pa zapisi aplikacije pokazuju 10.8.0.1 kao peera. Proslijedi izvornu adresu na razini aplikacije ili prihvati gubitak bilježenja po klijentu, ali odluči to svjesno umjesto da otkriješ tijekom incidenta.

Provjeri cijeli put izvana

Provjeri iz mreže koja nije ni VPS ni kuća: telefon na mobilnim podacima ili jeftin shell negdje drugdje. nc -vz files.example.net 5022 bi trebao prijaviti uspješnu vezu, a openssl s_client -connect files.example.net:443 -servername files.example.net bi trebao pokazati certifikat za javno ime. Zatim provjeri sigurnosnu grupu ili cloud vatrozid pružatelja. Pravilo DNAT koje nikad ne vidi paket obično je blokirano jedan sloj iznad računala domaćina.

Naposljetku odluči što se događa kad tunel padne. Pravilo DNAT nastavlja prihvaćati veze i tiho ih šalje u mrtav tunel, što izgleda točno kao pokvarena usluga. Provjera zdravlja na VPS-u koja odbija port dok je peer dolje stoji nekoliko redaka i štedi sat nagađanja. Nakon toga prestani uređivati pravila i promatraj to jedan dan prije nego mu povjeruješ.