Pag-publish ng home server sa pamamagitan ng VPS kapag hinaharangan ng CGNAT ang mga port

Nagsimula ako mula sa labas, gaya ng gagawin ng isang gumagamit: itinipa ang pangalan sa browser ng telepono sa mobile data at pinanood ang koneksyon na nakabitin hanggang maubos ang oras. Naresolba ang pangalan, kaya maayos ang DNS. Pati ang pahina ng port forwarding ng router sa bahay ay dead end, dahil ang WAN address nito ay nagpapakita ng 100.64.31.42, at hindi iyon address na iparuruta sa akin ng provider mula sa internet. Ipinaliwanag ng numerong iyon ang buong pagkabigo: ang linya ay nasa likod ng carrier-grade NAT, kaya ang pampublikong address sa aking panig ng tunnel ay pag-aari ng provider. Ang sumusunod ay ang landas na nilakad ko mula sa nakabiting tab na iyon hanggang sa isang serbisyong sumasagot.

Magsimula sa kliyente at pumasok sa loob

Bago baguhin ang anumang patakaran, patunayang saan humihinto ang kadena. Sa laptop pinatakbo ko ang dig +short files.example.net at nakuha ang address ng VPS pabalik, na nagtanggal ng lumang DNS sa aking makina. Pagkatapos, ang curl -v --connect-timeout 5 files.example.net:5022 ay naubos ang oras sa halip na tanggihan. Mahalaga ang pagkakaibang ito: kadalasan ang pagkaubos ng oras ay nangangahulugang itinatapon ang mga packet sa daan, samantalang ang pagtanggi ay nangangahulugang may sumagot at nagsabing hindi.

Ang susunod na hakbang papasok ay ang VPS mismo. Walang ipinakita ang ss -ltnp na nakikinig sa 5022, na inaasahan bago pa umiral ang patakarang DNAT. Sa parehong makina, kinumpirma ng wg show (o ip -br a show tun0 para sa OpenVPN) na buhay ang peer sa bahay at may sariwang handshake. Kung patay ang peer, walang patakarang NAT ang makakatulong, at walang ibig sabihin ang berdeng ilaw sa pahina ng VPN ng router sa bahay.

Kumpirmahin na ang linya sa bahay ay talagang nasa likod ng CGNAT

Ihambing ang address na iniuulat ng router sa WAN interface nito sa nakikita ng panlabas na serbisyo. Anumang nasa 100.64.0.0/10, ibig sabihin mula 100.64.x.x hanggang 100.127.x.x, ay ang shared address range mula sa RFC 6598 at hindi maabot mula sa internet. Ganito rin ang konklusyon kapag sinasabi ng router na may ordinaryong pribadong address ito samantalang ang pampublikong paghahanap ay nagbabalik ng walang kaugnayan. Ang linya ng CGNAT ay maaari ring may pampublikong address na tumatagal lamang hanggang sa susunod na lease, kaya ang port forwarding ay mukhang gumagana nang isang oras at pagkatapos ay tahimik na namamatay.

May mga provider na talagang nagbibigay ng totoong pampublikong address pero hinaharangan ang papasok na port 80 at 443 sa residential accounts. Kung web lang ang serbisyo mo at totoo ang pampublikong WAN address, tanungin ang support bago magtayo ng relay. Kung hindi, ang disenyo sa ibaba ay pantay na naaangkop sa bawat port, at sulit ihinto ang eksperimento sa panig ng router: tinatapos ng tagasalin sa network ng provider ang koneksyon bago pa ito umabot sa iyong WAN interface.

Ituro ang pangalan sa address ng VPS

Hindi nagpapasa ng trapiko ang DNS, kaya kailangang taglayin ng A record ng serbisyo ang pampublikong address ng VPS. Ang A record patungo sa 192.168.1.20 ay naresolba nang kapaki-pakinabang lamang para sa mga kliyenteng nasa loob na ng VPN; mula sa internet, naresolba ito sa address na walang makakapagruta. Para sa administratibong pag-access ng VPS mismo, may hiwalay akong pangalan, para hindi ako malito kung aling host ang tinutukoy ng isang record.

