Otthoni kiszolgáló közzététele VPS-en át, amikor a CGNAT blokkolja a portokat

Kívülről kezdtem, ahogy egy felhasználó tenné: beírtam a nevet egy telefon böngészőjébe mobil adaton, és néztem, ahogy a kapcsolat lóg, míg le nem járt az idő. A név feloldódott, tehát a DNS rendben volt. Az otthoni router porttovábbítás-oldala is zsákutca volt, mert a WAN-címe 100.64.31.42 volt, és ez nem olyan cím, amelyre egy szolgáltató az internetről felém irányítana. Ez a szám magyarázza az egész hibát: a vonal carrier-grade NAT mögött van, tehát a nyilvános cím a tunel én oldalamon a szolgáltatóé. Ami következik, az az út, amelyet abból a beragadt lapból egy válaszoló szolgáltatásig megtettem.

Kezdd az ügyfélnél, és haladj befelé

Mielőtt bármelyik szabályt megváltoztatnád, bizonyítsd, hol áll meg a lánc. A laptopon lefuttattam a dig +short files.example.net parancsot, és visszakaptam a VPS címét, ami kizárta az elavult DNS-t a gépemen. Ezután a curl -v --connect-timeout 5 files.example.net:5022 időtúllépésbe futott ahelyett, hogy elutasították volna. Ez a különbség számít: az időtúllépés általában azt jelenti, hogy a csomagokat útközben eldobják, míg az elutasítás azt, hogy valami válaszolt és nemet mondott.

A következő lépés befelé maga a VPS volt. A ss -ltnp semmit nem mutatott, ami az 5022-es porton figyelne, ami a DNAT-szabály előtt várható volt. Ugyanezen a gépen a wg show (vagy OpenVPN esetén a ip -br a show tun0) megerősítette, hogy az otthoni peer fut, és friss handshake-e van. Ha a peer nem működik, egyetlen NAT-szabály sem segít, és az otthoni router VPN-oldalán a zöld lámpa semmit nem jelent.

Erősítsd meg, hogy az otthoni vonal valóban CGNAT mögött van

Hasonlítsd össze a router által a WAN-interfészen jelentett címet azzal, amit egy külső szolgáltatás lát. Minden, ami a 100.64.0.0/10 tartományban van, azaz 100.64.x.x-től 100.127.x.x-ig, az RFC 6598 szerinti megosztott címtartomány, és az internetről nem érhető el. Ugyanerre a következtetésre jutsz, amikor a router azt állítja, hogy közönséges privát címe van, egy nyilvános lekérdezés pedig valami oda nem illőt ad vissza. A CGNAT-vonal járhat olyan nyilvános címmel is, amely csak a következő lease-ig érvényes, így a porttovábbítás egy órán át működni látszik, aztán csendben meghal.

Egyes szolgáltatók valóban valódi nyilvános címet adnak, de blokkolják a bejövő 80-as és 443-as portot a lakossági előfizetéseknél. Ha a szolgáltatásod csak webes, és a WAN-cím valóban nyilvános, kérdezd meg az ügyfélszolgálatot, mielőtt relay-t építesz. Ha nem az, az alábbi terv minden portra egyformán érvényes, és érdemes leállítani a kísérletet a router oldalán: a szolgáltató hálózatában lévő fordító bontja a kapcsolatot, mielőtt az valaha elérné a WAN-interfészedet.

Irányítsd a nevet a VPS címére

DNS nem továbbít forgalmat, ezért a szolgáltatás A-rekordjának a VPS nyilvános címét kell tartalmaznia. A 192.168.1.20-ra mutató A-rekord csak a VPN-en belüli ügyfeleknek oldódik fel hasznosan; az internetről olyan címre oldódik fel, amelyet senki nem tud irányítani. A VPS saját adminisztrációs hozzáféréséhez külön nevet tartok, hogy soha ne keverjem össze, melyik hoszthoz tartozik egy rekord.

