Koduserveri avaldamine VPS-i kaudu, kui CGNAT blokeerib pordid

Alustasin väljastpoolt, nii nagu teeks kasutaja: sisestasin nime telefoni brauseris mobiilse andmesidega ja vaatasin, kuidas ühendus ripub, kuni aeg lõppes. Nimi lahenes, seega DNS oli korras. Ka koduruuteri portide suunamise leht oli ummiktee, sest selle WAN-aadress näitas 100.64.31.42, ja see ei ole aadress, kuhu teenusepakkuja mind internetist marsruudib. See number selgitab kogu riket: liin on carrier-grade NAT taga, seega avalik aadress minu pool tunnelit kuulub teenusepakkujale. Järgnev on tee, mille käisin sellest kinni jäänud vahelehest teenuseni, mis vastab.

Alusta kliendist ja liigu sissepoole

Enne kui muudad ükskõik millist reeglit, tõesta, kus kett katkeb. Sülearvutis käivitasin dig +short files.example.net ja sain VPS-i aadressi tagasi, mis välistas aegunud DNS-i minu masinas. Seejärel lõppes curl -v --connect-timeout 5 files.example.net:5022 aeg, selle asemel et seda keeldutaks. See erinevus on oluline: aja lõppemine tähendab tavaliselt, et pakette visatakse teel ära, samas kui keeldumine tähendab, et miski vastas ja ütles ei.

Järgmine samm sissepoole oli VPS ise. ss -ltnp ei näidanud midagi, mis kuulaks 5022, mida oligi oodata enne DNAT-reegli olemasolu. Samas masinas kinnitas wg show (või ip -br a show tun0 OpenVPN-i jaoks), et kodu-peer on üleval ja värske handshake-iga. Kui peer ei tööta, ei aita ükski NAT-reegel, ja roheline tuli koduruuteri VPN-lehel ei tähenda midagi.

Kinnita, et koduliin on tõesti CGNAT-i taga

Võrdle aadressi, mille ruuter oma WAN-liidesel teatab, sellega, mida näeb väline teenus. Kõik vahemikus 100.64.0.0/10, see tähendab 100.64.x.x kuni 100.127.x.x, on RFC 6598 jagatud aadresside vahemik ja seda ei saa internetist kätte. Samale järeldusele jõuad siis, kui ruuter väidab, et tal on tavaline privaatne aadress, ja avalik päring tagastab midagi seostamatut. CGNAT-liinil võib olla ka avalik aadress, mis kehtib ainult kuni järgmise lease-ni, nii et portide suunamine näib tund aega töötavat ja sureb siis vaikselt.

Mõned teenusepakkujad annavad tõesti tõelise avaliku aadressi, kuid blokeerivad kodutariifidel sissetulevad pordid 80 ja 443. Kui sinu teenus on ainult veeb ja WAN-aadress on tõeliselt avalik, küsi enne relay ehitamist tugiteenusest. Kui see ei ole, kehtib allolev lahendus kõigi portide puhul võrdselt, ja tasub katkestada katse ruuteri poolel: teenusepakkuja võrgus olev tõlk lõpetab ühenduse enne, kui see sinu WAN-liideseni jõuab.

Suuna nimi VPS-i aadressile

DNS ei edasta liiklust, seega teenuse A-kirje peab sisaldama VPS-i avalikku aadressi. A-kirje 192.168.1.20-le laheneb kasulikult ainult klientidele, kes on juba VPN-is; internetist laheneb see aadressile, mida keegi marsruudida ei saa. VPS-i enda haldusjuurdepääsu jaoks hoian eraldi nime, et ma ei ajaks kunagi segamini, millisele hostile kirje osutab.

Kui nii VPS kui ka kodumasin teenindavad HTTP-d, anna kummaleign omal nimi ja lase VPS-il otsustada, kes vastab. Nende kokkusulatamine üheks nimeks ja lootmine, et puhverserver valib õige backend-i, on täpselt see, kuidas veedad terve pärastlõuna vale hosti siludes.

Üks port DNAT-iga, SSH jääb 22 peale

Otsene võimalus on sihtkoha NAT VPS-il. Lülita sisse forwarding töötavale kernelile ja hoia reeglis koduserveri tunneli aadressi, mitte selle LAN-aadressi:

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

Jäta SSH VPS-i enda juurde 22 peale ja suuna teine port, näiteks 5022, kodumasinasse. Kui suunad 22 väljalülitatud masinasse, kaotad ainsa tee, mis oleks võinud selle korda teha. Sama loogika kehtib puhverserveri kohta: hoia VPS-i haldusport relay-reeglitest väljas.

Tee reeglid püsivaks, kui need töötavad. Debianis või Ubuntus kirjutavad apt install iptables-persistent ja seejärel netfilter-persistent save need faili /etc/iptables/rules.v4. Firewalld-hostis on ekvivalent tsoonis püsiv portide suunamine, mis vajab enne kehtimist firewall-cmd --reload. Reeglid, mis elavad ainult mälus, kaovad teenusepakkuja esimesel hooldusrestardil, tavaliselt halval tunnil.

Paranda tagasitee või väldi selle vajadust

DNAT kirjutab ümber ainult sihtkoha. Koduserver näeb ühendust kliendi algse aadressi pealt, ja kui selle vaike-marsruut osutab kodu-ruuterile, väljub vastus kodu WAN-i kaudu, kus teenusepakkuja tõlk selle maha viskab. See asümmeetria oli teine rike, millega kokku puutusin, pärast seda kui DNAT-reegel näis täiesti korrektne.

Kaks parandust töötavad. Anna kodumasinale poliitikamarsruut, et tunnelist tulev liiklus läheks tagasi tunnelisse:

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

Või lase VPS-il allikas ümber kirjutada, et vastusel oleks aadress, millele see ulatub, ja lase conntrack-il väljumisel see ümber pöörata:

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

SNAT-i versioon peidab koduserveri eest tõelise kliendi aadressi, seega rakenduse logides on peer-ina näha 10.8.0.1. Edasta algne aadress rakenduse kihis või lepi kokku kliendipõhise logimise kaoga, kuid otsusta seda teadlikult, selle asemel et see intsidendi ajal avastada.

Kontrolli kogu teed väljastpoolt

Kontrolli võrgust, mis ei ole ei VPS ega kodu: telefon mobiilse andmesidega või odav shell mujal. nc -vz files.example.net 5022 peaks teatama õnnestunud ühendusest ja openssl s_client -connect files.example.net:443 -servername files.example.net peaks näitama avaliku nime sertifikaati. Seejärel kontrolli teenusepakkuja security group-i või pilve tulemüüri. DNAT-reegel, mis ei näe kunagi paketti, blokeeritakse tavaliselt üks kiht hostist kõrgemal.

Lõpuks otsusta, mis juhtub, kui tunnel maha kukub. DNAT-reegel jätkab ühenduste vastuvõtmist ja suunab need vaikselt surnud tunnelisse, mis näeb täpselt välja nagu katkine teenus. Tervisekontroll VPS-il, mis keeldub porti, kuni peer ei tööta, maksab paar rida ja säästab tunni oletusi. Pärast seda lõpeta reeglite muutmine ja jälgi seda päev enne, kui seda usaldad.