Publiser en VPN-klientport bak CGNAT: sjekkliste

Sett en tjeneste på en bærbar datamaskin bak carrier-grade NAT, pek den bærbare mot en VPS over en VPN, og ingen utenfor kan nå den. Du legger til en regel for destinasjons-NAT på VPS-en og får noe verre enn stillhet: tilkoblinger åpnes, og så stopper de. Svaret mangler ikke, det forlater via klientens egen standardrute, noe som betyr at serveren aldri ser det. Gå gjennom disse fem kontrollene i rekkefølge og stopp ved den første som ikke holder.

Bekreft at serveren i det hele tatt vil videresende

Kryss av denne boksen før du skriver en eneste oversettelse. En DNAT-regel for en pakke som kjernen nekter å videresende, godtas av regelparseren og forkastes deretter av videresendingsveien, noe som gir en tidsavbrudd som ser ut som et brannmurproblem.

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

Å sette det i en kjørende kjerne er ikke det samme som å sette det over en omstart. Skriv net.ipv4.ip_forward=1 i en fil under /etc/sysctl.d/, kjør sysctl --system, og les deretter verdien tilbake i stedet for å stole på at filen ble plukket opp. En container som administrerer sitt eget nettverksnavnerom trenger samme verdi inne i det navnerommet, ikke bare på verten.

Hvis tilbakelesingen fortsatt er null, stopp her. Ingenting nedenfor vil fungere.

Fest tunneladressen før noen regel refererer til den

Bassenget deler ut adresser i tilkoblingsrekkefølge, så en regel skrevet for dagens leie kan stille peke på en annen klient neste uke. Bind adressen til sertifikatets identitet i stedet for til rekkefølgen ved ankomst.

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

Det paret er klientenden og peer-enden av en punkt-til-punkt-tunnel, med serveren nøklet til sertifikatets common name. Under en subnett-topologi leses den andre verdien i stedet som en nettmaske, så skriv formen som passer til topologien som brukes. Koble deretter klienten til igjen og les adressen på klienten selv, fordi serverens syn på bassenget ikke er bevis for hva klienten konfigurerte.

Hvis adressen endres etter en gjentilkobling, stopp. En NAT-regel som følger et flyttende mål vil feile periodevis og lære deg ingenting.

Oversett begge veier

Destinasjonsoversettelse sender den innkommende pakken til klienten. Kildeoversettelse er det som får klienten til å svare serveren i stedet for den opprinnelige avsenderen, og det er regelen folk utelater.

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

Uten den andre regelen svarer klienten gjennom sin ISP-opplastingslenke, så den eksterne peeren ser en kildeadresse den aldri har snakket med, mens serveren ikke har noen sporingspost for svaret. Den utenforstående ser en håndtrykk som fullføres halvveis, og det er nettopp symptomet som sender folk på jakt etter en brannmurfeil som ikke finnes.

Les begge reglene tilbake med iptables -t nat -S og bekreft at grensesnittnavnet er det som bærer den offentlige adressen. På en vert som allerede filtrerer med nftables, skriv oversettelsen i en nftables-NAT-kjede av den matchende adressefamilien i stedet for å blande verktøy.

Slipp filtertabellen gjennom

NAT-tabellene skriver om headere; de gir ikke tillatelse. Med en standard DROP-policy trenger den videresendte strømmen sin egen godkjenning, pluss retningsretningen som de fleste policyer allerede dekker 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

Sjekk policyen for FORWARD-kjeden før du legger til noe, fordi rekkefølgen til en tidlig DROP avgjør om regelen din i det hele tatt blir konsultert. På en vert der filtreringen bor i nftables, legg den tilsvarende regelen til forward-kroken i inet-tabellen og bekreft at basiskjeden faktisk ser videresendt trafikk og ikke bare lokal inngang. Hvis en pakketeller på den nye regelen blir stående på null mens NAT-tellerne stiger, blir pakken forkastet før regelen din. Det er signalet om å lese kjederekkefølgen, ikke om å legge til en andre kopi av samme regel.

Bevis det fra et eksternt nettverk

Test fra et ikke-tilknyttet nettverk. En sondering fra en annen maskin på samme LAN kan passere gjennom hairpin-NAT-støtte og utøver aldri veien en ekstern klient bruker, så et grønt resultat der beviser det feil.

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

Kjør opptaket på serveren og på klienten samtidig. Serveropptaket viser om den oversatte pakken forlater mot tunnelen; klientopptaket viser om forespørselen kommer og hvor svaret er adressert. En oversettelsesoppføring i conntrack -L beviser at regelen samsvarte, og fraværet beviser at pakken aldri nådde NAT-kjeden.

Portskannere er svak dokumentasjon. De rapporterer porten som lukket til applikasjonen er bundet og lytter, så bruk en ekte tilkobling til den ekte tjenesten. Når det endelig virker, hold eksponeringen til den ene porten: å videresende SSH eller et administrasjonspanel fordi den første regelen føltes keitete er en mye større beslutning enn å publisere en tjeneste.