Ha mind a VPS, mind az otthoni gép HTTP-t szolgál ki, adj mindegyiknek saját nevet, és hagyd a VPS-re, hogy eldöntse, melyik válaszol. Egyetlen névbe olvasztani őket, és reménykedni, hogy a proxy a megfelelő backendet választja, pontosan az, ahogy egy délutánt a rossz hoszt hibakeresésével töltesz.

Egy port DNAT-tal, az SSH marad a 22-n

A közvetlen lehetőség a cél-NAT a VPS-en. Kapcsold be a forwardingot a futó kernelhez, és tartsd a szabályban az otthoni kiszolgáló tunelcímét, nem a LAN-címét:

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

Hagyd az SSH-t magára a VPS-re a 22-es porton, és továbbíts egy másik portot, például az 5022-est az otthoni gépre. Ha a 22-est egy kikapcsolt gépre továbbítod, elveszíted az egyetlen utat, amely megjavíthatta volna. Ugyanez a logika vonatkozik a proxyra: tartsd a VPS kezelési portját a relay-szabályokon kívül.

Tedd állandóvá a szabályokat, amint működnek. Debianon vagy Ubuntun a apt install iptables-persistent és utána a netfilter-persistent save a /etc/iptables/rules.v4 fájlba írja őket. Firewalld-s hoszton az megfelelője egy állandó porttovábbítás a zónán, amelynek az érvényesülés előtt a firewall-cmd --reload kell. A csak memóriában élő szabályok eltűnnek a szolgáltató első karbantartási újraindításakor, általában rossz órában.

Javítsd a visszautat, vagy kerüld el, hogy szükség legyen rá

A DNAT csak a célt írja át. Az otthoni kiszolgáló az eredeti ügyfélcímről érkező kapcsolatot lát, és ha az alapértelmezett útvonala az otthoni routerre mutat, a válasz a ház WAN-ján keresztül távozik, ahol a szolgáltató fordítója eldobja. Ez az aszimmetria volt a második hiba, amellyel találkoztam, miután a DNAT-szabály teljesen helyesnek tűnt.

Két javítás működik. Adj az otthoni gépnek házirend-útvonalat, hogy a tunelből jövő forgalom a tunelen keresztül menjen vissza:

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

Vagy hagyd, hogy a VPS átírja a forrást, hogy a válasznak legyen egy elérhető címe, és hagyd, hogy a conntrack a kifelé vezető úton visszafordítsa:

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

Az SNAT-változat elrejti a valódi ügyfélcímet az otthoni kiszolgáló elől, ezért az alkalmazásnaplók peer-ként a 10.8.0.1-et mutatják. Add tovább az eredeti címet az alkalmazásrétegen, vagy fogadd el az ügyfelenkénti naplózás elvesztését, de döntsd el szándékosan, ahelyett hogy egy incidens közben fedeznéd fel.

Ellenőrizd a teljes utat kívülről

Ellenőrizd olyan hálózatból, amely nem a VPS és nem is az otthon: mobil adaton lévő telefonról vagy egy olcsó shellből máshol. A nc -vz files.example.net 5022 sikeres kapcsolatot jelez, a openssl s_client -connect files.example.net:443 -servername files.example.net pedig a nyilvános név tanúsítványát mutatja. Ezután ellenőrizd a szolgáltató security groupját vagy felhőtűzfalát. Az a DNAT-szabály, amely soha nem lát csomagot, általában egy réteggel a hoszt felett blokkolódik.

Végül döntsd el, mi történik, ha a tunel leesik. A DNAT-szabály továbbra is fogad kapcsolatokat, és csendben egy halott tunelbe vezeti őket, ami pontosan egy tönkrement szolgáltatásnak látszik. Egy állapotellenőrzés a VPS-en, amely elutasítja a portot, amíg a peer nem működik, néhány sorba kerül, és egy óra találgatást spórol meg. Utána hagyd abba a szabályok szerkesztését, és figyeld egy napig, mielőtt megbízol benne.