Publiser ein VPN-klientport bak CGNAT: sjekkliste

Set ein teneste på ein berbar datamaskin bak carrier-grade NAT, peik den berbare mot ein VPS over ein VPN, og ingen utanfor kan nå han. Du legg til ein regel for mål-NAT på VPS-en og får noko verre enn stillheit: tilkoplingar opnar, og så stoppar dei. Svaret manglar ikkje, det går ut via klienten si eiga standardrute, noko som betyr at tenaren aldri ser det. Gå gjennom desse fem kontrollane i rekkefølgje og stopp ved den første som ikkje held.

Stadfest at tenaren i det heile vil videresende

Kryss av denne boksen før du skriv ein einaste omsetjing. Ein DNAT-regel for ein pakke som kjernen nektar å videresende, blir godteken av regelparsaren og deretter forkasta av videresendingsvegen, noko som gir ein tidsavbrot som ser ut som eit brannmurproblem.

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

Å setje det i ein køyrande kjerne er ikkje det same som å setje det over ein omstart. Skriv net.ipv4.ip_forward=1 i ei fil under /etc/sysctl.d/, køyr sysctl --system, og les deretter verdien tilbake i staden for å stole på at fila vart plukka opp. Ein container som styrer sitt eige nettverksnamnerom treng same verdi inne i det namnerommet, ikkje berre på verten.

Viss tilbakelesinga framleis er null, stopp her. Ingenting nedanfor vil fungere.

Fest tunneladressa før nokon regel viser til ho

Bassenget deler ut adresser i tilkoplingsrekkefølgje, så ein regel skriven for dagens leige kan stille peike på ein annan klient neste veke. Bind adressa til identiteten til sertifikatet i staden for til rekkefølgja 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 ein punkt-til-punkt-tunnel, med tenaren nøkla til common name til sertifikatet. Under ein subnett-topologi blir den andre verdien i staden lesen som ein nettmaske, så skriv forma som passar til topologien som blir brukt. Kopie deretter klienten til att og les adressa på klienten sjølv, fordi tenaren sitt syn på bassenget ikkje er bevis for kva klienten konfigurerte.

Viss adressa endrar seg etter ei attoppkopling, stopp. Ein NAT-regel som følgjer eit flyttande mål vil feile med mellomrom og lære deg ingenting.

Set om begge vegar

Målomsetjing sender den innkomande pakken til klienten. Kjeldeomsetjing er det som får klienten til å svare tenaren i staden for den opphavlege avsendaren, og det er regelen folk utelèt.

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 andre regelen svarar klienten gjennom ISP-opplastingslenka si, så den eksterne peeren ser ei kjeldeadresse han aldri har snakka med, medan tenaren ikkje har noka sporingspost for svaret. Den utanforståande ser eit handtrykk som blir fullført halvvegs, og det er nettopp symptomet som sender folk på jakt etter ein brannmurfeil som ikkje finst.

Les begge reglane tilbake med iptables -t nat -S og stadfest at grensesnittnamnet er det som ber den offentlege adressa. På ein vert som allereie filtrerer med nftables, skriv omsetjinga i ein nftables-NAT-kjede av den samsvarande adressefamilien i staden for å blande verktøy.

Slepp filtertabellen gjennom

NAT-tabellane skriv om hovud; dei gir ikkje løyve. Med ein standard DROP-policy treng den videresende straumen si eiga godkjenning, pluss retningsretningen som dei fleste policyar allereie dekkjer med ein 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 til FORWARD-kjeda før du legg til noko, fordi rekkefølgja til ein tidleg DROP avgjer om regelen din i det heile blir konsultert. På ein vert der filtreringa bur i nftables, legg den tilsvarande regelen til forward-kroken i inet-tabellen og stadfest at basiskjeda faktisk ser videresend trafikk og ikkje berre lokal inngang. Viss ein pakketeljar på den nye regelen blir ståande på null medan NAT-teljarane stig, blir pakken forkasta før regelen din. Det er signalet om å lese rekkefølgja til kjedene, ikkje om å leggje til ein andre kopi av same regel.

Prov det frå eit eksternt nettverk

Test frå eit ikkje-tilknytt nettverk. Ein sondering frå ein annan maskin på same LAN kan passere gjennom hairpin-NAT-støtte og utøver aldri vegen ein ekstern klient brukar, så eit grønt resultat der bevisar det feil.

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

Køyr opptaket på tenaren og på klienten samtidig. Tenaropptaket viser om den omsette pakken går ut mot tunnelen; klientopptaket viser om førespurnaden kjem og kvar svaret er adressert. Ei omsetjingsoppføring i conntrack -L bevisar at regelen samsvarte, og fråværet bevisar at pakken aldri nådde NAT-kjeda.

Portskannarar er svak dokumentasjon. Dei rapporterer porten som lukka til applikasjonen er bunden og lyttar, så bruk ein ekte tilkopling til den ekte tenesta. Når det endeleg virkar, hald eksponeringa til den eine porten: å videresende SSH eller eit administrasjonspanel fordi den første regelen kjendest keitete er ei mykje større avgjerd enn å publisere ei teneste.