Kotipalvelimen julkaiseminen VPS:n kautta, kun CGNAT blokkaa portit

Aloitin ulkopuolelta, kuten käyttäjä tekisi: kirjoitin nimen puhelimen selaimeen mobiilidatalla ja katsoin, miten yhteys roikkui, kunnes aikakatkaisu tuli. Nimi ratkesi, joten DNS oli kunnossa. Myös kotireitittimen portinohjaussivu oli umpikuja, koska sen WAN-osoite näytti 100.64.31.42, eikä se ole osoite, johon operaattori minua internetistä reitittää. Tämä luku selittää koko vian: linja on carrier-grade NATin takana, joten julkinen osoite tunnelin minun puolellani kuuluu operaattorille. Seuraavassa on polku, jonka kuljin siitä jumittuneesta välilehdestä palveluun, joka vastaa.

Aloita asiakkaasta ja etene sisäänpäin

Ennen kuin muutat yhtäkään sääntöä, todista mihin ketju pysähtyy. Kannettavalla ajoin dig +short files.example.net ja sain VPS:n osoitteen takaisin, mikä sulki pois vanhentuneen DNS:n koneellani. Sitten curl -v --connect-timeout 5 files.example.net:5022 aikakatkaistiin sen sijaan, että se olisi hylätty. Tällä erolla on väliä: aikakatkaisu tarkoittaa yleensä, että paketteja pudotetaan matkalla, kun taas hylkäys tarkoittaa, että jokin vastasi ja sanoi ei.

Seuraava askel sisäänpäin oli itse VPS. ss -ltnp ei näyttänyt mitään, mikä kuuntelisi portissa 5022, kuten odotettua ennen DNAT-säännön olemassaoloa. Samassa koneessa wg show (tai ip -br a show tun0 OpenVPN:lle) vahvisti, että kodin peer on ylhäällä ja sillä on tuore handshake. Jos peer ei toimi, mikään NAT-sääntö ei auta, eikä kotireitittimen VPN-sivun vihreä valo tarkoita mitään.

Vahvista, että kotilinja on todella CGNAT:n takana

Vertaa osoitetta, jonka reititin ilmoittaa WAN-liitännässään, siihen, mitä ulkoinen palvelu näkee. Kaikki alueella 100.64.0.0/10 eli 100.64.x.x – 100.127.x.x on RFC 6598:n jaettu osoitealue, eikä siihen pääse internetistä. Samaan johtopäätökseen päädyt, kun reititin väittää, että sillä on tavallinen yksityinen osoite, ja julkinen haku palauttaa jotain asiaankuulumatonta. CGNAT-linjalla voi olla myös julkinen osoite, joka kestää vain seuraavaan leaseen, joten portinohjaus näyttää toimivan tunnin ja kuolee sitten hiljaa.

Jotkut operaattorit antavat todella aidon julkisen osoitteen mutta estävät saapuvat portit 80 ja 443 kotiliittymissä. Jos palvelusi on vain verkko ja WAN-osoite on aidosti julkinen, kysy tuelta ennen kuin rakennat relayn. Jos ei, alla oleva suunnittelu pätee samalla tavalla jokaiseen porttiin, ja kokeilu kannattaa lopettaa reitittimen puolella: operaattorin verkossa oleva kääntäjä päättää yhteyden ennen kuin se koskaan saavuttaa WAN-liitäntäsi.

Osoita nimi VPS:n osoitteeseen

DNS ei välitä liikennettä, joten palvelun A-tietueen on sisällettävä VPS:n julkinen osoite. A-tietue osoitteeseen 192.168.1.20 ratkeaa hyödyllisesti vain asiakkaille, jotka ovat jo VPN:ssä; internetistä se ratkeaa osoitteeseen, jota kukaan ei voi reitittää. VPS:n omaan hallintakäyttöön pidän erillistä nimeä, jotta en koskaan sekoita, mihin isäntään tietue viittaa.

