Udgiv en VPN-klientport bag CGNAT: tjekliste

Sæt en tjeneste på en bærbar computer bag carrier-grade NAT, peg den bærbare mod en VPS over en VPN, og ingen udenfor kan nå den. Du tilføjer en regel for destinations-NAT på VPS'en og får noget værre end tavshed: forbindelser åbner, og så går de i stå. Svaret mangler ikke, det forlader via klientens egen standardrute, hvilket betyder, at serveren aldrig ser det. Gå disse fem kontroller igennem i rækkefølge, og stop ved den første, der ikke holder.

Bekræft, at serveren overhovedet vil videresende

Sæt kryds i denne boks, før du skriver en enkelt oversættelse. En DNAT-regel for en pakke, som kernen nægter at videresende, accepteres af regelparseren og bortkastes derefter af videresendelsesvejen, hvilket giver en timeout, der ligner et firewallproblem.

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

At sætte det i en kørende kerne er ikke det samme som at sætte det hen over en genstart. Skriv net.ipv4.ip_forward=1 i en fil under /etc/sysctl.d/, kør sysctl --system, og læs derefter værdien tilbage i stedet for at stole på, at filen blev samlet op. En container, der styrer sit eget netværksnavnerum, har brug for den samme værdi inde i det navnerum, ikke kun på værten.

Hvis tilbagelæsningen stadig er nul, så stop her. Intet nedenfor vil virke.

Fastgør tunneladressen, før nogen regel henviser til den

Puljen uddeler adresser i forbindelsesrækkefølge, så en regel skrevet til dagens lease kan stille pege på en anden klient i næste uge. Bind adressen til certifikatets identitet i stedet for til ankomstsækkefølgen.

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

Det par er klientenden og peer-enden af en punkt-til-punkt-tunnel, med serveren bundet til certifikatets common name. Under en subnettopologi læses den anden værdi i stedet som en netmaske, så skriv den form, der passer til den anvendte topologi. Genopret derefter klienten, og læs adressen på klienten selv, fordi serverens syn på puljen ikke er bevis for, hvad klienten konfigurerede.

Hvis adressen ændrer sig efter en genoprettelse, så stop. En NAT-regel, der følger et flyttende mål, vil fejle periodisk og lære dig intet.

Oversæt i begge retninger

Destinationsoversættelse sender den indgående pakke til klienten. Kildeoversættelse er det, der får klienten til at svare serveren i stedet for den oprindelige afsender, og det er den regel, folk udelader.

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

Uden den anden regel svarer klienten gennem sin ISP-uplink, så den fjern peer ser en kildeaddresse, den aldrig har talt med, mens serveren ikke har nogen sporingspost for svaret. Den udefrakommende ser et håndtryk, der halvt fuldføres, og det er præcis det symptom, der sender folk på jagt efter en firewallfejl, som ikke findes.

Læs begge regler tilbage med iptables -t nat -S, og bekræft at grænsefladenavnet er det, der bærer den offentlige adresse. På en vært, der allerede filtrerer med nftables, skal du skrive oversættelsen i en nftables-NAT-kæde af den matchende adressefamilie i stedet for at blande værktøjer.

Lad filtertabellen komme igennem

NAT-tabellerne omskriver headere; de giver ikke tilladelse. Med en standard-DROP-politik har den videresendte strøm brug for sin egen accept plus returretningen, som de fleste politikker allerede dækker 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

Kontroller politikken for FORWARD-kæden, før du tilføjer noget, fordi rækkefølgen af en tidlig DROP afgør, om din regel overhovedet bliver konsulteret. På en vært, hvis filtrering lever i nftables, skal du tilføje den tilsvarende regel til forward-hooket i inet-tabellen og bekræfte, at basiskæden faktisk ser videresendt trafik og ikke kun lokal input. Hvis en pakketæller på den nye regel bliver på nul, mens NAT-tællerne stiger, bliver pakken kasseret før din regel. Det er signalet til at læse kæderækkefølgen, ikke til at tilføje en anden kopi af samme regel.

Bevis det fra et eksternt netværk

Test fra et ikke-relateret netværk. En sondering fra en anden maskine på samme LAN kan passere gennem hairpin-NAT-understøttelse og udøver aldrig den vej, en fjernklient bruger, så et grønt resultat der beviser det forkerte.

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

Kør optagelsen på serveren og på klienten samtidig. Serveroptagelsen viser, om den oversatte pakke forlader mod tunnelen; klientoptagelsen viser, om anmodningen ankommer, og hvor svaret er adresseret. En oversættelsespost i conntrack -L beviser, at reglen matchede, og dens fravær beviser, at pakken aldrig nåede NAT-kæden.

Portscannere er svag dokumentation. De rapporterer porten som lukket, indtil applikationen er bundet og lytter, så brug en rigtig forbindelse til den rigtige tjeneste. Når det endelig virker, så hold eksponeringen til den ene port: at videresende SSH eller et adminpanel, fordi den første regel føltes akavet, er en meget større beslutning end at udgive en tjeneste.