Publiko një server shtëpiak përmes një VPS kur CGNAT bllokon portat

E nisa nga jashtë, ashtu siç do të bënte një përdorues: shkruaja emrin në shfletuesin e telefonit me të dhëna celulare dhe shihja lidhjen të varej derisa skadoi. Emri zgjidhej, pra DNS-ja ishte në rregull. Edhe faqja e ridrejtimit të porteve të ruterit të shtëpisë ishte rrugë pa krye, sepse adresa e saj WAN shfaqte 100.64.31.42, dhe kjo nuk është adresë drejt së cilës një ofrues më rrugëton nga interneti. Ai numër shpjegon gjithë dështimin: linja është pas carrier-grade NAT, pra adresa publike në anën time të tunelit i përket ofruesit. Ajo që vijon është rruga që ndoqa nga ai skedë e varur deri te një shërbim që përgjigjet.

Fillo te klienti dhe puno nga brenda

Para se të ndryshosh ndonjë rregull, provo ku ndalon zinxhiri. Në laptop ekzekutova dig +short files.example.net dhe mora adresën e VPS-së, gjë që përjashtonte DNS të vjetruar në makinën time. Më pas curl -v --connect-timeout 5 files.example.net:5022 skadoi në vend që të refuzohej. Kjo diferencë ka rëndësi: një skadim zakonisht do të thotë që paketat po hidhen gjatë rrugës, ndërsa një refuzim do të thotë që diçka u përgjigj dhe tha jo.

Hapi tjetër nga brenda ishte vetë VPS-ja. ss -ltnp nuk tregoi asgjë që dëgjonte në 5022, çka pritej para se të ekzistonte rregulli DNAT. Në të njëjtën makinë, wg show (ose ip -br a show tun0 për OpenVPN) konfirmoi se peer-i i shtëpisë ishte lart me një handshake të freskët. Nëse peer-i është poshtë, asnjë rregull NAT nuk ndihmon, dhe drita e gjelbër në faqen VPN të ruterit të shtëpisë nuk do të thotë asgjë.

Konfirmo se linja e shtëpisë është vërtet pas CGNAT

Krahaso adresën që ruteri raporton në ndërfaqen WAN me atë që sheh një shërbim i jashtëm. Çdo gjë në 100.64.0.0/10, pra 100.64.x.x deri 100.127.x.x, është diapazoni i adresave të përbashkëta nga RFC 6598 dhe nuk arrihet nga interneti. Në të njëjtin përfundim arrin kur ruteri pretendon një adresë private të zakonshme dhe një kërkim publik kthen diçka të palidhur. Një linjë CGNAT mund të vijë edhe me një adresë publike që zgjat vetëm deri në lease-in tjetër, kështu që një ridrejtim porti duket se funksionon një orë dhe pastaj vdes në heshtje.

Disa ofrues japin vërtet një adresë publike të vërtetë, por bllokojnë portat hyrëse 80 dhe 443 në llogaritë rezidenciale. Nëse shërbimi yt është vetëm web dhe adresa WAN është vërtet publike, pyet suportin para se të ndërtosh një relay. Nëse nuk është, dizajni më poshtë vlen njësoj për çdo port, dhe ia vlen ta ndalosh eksperimentin nga ana e ruterit: përkthyesi në rrjetin e ofruesit e përfundon lidhjen para se të arrijë ndonjëherë ndërfaqen tënde WAN.

Drejto emrin te adresa e VPS-së

DNS nuk e përcjell trafikun, pra rekordi A i shërbimit duhet të mbajë adresën publike të VPS-së. Një rekord A drejt 192.168.1.20 zgjidhet në mënyrë të dobishme vetëm për klientët që janë tashmë brenda VPN-së; nga interneti zgjidhet në një adresë që askush nuk mund ta rrugëtojë. Për aksesin administrativ të vetë VPS-së mbaj një emër të veçantë, që të mos ngatërroj kurrë se për cilin host flet një rekord.

