Ech hunn et vu baussen ugefaangen, sou wéi en Notzer et géif maachen: den Numm am Handy-Browser iwwer mobil Daten agetippt an nogekuckt, wéi d'Verbindung hänke bliwwen ass, bis se an en Timeout gelaf ass. Den Numm gouf opgeléist, DNS war also an der Rei. Och d'Port-Forward-Säit vum Heemrouter war eng Sakgaass, well hir WAN-Adress 100.64.31.42 war, an dat ass keng Adress, op déi en Ubider mir vum Internet aus ruteet. Dës Zuel erkläert de ganzen Feeler: d'Linn läit hannert carrier-grade NAT, also gehéiert déi öffentlech Adress op menger Säit vum Tunnel dem Ubider. Wat hei duerno kënnt, ass de Wee, deen ech vum hänkende Tab bis zu engem Service gaang sinn, dee äntwert.

Beim Client ufänken an no bannen schaffen

Bevir s du eng Regel änderes, beweise wou d'Kette ophält. Um Laptop hunn ech dig +short files.example.net lafe gelooss an d'VPS-Adress zréckkritt, wat veralteten DNS op menger Maschinn ausgeschloss huet. Duerno ass curl -v --connect-timeout 5 files.example.net:5022 an en Timeout gelaf, amplaz ofgeleent ze ginn. Dee Ënnerscheed ass wichteg: en Timeout heescht meeschtens, datt Pakete ënnerwee fale gelooss ginn, wärend eng Oflehnung heescht, datt eppes geäntwert an nee gesot huet.

Den nächsten Hop no bannen war d'VPS selwer. ss -ltnp huet näischt gewisen, wat op 5022 gelauschtert huet, wat erwaart war, éier d'DNAT-Regel existéiert huet. Op der selwechter Maschinn huet wg show (oder ip -br a show tun0 fir OpenVPN) bestätegt, datt de Heempeer uewen war mat engem frëschen Handshake. Wann de Peer ënnen ass, hëlleft keng NAT-Regel, an d'gréng Luucht op der VPN-Säit vum Heemrouter heescht näischt.

Bestätegen, datt d'Heemlinn wierklech hannert CGNAT läit

Vergläich d'Adress, déi de Router op sengem WAN-Interface mellt, mat deem, wat en externe Service gesäit. Alles an 100.64.0.0/10, also 100.64.x.x bis 100.127.x.x, ass de Shared-Address-Beräich aus RFC 6598 a kann net vum Internet aus erreecht ginn. Du kënns zum selwechten Ofschloss, wann de Router eng gewéinlech privat Adress behaapt an eng öffentlech Nofro eppes Onverbonnes zréckgëtt. Eng CGNAT-Linn kann och eng öffentlech Adress matbréngen, déi just bis zur nächster Lease hält, soudatt eng Portweiderleeung eng Stonn ze funktionéieren ausgesäit an duerno stille stierft.

E puer Ubider ginn tatsächlech eng richteg öffentlech Adress aus, blockéieren awer agoend 80 an 443 op Privatabonnementer. Wann däi Service nëmmen Web ass an d'WAN-Adress wierklech öffentlech ass, fro de Support, éier s du en Relay baust. Wann net, gëllt den Design hei drënner fir all Port gläichermoossen, an et lount sech, den Experiment op der Routersäit ofzeschléissen: den Translator am Ubider sengem Netz beendet d'Verbindung, éier se je däin WAN-Interface erreecht.

Den Numm op d'VPS-Adress weisen

DNS leeet keen Trafic weider, also muss den A-Record fir de Service déi öffentlech Adress vun der VPS enthalen. En A-Record op 192.168.1.20 léist nëmme nëtzlech op fir Clienten, déi schonn an der VPN sinn; vum Internet aus léist en op eng Adress op, déi keen route kann. Fir den Admin-Zougang vun der VPS selwer halen ech en eegenen Numm, soudatt ech ni verwiesselen, op wéi en Host e Record weist.