Jos sekä VPS että kotikone tarjoavat HTTP:tä, anna kummallekin oma nimi ja anna VPS:n päättää, kuka vastaa. Niiden sulattaminen yhdeksi nimeksi ja toive, että välityspalvelin valitsee oikean backendin, on juuri se tapa, jolla vietät koko iltapäivän väärää isäntää debugaten.

Yksi portti DNAT:lla, SSH jää porttiin 22

Suora vaihtoehto on kohde-NAT VPS:llä. Kytke forwarding päälle käynnissä olevalle ytimelle ja pidä säännössä kotipalvelimen tunneliosoite, ei sen LAN-osoite:

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ätä SSH itse VPS:ään porttiin 22 ja välitä toinen portti, esimerkiksi 5022, kotikoneelle. Jos välität portin 22 sammutettuun koneeseen, menetät ainoan polun, joka olisi voinut korjata sen. Sama logiikka koskee välityspalvelinta: pidä VPS:n hallintaportti relay-sääntöjen ulkopuolella.

Tee säännöistä pysyviä, kun ne toimivat. Debianissa tai Ubuntussa apt install iptables-persistent ja sitten netfilter-persistent save kirjoittavat ne tiedostoon /etc/iptables/rules.v4. Firewalld-isännässä vastine on pysyvä portinsiirto vyöhykkeellä, joka tarvitsee ennen voimaantuloa firewall-cmd --reload. Säännöt, jotka elävät vain muistissa, katoavat operaattorin ensimmäisessä huoltokäynnistyksessä, yleensä huonoon aikaan.

Korjaa paluureitti tai vältä sen tarvetta

DNAT kirjoittaa uudelleen vain kohteen. Kotipalvelin näkee yhteyden alkuperäisen asiakkaan osoitteesta, ja jos sen oletusreitti osoittaa kotireitittimeen, vastaus lähtee kodin WAN:n kautta, jossa operaattorin kääntäjä pudottaa sen. Tämä epäsymmetria oli toinen vika, johon törmäsin, kun DNAT-sääntö näytti täysin oikealta.

Kaksi korjausta toimii. Anna kotikoneelle käytäntöreitti, jotta tunnelista tuleva liikenne palaa tunnelin kautta:

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

Tai anna VPS:n kirjoittaa lähde uudelleen, jotta vastauksella on osoite, jonka se tavoittaa, ja anna conntrackin kääntää se lähdössä:

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

SNAT-versio piilottaa todellisen asiakkaan osoitteen kotipalvelimelta, joten sovelluksen lokit näyttävät peerinä 10.8.0.1. Välitä alkuperäinen osoite sovelluskerroksessa tai hyväksy asiakaskohtaisen lokituksen menetys, mutta päätä se tietoisesti sen sijaan, että löytäisit sen kesken incidentin.

Tarkista koko polku ulkopuolelta

Tarkista verkosta, joka ei ole VPS eikä koti: puhelin mobiilidatalla tai halpa shell muualla. nc -vz files.example.net 5022:n pitäisi ilmoittaa onnistuneesta yhteydestä ja openssl s_client -connect files.example.net:443 -servername files.example.net:n näyttää julkisen nimen sertifikaatti. Tarkista sitten operaattorin security group tai pilvipalomuuri. DNAT-sääntö, joka ei koskaan näe pakettia, estetään yleensä yksi kerros isännän yläpuolella.

Lopuksi päätä, mitä tapahtuu, kun tunneli putoaa. DNAT-sääntö ottaa edelleen yhteyksiä vastaan ja syöttää ne hiljaa kuolleeseen tunneliin, mikä näyttää täsmälleen rikkinäiseltä palvelulta. VPS:n terveystarkistus, joka hylkää portin, kun peer ei toimi, maksaa muutaman rivin ja säästää tunnin arvailua. Sen jälkeen lopeta sääntöjen muokkaaminen ja seuraa sitä vuorokausi ennen kuin luotat siihen.