Nëse si VPS-ja ashtu edhe makina e shtëpisë shërbejnë HTTP, jepi secilit emrin e vet dhe lëre VPS-në të vendosë kush përgjigjet. T’i bashkosh në një emër të vetëm dhe të shpresosh që proxy-ja zgjedh backend-in e duhur është pikërisht si kalon një pasdite duke debuguar hostin e gabuar.

DNAT një port, lëre SSH në 22

Opsioni i drejtpërdrejtë është NAT destinacioni në VPS. Aktivizo forwarding për kernelin që po ekzekutohet dhe mbaj adresën e tunelit të serverit të shtëpisë në rregull, jo adresën e tij 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

Lëre SSH drejt vetë VPS-së në 22 dhe përcjell një port tjetër, për shembull 5022, te makina e shtëpisë. Nëse përcjell 22 te një makinë e fikur, humbet rrugën e vetme që mund ta kishte rregulluar. E njëjta logjikë vlen për proxy-në: mbaj portën e administrimit të VPS-së jashtë rregullave të relay-t.

Bëji rregullat të përhershme sapo të funksionojnë. Në Debian ose Ubuntu, apt install iptables-persistent dhe më pas netfilter-persistent save i shkruajnë në /etc/iptables/rules.v4. Në një host me firewalld ekuivalenti është një forward-port i përhershëm në zonë, që kërkon firewall-cmd --reload para se të zbatohet. Rregullat që jetojnë vetëm në memorie zhduken në rindezjen e parë të mirëmbajtjes së ofruesit, zakonisht në një orë të keqe.

Rregullo rrugën e kthimit, ose shmang nevojën për të

DNAT rishkruan vetëm destinacionin. Serveri i shtëpisë sheh një lidhje nga adresa origjinale e klientit, dhe nëse rruga e tij parazgjedhur drejtohet te ruteri i shtëpisë, përgjigjja del nga shtëpia përmes WAN-it ku përkthyesi i ofruesit e hedh. Ajo asimetri ishte dështimi i dytë që takova, pasi rregulli DNAT dukej plotësisht i saktë.

Dy rregullime funksionojnë. Jepi makinës së shtëpisë një rrugë politike që trafiku nga tuneli të kthehet përmes tunelit:

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

Ose lëre VPS-në të rishkruajë burimin që përgjigjja të ketë një adresë që mund ta arrijë, dhe lëre conntrack ta kthejë mbrapsht në dalje:

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

Versioni SNAT e fsheh adresën e vërtetë të klientit nga serveri i shtëpisë, pra regjistrat e aplikacionit shfaqin 10.8.0.1 si peer. Përcille adresën origjinale në shtresën e aplikacionit, ose prano humbjen e regjistrimit për klient, por vendose me vetëdije në vend që ta zbulosh gjatë një incidenti.

Kontrollo gjithë rrugën nga jashtë

Verifiko nga një rrjet që nuk është as VPS-ja as shtëpia: një telefon me të dhëna celulare, ose një shell i lirë diku tjetër. nc -vz files.example.net 5022 duhet të raportojë një lidhje të suksesshme, dhe openssl s_client -connect files.example.net:443 -servername files.example.net duhet të shfaqë certifikatën për emrin publik. Më pas kontrollo security group ose firewall-in cloud të ofruesit. Një rregull DNAT që nuk sheh kurrë paketë zakonisht bllokohet një shtresë mbi hostin.

Së fundi, vendos çfarë ndodh kur tuneli bie. Një rregull DNAT vazhdon të pranojë lidhje dhe i fut ato në heshtje në një tunel të vdekur, gjë që duket saktësisht si shërbim i prishur. Një health check në VPS që refuzon portën ndërsa peer-i është poshtë kushton disa rreshta dhe kursen një orë hamendjesh. Pas kësaj, ndalo së redaktuarish rregulla dhe vëzhgoje një ditë para se t’i besosh.