Wann souwuel d'VPS wéi och d'Heemkëscht HTTP zerwéieren, gëff jidderengem seng eege Numm a lass d'VPS entscheeden, wien äntwert. Se an engem Numm ze falen an ze hoffen, de Proxy wielt de richtegen Backend, ass genee wéi s du en Nomëtteg laang de falschen Host debuggs.

DNAT eng Port, lass SSH op 22

Déi direkt Optioun ass Destination-NAT op der VPS. Aktivéier Forwarding fir de lafende Kernel a behal d'Tunneladress vum Heemserver an der Regel, net seng LAN-Adress:

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

Lass SSH zu der VPS selwer op 22 an forward eng aner Port, zum Beispill 5022, op d'Heemmaschinn. Weiders du 22 op eng Këscht, déi ënnen ass, verléiers du deen eenzegen Wee, dee kéint et reparéiert hunn. Déi selwecht Logik gëllt fir de Proxy: hal d'Verwaltungsport vun der VPS ausserhalb vun de Relay-Regelen.

Maach d'Regelen dauerhaft, soubal se funktionéieren. Op Debian oder Ubuntu schreift apt install iptables-persistent an duerno netfilter-persistent save se op /etc/iptables/rules.v4. Op engem firewalld-Host ass d'Ekwivalent eng permanent Forward-Port op der Zon, déi firewall-cmd --reload brauch, éier se gëllt. Regelen, déi nëmmen am Späicher liewen, verschwannen beim éischte Wartungs-Reboot vum Ubider, meeschtens zu enger schlechter Stonn.

De Réckwee reparéieren, oder et vermeiden, en ze brauchen

DNAT schreift nëmmen d'Zil ëm. Den Heemserver gesäit eng Verbindung vun der ursprénglecher Client-Adress, a wann seng Default-Route op den Heemrouter weist, verléisst d'Äntwert d'Haus iwwer de WAN, wou den Translator vum Ubider se fale léisst. Déi Asymmetrie war den zweeten Feeler, op deen ech gestouss sinn, nodeems d'DNAT-Regel komplett korrekt ausgesinn huet.

Zwou Korrekture funktionéieren. Gëff der Heemkëscht eng Policy-Route, soudatt Trafic aus dem Tunnel erëm duerch den Tunnel geet:

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

Oder lass d'VPS d'Quell ëmschreiwen, soudatt d'Äntwert eng Adress huet, déi se erreeche kann, a lass conntrack se um Wee eraus zréckdréien:

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

D'SNAT-Versioun verstoppt déi richteg Client-Adress virum Heemserver, also weisen d'Applikatiounsloggen 10.8.0.1 als Peer. Gëff d'Originaladress op der Applikatiounsebene weider, oder akzeptéier, datt d'Logging pro Client verluer geet, awer entscheed et bewosst, amplaz et während engem Incident ze entdecken.

De ganze Wee vu baussen iwwerpréiwen

Iwwerpréif vun engem Netz, dat weder d'VPS nach d'Haus ass: en Handy iwwer mobil Daten oder eng bëlleg Shell soss anzwousch. nc -vz files.example.net 5022 sollt eng erfollegräich Verbindung mellen, an openssl s_client -connect files.example.net:443 -servername files.example.net sollt d'Zertifikat fir den öffentlechen Numm weisen. Préif duerno d'Security Group oder d'Cloudfirewall vum Ubider. Eng DNAT-Regel, déi ni e Pak gesäit, gëtt meeschtens eng Schicht iwwer dem Host blockéiert.

Zum Schluss: entscheed, wat geschitt, wann den Tunnel fält. Eng DNAT-Regel hält weider Verbindungen un a féiert se stille an en doudegen Tunnel, wat genee wéi e kaputte Service ausgesäit. En Health Check op der VPS, deen d'Port ofweist, während de Peer ënnen ass, kascht e puer Zeilen a spuert eng Stonn Raten. Halt duerno op, Regelen ze änneren, a kuck et en Dag laang un, éier s du et vertraust.

Ähnlech Artikelen