Etxeko zerbitzari bat VPS baten bidez argitaratzea CGNAT-ek portuak blokeatzen dituenean

Kanpotik hasi nintzen, erabiltzaile batek egingo lukeen bezala: izena telefonoaren nabigatzailean idatzi nuen datu mugikorrekin eta konexioa zintzilik geratu zen denbora agortu arte. Izena ebazten zen, beraz DNSa ondo zegoen. Etxeko routerraren portu-birbidalketa orria ere kale itsua zen, haren WAN helbideak 100.64.31.42 erakusten baitzuen, eta hori ez da hornitzaile batek internetetik niregana bideratuko lukeen helbidea. Zenbaki horrek azaltzen du hutsegite osoa: linea carrier-grade NAT atzean dago, beraz tuneleko nire aldeko helbide publikoa hornitzailearena da. Hurrengo hau tab zintzilikatu hartatik erantzuten duen zerbitzu batera egindako bidea da.

Hasi bezerotik eta joan barrurantz

Edozein arau aldatu aurretik, frogatu katea non gelditzen den. Mahaigainean dig +short files.example.net exekutatu nuen eta VPSren helbidea jaso nuen, nire makinan DNS zaharkitua baztertuz. Gero curl -v --connect-timeout 5 files.example.net:5022 denbora agortu zen ukatu beharrean. Aldea garrantzitsua da: denbora-agorrak normalean paketeak bidean botatzen ari direla esan nahi du, ukapenak berriz zerbait erantzun eta ezetz esan duela.

Hurrengo jauzia barrurantz VPS bera zen. ss -ltnp ez zuen ezer erakutsi 5022n entzuten, DNAT araua existitu aurretik espero zitekeena. Makina berean, wg show (edo ip -br a show tun0 OpenVPNrako) etxeko peerra aktibo zegoela baieztatu zuen, handshake berri batekin. Peerra behera badago, NAT arau bakar batek ere ez du lagunduko, eta etxeko routerraren VPN orrialdeko argi berdeak ez du ezer esan nahi.

Baieztatu etxeko linea benetan CGNAT atzean dagoela

Alderatu routerrak bere WAN interfazean ematen duen helbidea kanpoko zerbitzu batek ikusten duenarekin. 100.64.0.0/10 barrutian dagoen guztia, hau da, 100.64.x.x-tik 100.127.x.x-ra, RFC 6598ko helbide partekatuen barrutia da eta ezin da internetetik iritsi. Ondorio berera iristen zara routerrak ohiko helbide pribatu bat duela dioenean eta bilaketa publiko batek zerikusirik ez duen zerbait itzultzen duenean. CGNAT lineak hurrengo lease-a arte baino irauten ez duen helbide publikoa ere izan dezake, beraz portu-birbidalketa batek ordubetez funtzionatzen duela ematen du eta gero isil-isilik hiltzen da.

Hornitzaile batzuek benetako helbide publikoa ematen dute, baina 80 eta 443 sarrera-portuak blokeatzen dituzte bizitegi-kontuetan. Zure zerbitzua web soila bada eta WAN helbidea benetan publikoa bada, galdetu laguntza-zerbitzuari errele bat eraiki aurretik. Hala ez bada, beheko diseinua portu guztiei berdin aplikatzen zaie, eta merezi du routerraren aldeko esperimentua gelditzea: hornitzailearen sareko itzultzaileak konexioa amaitzen du zure WAN interfazera iritsi aurretik.

Bideratu izena VPSren helbidera

DNSak ez du trafikoa birbidaltzen, beraz zerbitzuaren A erregistroak VPSren helbide publikoa eduki behar du. 192.168.1.20rako A erregistro bat modu erabilgarrian VPNaren barruan dauden bezeroentzat baino ez da ebazten; internetetik inork bideratu ezin duen helbide batera ebazten da. VPSren beraren administrazio-sarbiderako izen bereizi bat gordetzen dut, inoiz ez nahasteko erregistro bat zein ostalariri dagokion.

