Publiseer 'n tuisbediener deur 'n VPS wanneer CGNAT poorte blokkeer

Ek het van buite begin, soos 'n gebruiker sou doen: die naam in 'n selfoonblaaier op mobiele data getik en gekyk hoe die verbinding hang tot dit 'n time-out kry. Die naam het opgelos, so DNS was reg. Die tuisroeteerder se port-forward-bladsy was ook 'n doodloopstraat, want sy WAN-adres was 100.64.31.42, en dit is nie 'n adres waarnatoe 'n verskaffer my van die internet af sou roeteer nie. Daardie nommer verduidelik die hele fout: die lyn sit agter carrier-grade NAT, so die openbare adres aan my kant van die tonnel behoort aan die verskaffer. Wat volg, is die pad wat ek gestap het van daardie hangende oortjie na 'n diens wat antwoord.

Begin by die kliënt en werk inwaarts

Bewys waar die ketting stop voordat jy enige reël verander. Op die skootrekenaar het ek dig +short files.example.net uitgevoer en die VPS-adres teruggekry, wat verouderde DNS op my masjien uitgesluit het. Daarna het curl -v --connect-timeout 5 files.example.net:5022 'n time-out gekry in plaas daarvan om geweier te word. Daardie verskil maak saak: 'n time-out beteken gewoonlik dat pakkette onderweg laat val word, terwyl 'n weiering beteken dat iets geantwoord en nee gesê het.

Die volgende hop inwaarts was die VPS self. ss -ltnp het niks gewys wat op 5022 luister nie, wat verwag is voordat die DNAT-reël bestaan het. Op dieselfde masjien het wg show (of ip -br a show tun0 vir OpenVPN) bevestig dat die tuispeer op was met 'n vars handdruk. As die peer af is, help geen NAT-reël nie, en die groen liggie op die tuisroeteerder se VPN-bladsy beteken niks.

Bevestig die tuislyn sit regtig agter CGNAT

Vergelyk die adres wat die roeteerder op sy WAN-koppelvlak rapporteer met wat 'n eksterne diens sien. Enigiets in 100.64.0.0/10, dit wil sê 100.64.x.x tot 100.127.x.x, is die gedeelde adresreeks uit RFC 6598 en kan nie van die internet af bereik word nie. Jy kom tot dieselfde gevolgtrekking wanneer die roeteerder 'n gewone private adres voorgee en 'n openbare opsoek iets onverwants teruggee. 'n CGNAT-lyn kan ook 'n openbare adres hê wat net tot die volgende lease hou, sodat 'n port forward 'n uur lank werk en dan stil sterf.

Sommige verskaffers gee wel 'n regte openbare adres uit, maar blokkeer inkomende 80 en 443 op residensiële rekeninge. As jou diens net web is en die WAN-adres werklik openbaar is, vra die ondersteuning voor jy 'n relay bou. Is dit nie, dan geld die ontwerp hieronder vir elke poort ewe veel, en dit is die moeite werd om die eksperiment aan die roeteerderkant te stop: die vertaler in die verskaffer se netwerk beëindig die verbinding voordat dit ooit jou WAN-koppelvlak bereik.

Wys die naam na die VPS se adres

DNS stuur nie verkeer deur nie, so die A-rekord vir die diens moet die VPS se openbare adres bevat. 'n A-rekord na 192.168.1.20 los net nuttig op vir kliënte wat al in die VPN is; van die internet af los dit op na 'n adres wat niemand kan roeteer nie. Vir die VPS se eie administrasietoegang hou ek 'n aparte naam, sodat ek nooit verwar op watter gasheer 'n rekord wys nie.

As beide die VPS en die tuisboks HTTP bedien, gee elkeen sy eie naam en laat die VPS besluit wie antwoord. Om hulle in een naam saam te vou en te hoop die volmag kies die regte agterkant, is presies hoe jy 'n middag lank die verkeerde gasheer ontfout.

DNAT een poort, laat SSH op 22

Die direkte opsie is destination NAT op die VPS. Aktiveer forwarding vir die lopende kern en hou die tuisbediener se tonneladres in die reël, nie sy LAN-adres nie:

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

Laat SSH na die VPS self op 22 en stuur 'n ander poort, soos 5022, aan na die tuismasjien. Stuur jy 22 na 'n boks wat af is, verloor jy die enigste pad wat dit kon herstel het. Dieselfde logika geld vir die volmag: hou die VPS se bestuurspoort buite die relay-reëls.

Maak die reëls permanent sodra hulle werk. Op Debian of Ubuntu skryf apt install iptables-persistent en daarna netfilter-persistent save hulle na /etc/iptables/rules.v4. Op 'n firewalld-gasheer is die ekwivalent 'n permanente forward-port op die sone, wat firewall-cmd --reload nodig het voordat dit geld. Reëls wat net in die geheue leef, verdwyn by die verskaffer se eerste instandhouding-herbooting, gewoonlik op 'n slegte uur.

Herstel die terugroete, of vermy die behoefte daaraan

DNAT herskryf net die bestemming. Die tuisbediener sien 'n verbinding van die oorspronklike kliëntadres, en as sy verstekroete na die tuisroeteerder wys, verlaat die antwoord die huis deur die WAN waar die verskaffer se vertaler dit laat val. Daardie asimmetrie was die tweede fout wat ek getref het, nadat die DNAT-reël heeltemal korrek gelyk het.

Twee regstellings werk. Gee die tuisboks 'n beleidsroete sodat verkeer uit die tonnel weer deur die tonnel teruggaan:

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

Of laat die VPS die bron herskryf sodat die antwoord 'n adres het wat hy kan bereik, en laat conntrack dit op pad uit omdraai:

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

Die SNAT-weergawe verberg die werklike kliëntadres vir die tuisbediener, so toepassinglogboeke wys 10.8.0.1 as die peer. Gee die oorspronklike adres deur op die toepassinglaag, of aanvaar dat logboekhouding per kliënt verlore gaan, maar besluit dit doelbewus eerder as om dit tydens 'n voorval te ontdek.

Kontroleer die hele pad van buite

Verifieer vanuit 'n netwerk wat nie die VPS en nie die huis is nie: 'n selfoon op mobiele data, of 'n goedkoop skulp elders. nc -vz files.example.net 5022 behoort 'n suksesvolle verbinding te rapporteer, en openssl s_client -connect files.example.net:443 -servername files.example.net behoort die sertifikaat vir die openbare naam te wys. Kontroleer dan die verskaffer se sekuriteitsgroep of wolkkewer. 'n DNAT-reël wat nooit 'n pakket sien nie, word gewoonlik een laag bo die gasheer geblokkeer.

Laastens: besluit wat gebeur wanneer die tonnel val. 'n DNAT-reël hou aan om verbindings te aanvaar en voer hulle stil in 'n dooie tonnel in, wat presies soos 'n stukkende diens lyk. 'n Gesondheidstoets op die VPS wat die poort weier terwyl die peer af is, kos 'n paar reëls en spaar 'n uur se raai. Stop daarna om reëls te wysig en kyk 'n dag daarna voordat jy dit vertrou.