Kung parehong naghahatid ng HTTP ang VPS at ang makina sa bahay, bigyan ang bawat isa ng sariling pangalan at hayaan ang VPS na magpasya kung sino ang sasagot. Ang pagsamahin sila sa isang pangalan at umasa na pipiliin ng proxy ang tamang backend ay siya mismong paraan para magpalipas ng isang hapon sa pag-debug ng maling host.

Isang port sa DNAT, manatili ang SSH sa 22

Ang direktang opsyon ay destination NAT sa VPS. Paganahin ang forwarding para sa tumatakbong kernel at itago ang tunnel address ng home server sa patakaran, hindi ang LAN address nito:

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

Iwanan ang SSH papunta sa VPS mismo sa 22 at i-forward ang ibang port, halimbawa 5022, papunta sa makina sa bahay. Kung i-forward mo ang 22 sa isang makinaryang patay, mawawala ang tanging daang makakapag-ayos nito. Ganoon din ang lohika sa proxy: itago ang management port ng VPS sa labas ng mga patakaran ng relay.

Gawing permanente ang mga patakaran kapag gumana na. Sa Debian o Ubuntu, isinusulat ito ng apt install iptables-persistent at pagkatapos ng netfilter-persistent save sa /etc/iptables/rules.v4. Sa host na may firewalld, ang katumbas ay permanenteng port forwarding sa zone, na nangangailangan ng firewall-cmd --reload bago magkabisa. Ang mga patakarang nabubuhay lamang sa memorya ay nawawala sa unang maintenance reboot ng provider, kadalasan sa masamang oras.

Ayusin ang pabalik na ruta, o iwasan ang pangangailangan dito

Ang DNAT ay nagsusulat muli lamang ng destinasyon. Nakikita ng home server ang koneksyon mula sa orihinal na address ng kliyente, at kung ang default route nito ay patungo sa router sa bahay, lumalabas ang sagot sa WAN ng bahay kung saan itinatapon ito ng tagasalin ng provider. Ang kawalan ng simetrya na iyon ang ikalawang pagkabigo kong natagpuan, pagkatapos na mukhang ganap na tama ang patakarang DNAT.

Dalawang pagwawasto ang gumagana. Bigyan ang makina sa bahay ng policy route para bumalik sa tunnel ang trapikong galing sa tunnel:

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

O hayaang isulat muli ng VPS ang source para may address ang sagot na maaabot nito, at hayaang baliktarin ito ng conntrack sa labasan:

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

Itinatago ng bersyong SNAT ang totoong address ng kliyente mula sa home server, kaya ang mga log ng aplikasyon ay nagpapakita ng 10.8.0.1 bilang peer. Ipasa ang orihinal na address sa antas ng aplikasyon, o tanggapin ang pagkawala ng per-client na pag-log, pero magpasya nang sadya sa halip na matuklasan ito habang may insidente.

Suriin ang buong landas mula sa labas

I-verify mula sa network na hindi ang VPS at hindi ang bahay: telepono sa mobile data, o murang shell sa ibang lugar. Dapat iulat ng nc -vz files.example.net 5022 ang matagumpay na koneksyon, at dapat ipakita ng openssl s_client -connect files.example.net:443 -servername files.example.net ang certificate para sa pampublikong pangalan. Pagkatapos, suriin ang security group o cloud firewall ng provider. Ang patakarang DNAT na hindi kailanman nakakakita ng packet ay karaniwang hinaharangan isang antas sa itaas ng host.

Sa huli, magpasya kung ano ang mangyayari kapag bumagsak ang tunnel. Patuloy na tumatanggap ng koneksyon ang patakarang DNAT at tahimik na ipinapasok ang mga ito sa patay na tunnel, na mukhang eksaktong sirang serbisyo. Ang health check sa VPS na tumatanggi sa port habang patay ang peer ay ilang linya lamang ang halaga at nakakatipid ng isang oras na hulaan. Pagkatapos nito, itigil ang pag-edit ng patakaran at panoorin ito nang isang araw bago mo ito pagkatiwalaan.