Publicera en VPN-klientport bakom CGNAT: checklista

Sätt en tjänst på en bärbar dator bakom carrier-grade NAT, rikta den bärbara datorn mot en VPS över en VPN, och ingen utanför kan nå den. Du lägger till en regel för destinations-NAT på VPS:en och får något värre än tystnad: anslutningarna öppnas och stannar sedan. Svaret saknas inte, det lämnar via klientens egen standardrutt, vilket betyder att servern aldrig ser det. Gå igenom de här fem kontrollerna i ordning och stanna vid den första som inte håller.

Bekräfta att servern överhuvudtaget kommer att vidarebefordra

Kryssa i den här rutan innan du skriver en enda översättning. En DNAT-regel för ett paket som kärnan vägrar vidarebefordra accepteras av regelparsern och kastas sedan av vidarebefordringsvägen, vilket ger en timeout som ser ut som ett brandväggsproblem.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1

Att sätta det i en körande kärna är inte samma sak som att sätta det över en omstart. Skriv net.ipv4.ip_forward=1 i en fil under /etc/sysctl.d/, kör sysctl --system och läs sedan tillbaka värdet i stället för att lita på att filen fångades upp. En container som hanterar sitt eget nätverksnamnrymd behöver samma värde inne i den namnrymden, inte bara på värden.

Om tillbakaläsningen fortfarande är noll, stanna här. Ingenting nedanför kommer att fungera.

Lås tunneladressen innan någon regel hänvisar till den

Poolen delar ut adresser i anslutningsordning, så en regel skriven för dagens leasing kan tyst peka på en annan klient nästa vecka. Bind adressen till certifikatets identitet i stället för till ankomstordningen.

client-config-dir /etc/openvpn/ccd
ifconfig-push 10.77.0.14 10.77.0.13

Det paret är klientänden och peer-änden av en punkt-till-punkt-tunnel, med servern knuten till certifikatets common name. Under en subnätstopologi läses det andra värdet i stället som en nätmask, så skriv den form som matchar topologin som används. Anslut sedan klienten igen och läs adressen på klienten själv, eftersom serverns syn på poolen inte är bevis för vad klienten konfigurerade.

Om adressen ändras efter en återanslutning, stanna. En NAT-regel som följer ett rörligt mål kommer att misslyckas periodvis och lära dig ingenting.

Översätt åt båda hållen

Destinationsöversättning skickar det inkommande paketet till klienten. Källöversättning är det som får klienten att svara servern i stället för den ursprungliga avsändaren, och det är regeln folk utelämnar.

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 29443 -j DNAT --to-destination 10.77.0.14:29443
iptables -t nat -A POSTROUTING -d 10.77.0.14 -p tcp --dport 29443 -j SNAT --to-source 10.77.0.13

Utan den andra regeln svarar klienten via sin ISP-upplänk, så den fjärran peeren ser en källadress som den aldrig har talat med, medan servern inte har någon spårningspost för svaret. Den utomstående ser en handskakning som fullbordas halvvägs, och det är precis det symptom som skickar folk att leta efter ett brandväggsfel som inte finns.

Läs tillbaka båda reglerna med iptables -t nat -S och bekräfta att gränssnittsnamnet är det som bär den publika adressen. På en värd som redan filtrerar med nftables skriver du översättningen i en nftables-NAT-kedja av den matchande adressfamiljen i stället för att blanda verktyg.

Släpp igenom filtertabellen

NAT-tabellerna skriver om huvuden; de ger inte tillstånd. Med en standard-DROP-policy behöver det vidarebefordrade flödet sitt eget tillstånd, plus returriktningen som de flesta policyer redan täcker med en established,related-regel.

iptables -A FORWARD -i eth0 -o tun0 -p tcp --dport 29443 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Kontrollera policyn för FORWARD-kedjan innan du lägger till något, eftersom ordningen för en tidig DROP avgör om din regel alls blir tillfrågad. På en värd vars filtrering lever i nftables lägger du till motsvarande regel på forward-kroken i inet-tabellen och bekräftar att baskedjan verkligen ser vidarebefordrad trafik och inte bara lokal inmatning. Om en paketräknare på den nya regeln stannar på noll medan NAT-räknarna stiger, kastas paketet före din regel. Det är signalen att läsa kedjeordningen, inte att lägga till en andra kopia av samma regel.

Bevisa det från ett externt nätverk

Testa från ett orelaterat nätverk. En sond från en annan maskin i samma LAN kan passera genom hairpin-NAT-stöd och utövar aldrig den väg en fjärrklient använder, så ett grönt resultat där bevisar fel sak.

tcpdump -ni any port 29443
conntrack -L | grep 29443

Kör fångsten på servern och på klienten samtidigt. Fångsten på servern visar om det översatta paketet lämnar mot tunneln; fångsten på klienten visar om begäran anländer och vart svaret är adresserat. En översättningspost i conntrack -L bevisar att regeln matchade, och dess frånvaro bevisar att paketet aldrig nådde NAT-kedjan.

Portskannrar är svaga bevis. De rapporterar porten som stängd tills applikationen är bunden och lyssnar, så använd en riktig anslutning till den riktiga tjänsten. När det till slut fungerar håller du exponeringen till den enda porten: att vidarebefordra SSH eller en adminpanel för att den första regeln kändes besvärlig är ett mycket större beslut än att publicera en tjänst.