Mājas servera publicēšana caur VPS, kad CGNAT bloķē portus

Sāku no ārpuses, kā to darītu lietotājs: ievadīju vārdu tālruņa pārlūkā mobilajos datos un skatījos, kā savienojums karājas, līdz beidzās laiks. Vārds atrisinājās, tātad DNS bija kārtībā. Arī mājas maršrutētāja portu pāradresācijas lapa bija strupceļš, jo tās WAN adrese rādīja 100.64.31.42, un tā nav adrese, uz kuru pakalpojumu sniedzējs mani maršrutē no interneta. Šis skaitlis izskaidro visu kļūmi: līnija atrodas aiz carrier-grade NAT, tāpēc publiskā adrese manā tunelī pusē pieder pakalpojumu sniedzējam. Tālāk aprakstīts ceļš, ko nogāju no tās iekārtās cilnes līdz pakalpojumam, kas atbild.

Sāc pie klienta un ej uz iekšu

Pirms mainīt jebkuru noteikumu, pierādi, kur ķēde apstājas. Portatīvajā datorā palaidu dig +short files.example.net un saņēmu VPS adresi atpakaļ, kas izslēdza novecojušu DNS manā mašīnā. Pēc tam curl -v --connect-timeout 5 files.example.net:5022 beidzās laiks, nevis tika atteikts. Šī atšķirība ir svarīga: laika izbeigšanās parasti nozīmē, ka paketes tiek izmestas ceļā, bet atteikums nozīmē, ka kaut kas atbildēja un pateica nē.

Nākamais solis uz iekšu bija pats VPS. ss -ltnp neparādīja neko, kas klausītos uz 5022, kā arī bija gaidāms pirms DNAT noteikuma pastāvēšanas. Tajā pašā mašīnā wg show (vai ip -br a show tun0 OpenVPN gadījumā) apstiprināja, ka mājas peer darbojas un tam ir svaigs handshake. Ja peer nestrādā, neviens NAT noteikums nepalīdzēs, un zaļā gaisma mājas maršrutētāja VPN lapā neko nenozīmē.

Apstiprini, ka mājas līnija tiešām ir aiz CGNAT

Salīdzini adresi, ko maršrutētājs ziņo savā WAN saskarnē, ar to, ko redz ārējs pakalpojums. Viss 100.64.0.0/10, tas ir no 100.64.x.x līdz 100.127.x.x, ir koplietoto adrešu diapazons no RFC 6598 un no interneta nav sasniedzams. Pie tā paša secinājuma nonāksi, kad maršrutētājs apgalvo, ka tam ir parasta privātā adrese, bet publiska pārbaude atgriež kaut ko nesaistītu. CGNAT līnijai var būt arī publiskā adrese, kas derīga tikai līdz nākamajai lease, tāpēc portu pāradresācija šķietami strādā stundu un pēc tam klusi nomirst.

Daži pakalpojumu sniedzēji tiešām izsniedz īstu publisko adresi, bet bloķē ienākošos 80 un 443 portus mājsaimniecības kontos. Ja tavs pakalpojums ir tikai tīmekļa un WAN adrese patiešām ir publiska, pajautā atbalstam, pirms būvē relay. Ja nav, zemāk esošais dizains attiecas vienādi uz katru portu, un ir vērts pārtraukt eksperimentu maršrutētāja pusē: tulkotājs pakalpojumu sniedzēja tīklā pārtrauc savienojumu, pirms tas vispār sasniedz tavu WAN saskarni.

Novirzi vārdu uz VPS adresi

DNS nepārsūta trafiku, tāpēc pakalpojuma A ierakstā jābūt VPS publiskajai adresei. A ieraksts uz 192.168.1.20 lietderīgi atrisinās tikai klientiem, kuri jau ir VPN; no interneta tas atrisinās adresē, kuru neviens nevar maršrutēt. Administrācijas piekļuvei pašam VPS es turu atsevišķu vārdu, lai nekad nesajauktu, uz kuru resursdatoru attiecas ieraksts.