VPSak zein etxeko makinak HTTP zerbitzatzen badute, eman bakoitzari bere izena eta utzi VPSari erabakitzen nor erantzun. Biak izen bakarrean fusionatu eta proxyak backend zuzena aukeratuko duela espero izatea da ostalarri okerra arratsalde osoan arazten amaitzeko modua.

Portu bat DNAT bidez, utzi SSH 22n

Aukera zuzena VPSan helmugako NAT egitea da. Gaitu forwardinga exekutatzen ari den kernelarentzat eta mantendu etxeko zerbitzariaren tuneleko helbidea arauan, ez haren LAN helbidea:

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

Utzi VPSrako SSH 22n eta birbidali beste portu bat, adibidez 5022, etxeko makinara. Itzalita dagoen makina batera 22 birbidaltzen baduzu, konpon zezakeen bide bakarra galtzen duzu. Logika bera aplikatzen zaio proxyari: utzi VPSaren kudeaketa-portua errele arauetatik kanpo.

Egin arauak iraunkor funtzionatzen dutenean. Debian edo Ubuntun, apt install iptables-persistent eta gero netfilter-persistent save haiek /etc/iptables/rules.v4 fitxategian idazten dituzte. firewalld duen ostalari batean baliokidea zonan portu-birbidalketa iraunkorra da, eta firewall-cmd --reload behar du aplikatu aurretik. Memorian bakarrik bizi diren arauak hornitzailearen lehen mantentze-berrabiaraztean desagertzen dira, normalean ordu txar batean.

Konpondu itzulera-bidea, edo saihestu beharra

DNATek helmuga soilik berridazten du. Etxeko zerbitzariak jatorrizko bezeroaren helbidetik datorren konexioa ikusten du, eta haren bide lehenetsia etxeko routerrera badoa, erantzuna etxeko WANetik irteten da, eta han hornitzailearen itzultzaileak botatzen du. Asimetria hori izan zen topatu nuen bigarren hutsegitea, DNAT araua guztiz zuzena zirudien ondoren.

Konponketa bik funtzionatzen dute. Eman etxeko makinari politika-bide bat, tuneletik datorren trafikoa tuneletik itzul dadin:

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

Edo utzi VPSari iturria berridazten, erantzunak irits dezakeen helbide bat izan dezan, eta utzi conntracki irteeran alderantzikatzen:

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

SNAT bertsioak bezeroaren benetako helbidea ezkutatzen dio etxeko zerbitzariari, beraz aplikazioaren erregistroek 10.8.0.1 erakusten dute peer gisa. Pasa ezazu jatorrizko helbidea aplikazio-geruzan, edo onartu bezero bakoitzeko erregistroa galtzea, baina erabaki kontzienteki, intzidente batean aurkitu beharrean.

Egiaztatu bide osoa kanpotik

Egiaztatu VPSa ez den eta etxea ez den sare batetik: datu mugikorreko telefono bat, edo shell merke bat beste nonbait. nc -vz files.example.net 5022 konexio arrakastatsu bat jakinarazi beharko luke, eta openssl s_client -connect files.example.net:443 -servername files.example.net izen publikoaren ziurtagiria erakutsi beharko luke. Gero egiaztatu hornitzailearen security group edo hodeiko suebakia. Paketerik inoiz ikusten ez duen DNAT arau bat normalean ostalariaren gaineko geruza batean blokeatzen da.

Azkenik, erabaki zer gertatzen den tunela erortzen denean. DNAT arauak konexioak onartzen jarraitzen du eta isilik sartzen ditu tunel hil batean, eta horrek zerbitzu hondatua bezala dirudi. VPSan osasun-egiaztapen batek portua ukatzen badu peerra behera dagoen bitartean, lerro gutxi batzuk besterik ez ditu eta ordu bat asmatze aurreztuko du. Ondoren, utzi arauak editatzen eta begiratu egun batez fidatu aurretik.