In thússerver publisearje fia in VPS as CGNAT poarten blokket

Ik begon fan bûten ôf, sa't in brûker it dwaan soe: de namme yn 'e browser fan in telefoan op mobyl data typt en sjoen hoe't de ferbining hinge oant er yn in time-out rûn. De namme waard oplost, dus DNS wie yn oarder. Ek de port-forward-side fan 'e thúsrouter wie in dea ein, want it WAN-adres wie 100.64.31.42, en dat is gjin adres dêr't in provider my fan it ynternet nei ta roetet. Dat nûmer ferklearret de hiele flater: de line sit efter carrier-grade NAT, dus it iepenbiere adres oan myn kant fan 'e tunnel is fan 'e provider. Wat folget is de wei dy't ik rûn fan dat hingjende ljepblêd nei in tsjinst dy't antwurdet.

Begjin by de klient en wurk nei binnen

Bewiis earst wêr't de keatling stjoppt, foardatst in regel feroarest. Op 'e laptop rûn ik dig +short files.example.net en krige it adres fan 'e VPS werom, wat ferâldere DNS op myn masine útslute. Dêrnei rûn curl -v --connect-timeout 5 files.example.net:5022 yn in time-out ynstee fan wegere te wurden. Dat ferskil is wichtich: in time-out betsjut meast dat pakketten ûnderweis weilitten wurde, wylst in wegering betsjut dat der wat antwurde en nee sei.

De folgjende hop nei binnen wie de VPS sels. ss -ltnp liet neat sjen dat op 5022 harke, wat te ferwachtsjen wie foardat de DNAT-regel bestie. Op itselde masine befêstige wg show (of ip -br a show tun0 by OpenVPN) dat de thúspeer online wie mei in resinte handshake. Stiet de peer út, dan helpt gjin inkele NAT-regel, en it griene lampke op 'e VPN-side fan 'e thúsrouter betsjut neat.

Befêstigje dat de thúsline echt efter CGNAT sit

Fergelykje it adres dat de router op syn WAN-interface meldt mei wat in eksterne tsjinst sjocht. Alles yn 100.64.0.0/10, dus 100.64.x.x oant en mei 100.127.x.x, is it shared-address-berik út RFC 6598 en is net fan it ynternet ôf berikber. Do komst ta deselde konklúzje as de router in gewoan privee-adres beweart en in iepenbiere lookup wat ûnferbâns weromjout. In CGNAT-line kin ek in iepenbier adres krije dat allinnich oant de folgjende lease jildt, sadat in port-forward in oere liket te wurkjen en dêrnei stil stjert.

Guon providers jouwe wol in echt iepenbier adres út, mar blokkearje ynkommende 80 en 443 op konsuminteabonnementen. Is dyn tsjinst allinnich web en is it WAN-adres echt iepenbier, freegje it dan oan 'e support foardatst in relay boust. Is dat net sa, dan jildt it ûntwerp hjirûnder foar elke poarte likefolle, en it leanet om it eksperimint oan 'e routerkant te stopjen: de translator yn it netwurk fan 'e provider beëiniget de ferbining foardat se ea dyn WAN-interface berikt.

Wize de namme nei it adres fan 'e VPS

DNS stjoert gjin ferkear troch, dus it A-record fan 'e tsjinst moat it iepenbiere adres fan 'e VPS befetsje. In A-record nei 192.168.1.20 lost allinnich nuttich op foar klanten dy't al yn 'e VPN sitte; fan it ynternet ôf lost it op nei in adres dat nimmen roetearje kin. Foar de behearderstagong fan 'e VPS sels hâld ik in aparte namme oan, sadat ik nea ferwarje op hokker host in record wiist.

As sawol de VPS as de thúsbak HTTP tsjinnet, jou dan elkenien syn eigen namme en lit de VPS beslisse wa't antwurdet. Se yn ien namme proppe en hoopje dat de proxy de juste backend kiest, is krekt hoe'tst in middei de ferkearde host debugst.

DNAT ien poarte, lit SSH op 22

De direkte opsje is destination NAT op 'e VPS. Sette forwarding oan foar de draaiende kernel en hâld it tunneladres fan 'e thússerver yn 'e regel, net syn LAN-adres:

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

Lit SSH nei de VPS sels op 22 en forward in oare poarte, bygelyks 5022, nei de thúsmachine. Forwardst 22 nei in bak dy't út stiet, dan ferliest it ienige paad dat it reparearje kinnen hie. Deselde logika jildt foar de proxy: hâld de behearpoarte fan 'e VPS bûten de relay-regels.

Meitsje de regels permanint sadree't se wurkje. Op Debian of Ubuntu skriuwt apt install iptables-persistent en dêrnei netfilter-persistent save se nei /etc/iptables/rules.v4. Op in firewalld-host is it ekwivalint in permaninte forward-port op 'e sône, dy't firewall-cmd --reload nedich hat foardat er jildt. Regels dy't allinnich yn it ûnthâld libje, ferdwine by de earste ûnderhâldsherstart fan 'e provider, meast op in min oere.

Reparearje de weromwei, of meitsje him oerstallich

DNAT skriuwt allinnich de bestimming oer. De thússerver sjocht in ferbining fan it oarspronklike klientadres, en as syn default route nei de thúsrouter wiist, ferlit it antwurd it hûs fia de WAN, dêr't de translator fan 'e provider it falle lit. Dy asymmetrie wie de twadde flater dy't ik trof, nei't de DNAT-regel der folslein korrekt útseach.

Twa oplossingen wurkje. Jou de thúsbak in beliedsroute sadat ferkear út 'e tunnel wer troch de tunnel weromgiet:

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

Of lit de VPS de boarne oerskriuwe sadat it antwurd in adres hat dat er berikke kin, en lit conntrack it op 'e wei nei bûten weromdraaie:

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

De SNAT-fariant ferberget it echte klientadres foar de thússerver, dus yn 'e applikaasjelogs stiet 10.8.0.1 as peer. Jou it orizjinele adres troch op 'e applikaasjelaach, of akseptearje dat logging per klient ferlern giet, mar beslút it bewust ynstee fan it by in ynsidint te ûntdekken.

Kontrolearje it hiele paad fan bûten ôf

Kontrolearje fan in netwurk dat net de VPS en net it hûs is: in telefoan op mobyl data, of in goedkeape shell earne oars. nc -vz files.example.net 5022 soe in slagge ferbining melde moatte, en openssl s_client -connect files.example.net:443 -servername files.example.net soe it sertifikaat foar de iepenbiere namme sjen litte moatte. Kontrolearje dêrnei de security group of cloudfirewall fan 'e provider. In DNAT-regel dy't nea in pakket sjocht, wurdt meast ien laach boppe de host blokkearre.

Ta slot: beslút wat der bart as de tunnel fuortfalt. In DNAT-regel bliuwt ferbiningen oannimme en fiert se stil in deade tunnel yn, wat der krekt útsjocht as in stikken tsjinst. In health check op 'e VPS dy't de poarte wegert salang't de peer út stiet, kostet in pear regels en sparret in oere gokken. Stop dêrnei mei regels bewurkje en sjoch der in dei nei foardatst it fertroust.