Publikigi hejman servilon per VPS kiam CGNAT blokas pordojn

Mi komencis de ekstere, kiel uzanto farus: tajpis la nomon en la retumilo de telefono sur portebla datumaro kaj vidis la konekton pendi ĝis ĝi tempis el. La nomo solviĝis, do DNS estis en ordo. Ankaŭ la pordvarba paĝo de la hejma enkursigilo estis sakstrato, ĉar ĝia WAN-adreso estis 100.64.31.42, kaj tio ne estas adreso al kiu provizanto enkursigos min de la interreto. Tiu numero klarigas la tutan fiaskon: la linio situas malantaŭ carrier-grade NAT, do la publika adreso miaflanke de la tunelo apartenas al la provizanto. Tio, kio sekvas, estas la vojo, kiun mi iris de tiu pendanta langeto ĝis servo, kiu respondas.

Komencu ĉe la kliento kaj laboru internen

Antaŭ ol ŝanĝi ajnan regulon, pruvu, kie la ĉeno haltas. Sur la tekokomputilo mi lanĉis dig +short files.example.net kaj rericevis la adreson de la VPS, kio ekskludis malnoviĝintan DNS sur mia maŝino. Poste curl -v --connect-timeout 5 files.example.net:5022 tempis el anstataŭ esti rifuzita. Tiu diferenco gravas: tempeliro kutime signifas, ke pakaĵoj estas forĵetataj survoje, dum rifuzo signifas, ke io respondis kaj diris ne.

La sekva salto internen estis la VPS mem. ss -ltnp montris nenion aŭskultantan sur 5022, kio estis atendita antaŭ ol ekzistis la regulo DNAT. Sur la sama maŝino wg show (aŭ ip -br a show tun0 por OpenVPN) konfirmis, ke la hejma peer estis supre kun freŝa manpremo. Se la peer estas malsupre, neniu NAT-regulo helpos, kaj la verda lumo sur la VPN-paĝo de la hejma enkursigilo signifas nenion.

Konfirmu, ke la hejma linio vere situas malantaŭ CGNAT

Komparu la adreson, kiun la enkursigilo raportas sur sia WAN-interfaco, kun tio, kion vidas ekstera servo. Ĉio en 100.64.0.0/10, do 100.64.x.x ĝis 100.127.x.x, estas la dividita adresaro el RFC 6598 kaj ne estas atingebla de la interreto. Vi venas al la sama konkludo, kiam la enkursigilo asertas ordinaran privatan adreson kaj publika serĉo redonas ion nerilatan. CGNAT-linio ankaŭ povas veni kun publika adreso, kiu daŭras nur ĝis la sekva luo, tiel ke pordvarbado ŝajnas funkcii dum horo kaj poste silente mortas.

Iuj provizantoj ja donas veran publikan adreson, sed blokas envenantajn 80 kaj 443 ĉe loĝejaj kontoj. Se via servo estas nur reteja kaj la WAN-adreso estas vere publika, demandu la subtenon antaŭ ol konstrui relajson. Se ĝi ne estas, la suba dezajno validas egale por ĉiu pordo, kaj indas ĉesigi la eksperimenton ĉe la enkursigilo: la tradukilo en la reto de la provizanto finas la konekton antaŭ ol ĝi iam ajn atingas vian WAN-interfacon.

Direktu la nomon al la adreso de la VPS

DNS ne plusendadas trafikon, do la A-rikordo por la servo devas enhavi la publikan adreson de la VPS. A-rikordo al 192.168.1.20 solviĝas utile nur por klientoj jam ene de la VPN; de la interreto ĝi solviĝas al adreso, kiun neniu povas enkursigi. Por la administra aliro de la VPS mem mi tenas apartan nomon, por ke mi neniam konfuzu, al kiu gastiganto rikordo montras.

Se kaj la VPS kaj la hejma maŝino servas HTTP, donu al ĉiu sian propran nomon kaj lasu la VPS-on decidi, kiu respondu. Kunfaldi ilin en unu nomon kaj esperi, ke la prokurilo elektos la ĝustan malantaŭan servon, estas ĝuste kiel vi pasigos posttagmezon sencimigante la malĝustan gastiganton.

DNAT unu pordon, lasu SSH sur 22

La rekta opcio estas cel-NAT sur la VPS. Ŝaltu plusendadon por la kuranta kerno kaj tenu la tunelan adreson de la hejma servilo en la regulo, ne ĝian LAN-adreson:

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

Lasu SSH al la VPS mem sur 22 kaj plusendu alian pordon, ekzemple 5022, al la hejma maŝino. Se vi plusendas 22 al maŝino, kiu estas malsupre, vi perdas la solan vojon, kiu povintus ripari ĝin. La sama logiko validas por la prokurilo: tenu la administran pordon de la VPS ekster la relajsaj reguloj.

Faru la regulojn daŭraj, kiam ili funkcias. Sur Debian aŭ Ubuntu, apt install iptables-persistent kaj poste netfilter-persistent save skribas ilin al /etc/iptables/rules.v4. Sur firewalld-gastiganto la ekvivalento estas permanenta plusenda pordo sur la zono, kiu bezonas firewall-cmd --reload antaŭ ol ĝi validas. Reguloj, kiuj vivas nur en memoro, malaperas ĉe la unua prizorga restartigo de la provizanto, kutime je malbona horo.

Riparu la revenan vojon, aŭ evitu bezoni ĝin

DNAT reskribas nur la celon. La hejma servilo vidas konekton de la origina klienta adreso, kaj se ĝia defaŭlta vojo montras al la hejma enkursigilo, la respondo forlasas la domon tra la WAN, kie la tradukilo de la provizanto forĵetas ĝin. Tiu nesimetrio estis la dua fiasko, kiun mi trafis, post kiam la DNAT-regulo aspektis tute ĝusta.

Du riparoj funkcias. Donu al la hejma maŝino politikan vojon, por ke trafiko el la tunelo reiru tra la tunelo:

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

Aŭ lasu la VPS-on reskribi la fonton, por ke la respondo havu adreson, kiun ĝi povas atingi, kaj lasu conntrack renversi ĝin ĉe la eliro:

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

La SNAT-versio kaŝas la veran klientan adreson de la hejma servilo, do la aplikaĝoj montras 10.8.0.1 kiel peer. Plusendu la originan adreson ĉe la aplika tavolo, aŭ akceptu perdi protokoladon por kliento, sed decida tion konscie anstataŭ malkovri ĝin dum incidento.

Kontrolu la tutan vojon de ekstere

Kontrolu el reto, kiu estas nek la VPS nek la domo: telefono sur portebla datumaro, aŭ malmultekosta ŝelo aliloke. nc -vz files.example.net 5022 devus raporti sukcesan konekton, kaj openssl s_client -connect files.example.net:443 -servername files.example.net devus montri la atestilon por la publika nomo. Poste kontrolu la sekurecgrupigon aŭ nuban fajrmuron de la provizanto. DNAT-regulo, kiu neniam vidas pakaĵon, estas kutime blokata unu tavolon super la gastiganto.

Fine, decidu, kio okazas, kiam la tunelo falas. DNAT-regulo daŭre akceptas konektojn kaj silente enkondukas ilin en mortan tunelon, kio aspektas ĝuste kiel difektita servo. Sanokontrolo sur la VPS, kiu rifuzas la pordon dum la peer estas malsupre, kostas kelkajn liniojn kaj ŝparas horon da konjektado. Poste ĉesu redakti regulojn kaj observu ĝin dum tago antaŭ ol fidi ĝin.