Objavljanje domačega strežnika prek VPS, ko CGNAT blokira vrata

Začel sem od zunaj, kot bi storil uporabnik: vpisal sem ime v brskalniku telefona na mobilnih podatkih in gledal, kako povezava visi, dokler ni potekel čas. Ime se je razreševalo, torej je bil DNS v redu. Tudi stran za posredovanje vrat na domačem usmerjevalniku je bila slepa ulica, ker je njen naslov WAN kazal 100.64.31.42, in to ni naslov, kamor bi me ponudnik usmerjal z interneta. Ta številka pojasni celotno okvaro: linija je za carrier-grade NAT, zato javni naslov na moji strani tunela pripada ponudniku. Kar sledi, je pot, ki sem jo prehodil od tistega zataknjenega zavihka do storitve, ki odgovarja.

Začni pri odjemalcu in pojdi navznoter

Preden spremeniš katero koli pravilo, dokaži, kje se veriga ustavi. Na prenosniku sem zagnal dig +short files.example.net in dobil naslov VPS nazaj, kar je izključilo zastarel DNS na mojem stroju. Nato je curl -v --connect-timeout 5 files.example.net:5022 potekel, namesto da bi bil zavrnjen. Ta razlika je pomembna: potek običajno pomeni, da se paketi na poti zavržejo, medtem ko zavrnitev pomeni, da je nekaj odgovorilo in reklo ne.

Naslednji skok navznoter je bil sam VPS. ss -ltnp ni pokazal ničesar, kar bi poslušalo na 5022, kar je bilo pričakovano pred nastankom pravila DNAT. Na istem stroju je wg show (ali ip -br a show tun0 za OpenVPN) potrdil, da je domači peer pokonci in ima svež handshake. Če peer ne deluje, nobeno pravilo NAT ne pomaga, in zelena lučka na strani VPN domačega usmerjevalnika ne pomeni nič.

Potrdi, da je domača linija res za CGNAT

Primerjaj naslov, ki ga usmerjevalnik poroča na vmesniku WAN, s tem, kar vidi zunanja storitev. Vse v 100.64.0.0/10, torej od 100.64.x.x do 100.127.x.x, je obseg skupnih naslovov iz RFC 6598 in z interneta ni dosegljiv. Do enakega sklepa prideš, ko usmerjevalnik trdi, da ima običajen zasebni naslov, javno iskanje pa vrne nekaj nepovezanega. Linija CGNAT ima lahko tudi javni naslov, ki velja le do naslednjega lease, zato je videti, da posredovanje vrat deluje eno uro, nato pa tiho umre.

Nekateri ponudniki res dajo pravi javni naslov, a blokirajo dohodna vrata 80 in 443 na stanovanjskih računih. Če je tvoja storitev samo spletna in je naslov WAN resnično javen, vprašaj podporo, preden zgradiš relay. Če ni, spodnja zasnova velja enako za vsaka vrata, in vredno je ustaviti poskus na strani usmerjevalnika: prevajalnik v omrežju ponudnika konča povezavo, preden ta sploh doseže tvoj vmesnik WAN.

Usmeri ime na naslov VPS

DNS ne posreduje prometa, zato mora zapis A storitve vsebovati javni naslov VPS. Zapis A na 192.168.1.20 se uporabno razreši le za odjemalce, ki so že v VPN; z interneta se razreši na naslov, ki ga nihče ne more usmeriti. Za skrbniški dostop do samega VPS hranim ločeno ime, da nikoli ne zamenjam, na kateri gostitelj kaže zapis.

Če HTTP strežeta tako VPS kot domači stroj, daj vsakemu svoje ime in pusti VPS, da odloči, kdo odgovarja. Zložiti ju v eno ime in upati, da bo proxy izbral pravi backend, je natanko to, kako preživiš celo popoldne z razhroščevanjem napačnega gostitelja.

Ena vrata z DNAT, SSH ostane na 22

Neposredna možnost je ciljni NAT na VPS. Vklopi forwarding za jedro, ki teče, in obdrži naslov tunela domačega strežnika v pravilu, ne njegovega naslova 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

Pusti SSH do samega VPS na 22 in posreduj druga vrata, na primer 5022, na domači stroj. Če posreduješ 22 na izklopljen stroj, izgubiš edino pot, ki bi ga lahko popravila. Ista logika velja za proxy: drži skrbniška vrata VPS zunaj pravil relayja.

Naredi pravila trajna, ko delujejo. Na Debianu ali Ubuntu jih apt install iptables-persistent in nato netfilter-persistent save zapišeta v /etc/iptables/rules.v4. Na gostitelju s firewalld je ustreznica trajno posredovanje vrat v coni, ki pred veljavnostjo potrebuje firewall-cmd --reload. Pravila, ki živijo le v pomnilniku, izginejo ob prvem vzdrževalnem ponovnem zagonu ponudnika, običajno ob slabi uri.

Popravi povratno pot ali se izogni potrebi po njej

DNAT prepiše le cilj. Domači strežnik vidi povezavo z izvornega naslova odjemalca, in če njegova privzeta pot kaže na domači usmerjevalnik, odgovor zapusti hišo skozi WAN, kjer ga prevajalnik ponudnika zavrže. Ta asimetrija je bila druga okvara, na katero sem naletel, potem ko je pravilo DNAT izgledalo popolnoma pravilno.

Dve popravki delujeta. Daj domačemu stroju politično pot, da promet iz tunela gre nazaj skozi tunel:

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

Ali pusti VPS, da prepiše vir, da ima odgovor naslov, ki ga lahko doseže, in pusti conntrack, da ga na poti ven obrne:

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

Različica SNAT skrije pravi naslov odjemalca pred domačim strežnikom, zato dnevnik aplikacije kaže 10.8.0.1 kot peer. Posreduj izvirni naslov na aplikacijskem nivoju ali sprejmi izgubo beleženja po odjemalcih, a odloči se zavestno, namesto da bi to odkril med incidentom.

Preveri celotno pot od zunaj

Preveri iz omrežja, ki ni niti VPS niti hiša: telefon na mobilnih podatkih ali poceni shell drugje. nc -vz files.example.net 5022 bi moralo poročati uspešno povezavo, openssl s_client -connect files.example.net:443 -servername files.example.net pa bi moralo pokazati potrdilo za javno ime. Nato preveri varnostno skupino ali oblačni požarni zid ponudnika. Pravilo DNAT, ki nikoli ne vidi paketa, je običajno blokirano eno plast nad gostiteljem.

Na koncu se odloči, kaj se zgodi, ko tunel pade. Pravilo DNAT še naprej sprejema povezave in jih tiho pošilja v mrtev tunel, kar je videti natanko kot pokvarjena storitev. Preverjanje stanja na VPS, ki zavrne vrata, dokler peer ne deluje, stane nekaj vrstic in prihrani uro ugibanja. Potem nehaj urejati pravila in ga opazuj en dan, preden mu zaupaš.