Publisearje in VPN-klantpoarte fan efter CGNAT: kontrôlelist

Set in tsjinst op in laptop efter carrier-grade NAT, rjochtsje dy laptop op in VPS oer in VPN, en nimmen bûten kin derby. Jo foegje in bestimming-NAT-regel ta op 'e VPS en krije wat slimmer as stilte: ferbiningen iepenje en stopje dan. It antwurd ûntbrekt net, it ferlit oer de eigen standertrûte fan 'e klant, wat betsjut dat de tsjinner it nea sjocht. Wurkje dizze fiif kontrôles yn folchoarder ôf en stop by de earste dy't net hâldt.

Befêstigje dat de tsjinner hielendal trochstjoere sil

Set dit fakje oan foar't jo ien oersetting skriuwe. In DNAT-regel foar in pakket dat de kearn wegeret troch te stjoeren wurdt troch de regelparser akseptearre en dêrnei troch it trochstjoerpaad weilitten, wat in timeout jout dy't op in firewallprobleem liket.

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

It ynstellen yn in rinnende kearn is net itselde as it oer in werstart hinne ynstellen. Skriuw net.ipv4.ip_forward=1 yn in bestân ûnder /etc/sysctl.d/, fier sysctl --system út, en lês de wearde dan werom ynstee fan te fertrouwen dat it bestân oppakt is. In kontener dy't syn eigen netwurknammeromte beheart hat deselde wearde nedich binnen dy romte, net allinnich op 'e host.

As it weromlêzen noch altyd nul is, stop hjir. Neat fierder sil wurkje.

Pin it tunneladres fêst foar't ien regel dernei ferwiist

De pool dielt adressen út yn ferbiningsfolchoarder, dus in regel skreaun foar de hjoeddeiske lease kin folgjende wike stil nei in oare klant wize. Bin it adres oan 'e identiteit fan it sertifikaat ynstee fan oan oankomstfolchoarder.

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

Dat pear is de klantkant en de peerkant fan in punt-nei-punt-tunnel, wêrby't de tsjinner kaaie is op 'e mienskiplike namme fan it sertifikaat. Under in subnet-topology wurdt de twadde wearde ynstee as in netmasker lêzen, skriuw dus de foarm dy't by de brûkte topology past. Ferbyn dan de klant wer en lês it adres op 'e klant sels, want de blik fan 'e tsjinner op 'e pool is gjin bewiis fan wat de klant konfigurearre hat.

As it adres nei in werferbining feroaret, stop. In NAT-regel dy't in beweecht doel folget sil periodyk mislearje en jo neat leare.

Fertaal yn beide rjochtingen

Bestimmingsoersetting stjoert it ynkommende pakket nei de klant. Boarne-oersetting is wat de klant de tsjinner antwurdzje lit ynstee fan 'e oarspronklike ôfstjoerder, en dat is de regel dy't minsken weilitte.

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

Sûnder de twadde regel antwurdet de klant oer syn ISP-opgeande link, dus de fiere peer sjocht in boarneres adres dêr't er nea mei praat hat, wylst de tsjinner gjin folchynskaai foar it antwurd hat. De bûtenste waarnimmer sjocht in hânskodding dy't heal foltôget, en dat is krekt it symptoom dat minsken efter in firewallflater sykje lit dy't der net is.

Lês beide regels werom mei iptables -t nat -S en befêstigje dat de ynterfaznamme dejinge is dy't it publike adres draacht. Op in host dy't al mei nftables filteret, skriuw de oersetting yn in nftables-NAT-keten fan 'e oerienkommende adresfamylje ynstee fan helpmiddelen te mingen.

Lit de filtertabel troch

De NAT-tabellen skriuwe kopteksten om; se jouwe gjin tastimming. Mei in standert-DROP-belied hat de trochstjoerde stream syn eigen akseptaasje nedich, plus de weromrjochting dy't de measte belieden al mei in established,related-regel dekke.

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

Kontrolearje it belied fan 'e FORWARD-keten foar't jo wat tafoegje, want de folchoarder fan in iere DROP beslút oft jo regel ea rieplachte wurdt. Op in host waans filtering yn nftables wennet, foegje de lykweardige regel ta oan 'e forward-hook fan 'e inet-tabel en befêstigje dat de basisketen wier trochstjoerd ferkear sjocht en net allinnich lokale ynfier. As in pakketteller op 'e nije regel op nul bliuwt wylst de NAT-tellers stige, wurdt it pakket foar jo regel weilitten. Dat is it sinjaal om de ketenfolchoarder te lêzen, net om in twadde kopy fan deselde regel ta te foegjen.

Bewiis it fan in bûtennetwurk ôf

Test fan in net besibbe netwurk. In probe fan in oare masine op itselde LAN kin troch hairpin-NAT-stipe gean en nea it paad beoefenje dat in fiere klant brûkt, dus in grien resultaat dêr bewiist it ferkearde ding.

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

Fier de opname op 'e tsjinner en op 'e klant tagelyk út. De opname fan 'e tsjinner lit sjen oft it fertaalde pakket nei de tunnel ferlit; de opname fan 'e klant lit sjen oft it fersyk oankomt en wêr't it antwurd adressearre is. In oersettingsynskriuwing yn conntrack -L bewiist dat de regel oerienkaam, en it ûntbrekken dêrfan bewiist dat it pakket nea de NAT-keten berikte.

Poarteskanners binne swak bewiis. Se melde de poarte as sletten oant de applikaasje bûn is en harket, dus brûk in echte ferbining nei de echte tsjinst. As it einlings wurket, hâld de bleatstelling by dy iene poarte: SSH of in adminpaniel trochstjoere om't de earste regel ûnhandich fielde is in folle grutter beslút as in tsjinst publisearje.