Birta heimilþjón í gegnum VPS þegar CGNAT lokar portum

Ég byrjaði utan frá, eins og notandi myndi gera: sló nafnið inn í vafra síma á farsímagögnum og horfði á tenginguna hanga þar til hún féll á tíma. Nafnið leystist, svo DNS var í lagi. Port-forward-síða heimilisbeinanna var líka blindgata, því WAN-talan var 100.64.31.42, og það er ekki tal sem þjónustuveitandi beinir til mín frá internetinu. Þessi tala útskýrir alla bilunina: línan er bak við carrier-grade NAT, svo opinbera talið mínu megin við göngin tilheyrir þjónustuveitandanum. Það sem fylgir er leiðin sem ég gekk frá þeim hangandi flipa að þjónustu sem svarar.

Byrjaðu á biðlaranum og vinnðu inn á við

Áður en þú breytir nokkurri reglu skaltu sanna hvar keðjan stöðvast. Á fartölvunni keyrði ég dig +short files.example.net og fékk VPS-talið til baka, sem útilokaði gamalt DNS á vélinni minni. Síðan féll curl -v --connect-timeout 5 files.example.net:5022 á tíma í stað þess að vera hafnað. Sá munur skiptir máli: tími þýðir yfirleitt að pakkar séu felldir á leiðinni, en höfnun þýðir að eitthvað svaraði og sagði nei.

Næsta stökk inn á við var VPS-inn sjálfur. ss -ltnp sýndi ekkert sem hlustaði á 5022, sem var viðbúið áður en DNAT-reglan var til. Á sömu vél staðfesti wg show (eða ip -br a show tun0 fyrir OpenVPN) að heimilisfélaginn væri uppi með nýlegt handaband. Ef félaginn er niðri hjálpar engin NAT-regla, og græna ljósið á VPN-síðu heimilisbeinanna þýðir ekkert.

Staðfestu að heimilislínan sé raunverulega bak við CGNAT

Berðu saman talið sem beinin segja á WAN-viðmótinu og það sem utanaðkomandi þjónusta sér. Allt í 100.64.0.0/10, það er 100.64.x.x til 100.127.x.x, er sameiginlega talnasviðið frá RFC 6598 og næst ekki frá internetinu. Þú kemst að sömu niðurstöðu þegar beinin segja venjulegt einkatal og opin leit skilar einhverju ótengdu. CGNAT-lína getur líka komið með opið tal sem varir aðeins til næstu leigu, svo port forward virðist virka í klukkustund og deyr svo hljóðlega.

Sumir þjónustuveitendur gefa raunverulega opið tal en loka á innkomandi 80 og 443 á heimilisáskriftum. Ef þjónustan þín er eingöngu vefur og WAN-talið er raunverulega opið, spurðu þjónustuverið áður en þú byggir relay. Ef ekki gildir hönnunin hér að neðan fyrir hvern port jafnt, og það borgar sig að stöðva tilraunina á beinunum: umbreytirinn í neti þjónustuveitandans lokar tengingunni áður en hún nær nokkurn tíma WAN-viðmótinu þínu.

Beindu nafninu að VPS-talinu

DNS millifærir ekki umferð, svo A-færslan fyrir þjónustuna verður að geyma opið tal VPS-ins. A-færsla að 192.168.1.20 leysist aðeins nytsamlega fyrir biðlara sem eru þegar inni í VPN-inu; frá internetinu leysist hún í tal sem enginn getur beint. Fyrir stjórnunaraðgang VPS-ins sjálfs held ég sér nafni svo ég ruglist aldrei á hvaða hýsil færsla vísar á.

Ef bæði VPS-inn og heimiliskassinn þjóna HTTP skaltu gefa hvorum sitt nafn og láta VPS-inn ráða hver svarar. Að brjóta þau saman í eitt nafn og vona að milliþjónninn velji rétt bakenda er einmitt hvernig þú eyðir síðdegi í að kemba rangt hýsil.

DNAT einn port, hafðu SSH á 22

Beini valkosturinn er destination NAT á VPS-inum. Kveiktu á forwarding fyrir kjarnann sem keyrir og hafðu göngutal heimilissins í reglunni, ekki LAN-talið:

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

Hafðu SSH að VPS-inum sjálfum á 22 og framsendu annan port, til dæmis 5022, til heimilivélarinnar. Ef þú framsendir 22 á kassa sem er niðri tapar þú einu leiðinni sem hefði getað lagað hann. Sama rökfræði gildir um milliþjóninn: hafðu stjórnport VPS-ins utan relay-reglnanna.

Gerðu reglurnar varanlegar þegar þær virka. Á Debian eða Ubuntu skrifar apt install iptables-persistent og síðan netfilter-persistent save þær í /etc/iptables/rules.v4. Á firewalld-hýsil er hliðstæðan varanleg forward-port á svæðinu, sem þarf firewall-cmd --reload áður en hún gildir. Reglur sem lifa aðeins í minni hverfa við fyrstu viðhaldsendurræsingu veitandans, venjulega á vondri stundu.

Lagaðu bakleiðina, eða slepptu því að þurfa hana

DNAT endurskrifar aðeins áfangastaðinn. Heimilissinn sér tengingu frá upprunalega biðlaratalinu, og ef sjálfgefna leiðin vísar á heimilisbeinin fer svarið út úr húsinu um WAN-ið þar sem umbreytir veitandans fellir það. Þessi ósamhverfa var önnur bilunin sem ég lenti í, eftir að DNAT-reglan leit út fyrir að vera fullkomlega rétt.

Tvær lagfæringar virka. Gefðu heimiliskassanum stefnuleið svo umferð frá göngunum fari til baka um göngin:

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

Eða láttu VPS-inn endurskrifa uppruna svo svarið hafi tal sem hann nær til, og láttu conntrack snúa því við á leið út:

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

SNAT-útgáfan felur raunverulega biðlaratalið fyrir heimilissinum, svo forritaskrár sýna 10.8.0.1 sem félaga. Sendu upprunalega talið áfram á forritalaginu, eða sættu þig við að missa skráningu per biðlara, en ákveddu það viljandi í stað þess að uppgötva það í atviki.

Athugaðu alla leiðina utan frá

Sannprófaðu frá neti sem er hvorki VPS-inn né húsið: sími á farsímagögnum, eða ódýrt skel annars staðar. nc -vz files.example.net 5022 ætti að tilkynna tekna tengingu, og openssl s_client -connect files.example.net:443 -servername files.example.net ætti að sýna skírteinið fyrir opinbera nafnið. Athugaðu síðan security group eða skýjavegg veitandans. DNAT-regla sem sér aldrei pakka er venjulega blokkuð einu lagi ofar en hýsilinn.

Að lokum: ákveddu hvað gerist þegar göngin falla. DNAT-regla heldur áfram að taka við tengingum og færir þær hljóðlega inn í dauð göng, sem lítur nákvæmlega út eins og biluð þjónusta. Health check á VPS-inum sem hafnar portinum meðan félaginn er niðri kostar nokkrar línur og sparar klukkustund af getgátum. Hættu þá að breyta reglum og fylgstu með þessu í sólarhring áður en þú treystir því.