Ja HTTP apkalpo gan VPS, gan mājas mašīna, dod katram savu vārdu un ļauj VPS izlemt, kas atbild. Salipt tos vienā vārdā un cerēt, ka starpniekservers izvēlēsies pareizo backend, ir tieši tas, kā pavadi visu pēcpusdienu atkļūdojot nepareizo resursdatoru.

Viens ports caur DNAT, SSH paliek uz 22

Tiešā iespēja ir galamērķa NAT uz VPS. Ieslēdz forwarding darbojošajai kodolam un turi noteikumā mājas servera tuneļa adresi, nevis tā LAN adresi:

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

Atstāj SSH uz pašu VPS uz 22 un pāradresē citu portu, piemēram, 5022, uz mājas mašīnu. Ja pāradresēsi 22 uz izslēgtu mašīnu, zaudēsi vienīgo ceļu, kas to varēja salabot. Tā pati loģika attiecas uz starpniekserveri: turi VPS pārvaldības portu ārpus relay noteikumiem.

Padari noteikumus pastāvīgus, kad tie sāk strādāt. Debian vai Ubuntu apt install iptables-persistent un pēc tam netfilter-persistent save ieraksta tos /etc/iptables/rules.v4. Resursdatorā ar firewalld ekvivalents ir pastāvīga portu pāradresācija zonā, kam pirms piemērošanas vajadzīgs firewall-cmd --reload. Noteikumi, kas dzīvo tikai atmiņā, pazūd pirmajā pakalpojumu sniedzēja apkopes pārstartēšanā, parasti neveiksmīgā stundā.

Salabo atgriešanās ceļu vai izvairies no tā nepieciešamības

DNAT pārraksta tikai galamērķi. Mājas serveris redz savienojumu no sākotnējās klienta adreses, un, ja tā noklusējuma maršruts ved uz mājas maršrutētāju, atbilde iziet caur mājas WAN, kur pakalpojumu sniedzēja tulkotājs to nomet. Šī asimetrija bija otrā kļūme, ar ko saskāros, pēc tam kad DNAT noteikums izskatījās pilnīgi pareizs.

Divas labojumi strādā. Dod mājas mašīnai politikas maršrutu, lai trafiks no tuneļa ietu atpakaļ caur tuneli:

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

Vai ļauj VPS pārrakstīt avotu, lai atbildei būtu adrese, ko tas var sasniegt, un ļauj conntrack to apgriezt izejā:

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

SNAT versija slēpj īsto klienta adresi no mājas servera, tāpēc lietojumprogrammas žurnālos kā peer redzams 10.8.0.1. Nodod sākotnējo adresi lietojumprogrammas līmenī vai pieņem žurnālu zudumu pa klientiem, bet izlem to apzināti, nevis atklāj incidenta laikā.

Pārbaudi visu ceļu no ārpuses

Pārbaudi no tīkla, kas nav ne VPS, ne mājas: tālrunis mobilajos datos vai lēts shell citur. nc -vz files.example.net 5022 vajadzētu ziņot par veiksmīgu savienojumu, un openssl s_client -connect files.example.net:443 -servername files.example.net vajadzētu parādīt publiskā vārda sertifikātu. Pēc tam pārbaudi pakalpojumu sniedzēja security group vai mākoņa ugunsmūri. DNAT noteikums, kas nekad neredz paketi, parasti tiek bloķēts vienu slāni virs resursdatora.

Visbeidzot izlem, kas notiek, kad tunelis nokrīt. DNAT noteikums turpina pieņemt savienojumus un klusi ievada tos mirušā tunelī, kas izskatās tieši kā salauzts pakalpojums. Veselības pārbaude uz VPS, kas noraida portu, kamēr peer nestrādā, izmaksā dažas rindas un ietaupa stundu minējumu. Pēc tam pārtrauc rediģēt noteikumus un vēro to dienu, pirms uzticēties.