Publikoni një port klienti VPN pas CGNAT: listë kontrolli

Vendosni një shërbim në një laptop pas NAT të nivelit të operatorit, drejtojeni atë laptop në një VPS përmes një VPN, dhe askush nga jashtë nuk mund ta arrijë. Shtoni një rregull NAT destinacioni në VPS dhe merrni diçka më të keqe se heshtja: lidhjet hapen dhe më pas bllokohen. Përgjigjja nuk mungon, ajo po del përmes rrugës së vetë klientit, që do të thotë se serveri nuk e sheh kurrë. Kaloni këto pesë kontrolle me radhë dhe ndaloni te i pari që nuk qëndron.

Konfirmoni se serveri do të përcjellë fare

Shënoni këtë kuti përpara se të shkruani një përkthim të vetëm. Rregulli DNAT për një paketë që bërthama refuzon ta përcjellë pranohet nga analizuesi i rregullave dhe më pas hidhet nga rruga e përcjelljes, çka prodhon një afat që duket si problem me firewall-in.

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

Vendosja e tij në një bërthamë në punë nuk është e njëjtë me vendosjen përgjatë një rindezjeje. Shkruani net.ipv4.ip_forward=1 në një skedar nën /etc/sysctl.d/, ekzekutoni sysctl --system dhe më pas lexoni vlerën përsëri në vend që të besoni se skedari u kap. Një kontejner që administron hapësirën e vet të emrave të rrjetit ka nevojë për të njëjtën vlerë brenda asaj hapësire, jo vetëm në host.

Nëse rileximi është ende zero, ndaloni këtu. Asgjë më poshtë nuk do të funksionojë.

Fiksoni adresën e tunelit përpara se ndonjë rregull t'i referohet

Pishina i shpërndan adresat sipas radhës së lidhjeve, ndaj një rregull i shkruar për qiranë e sotme mund të tregojë në heshtje një klient tjetër javën tjetër. Lidhni adresën me identitetin e certifikatës dhe jo me radhën e arritjes.

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

Ai çift është skaji i klientit dhe skaji i palës të një tuneli pikë-për-pikë, ndërsa serveri është lidhur me emrin e përbashkët të certifikatës. Në një topologji nënrrjete vlera e dytë lexohet si maskë rrjeti, ndaj shkruani formën që përputhet me topologjinë në përdorim. Më pas rilidhni klientin dhe lexoni adresën në vetë klientin, sepse pamja e serverit për pishinën nuk është provë e asaj që konfiguroi klienti.

Nëse adresa ndryshon pas një rilidhjeje, ndaloni. Një rregull NAT që ndjek një objektiv në lëvizje do të dështojë me ndërprerje dhe nuk do t'ju mësojë asgjë.

Përktheni në të dy drejtimet

Përkthimi i destinacionit dërgon paketën hyrëse te klienti. Përkthimi i burimit është ai që bën klientin të përgjigjet serverit dhe jo dërguesit origjinal, dhe është rregulli që njerëzit e lënë jashtë.

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

Pa rregullin e dytë klienti përgjigjet përmes lidhjes së tij ISP, ndaj pala e largët sheh një adresë burimi me të cilën nuk ka folur kurrë, ndërsa serveri nuk mban asnjë zë gjurmimi për përgjigjen. Vëzhguesi i jashtëm sheh një shtrëngim duarsh që përfundon gjysmë, dhe pikërisht ky është simptoma që i dërgon njerëzit të kërkojnë një gabim firewall-i që nuk ekziston.

Rilexoni të dy rregullat me iptables -t nat -S dhe konfirmoni se emri i ndërfaqes është ai që mban adresën publike. Në një host që filtron tashmë me nftables, shkruani përkthimin në një zinxhir NAT nftables të familjes së adresave që përputhet, në vend që të përzieni mjete.

Lërini tabelën e filtrave të kalojë

Tabelat NAT rishkruajnë titujt; ato nuk japin leje. Me një politikë DROP të parazgjedhur rryma e përcjellë ka nevojë për pranimin e vet, plus drejtimin e kthimit që shumica e politikave e mbulojnë tashmë me një rregull established,related.

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

Kontrolloni politikën e zinxhirit FORWARD përpara se të shtoni diçka, sepse rendi i një DROP të hershëm vendos nëse rregulli juaj do të konsultohet ndonjëherë. Në një host ku filtrimi jeton në nftables, shtoni rregullin ekuivalent te grepa forward e tabelës inet dhe konfirmoni se zinxhiri bazë sheh vërtet trafikun e përcjellë dhe jo vetëm hyrjen lokale. Nëse numëruesi i paketave në rregullin e ri mbetet zero ndërsa numëruesit NAT rriten, paketa hidhet përpara rregullit tuaj. Ky është sinjali për të lexuar rendin e zinxhirëve, jo për të shtuar një kopje të dytë të të njëjtit rregull.

Vërtetojeni nga një rrjet i jashtëm

Testoni nga një rrjet i palidhur. Një sondë nga një makinë tjetër në të njëjtin LAN mund të kalojë përmes mbështetjes hairpin NAT dhe nuk ushtron kurrë rrugën që përdor një klient i largët, ndaj një rezultat i gjelbër atje provon gjënë e gabuar.

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

Ekzekutoni kapjen në server dhe në klient në të njëjtën kohë. Kapja në server tregon nëse paketa e përkthyer del drejt tunelit; kapja në klient tregon nëse kërkesa arrin dhe ku drejtohet përgjigjja. Një zë përkthimi në conntrack -L provon se rregulli përputhej, dhe mungesa e tij provon se paketa nuk arriti kurrë zinxhirin NAT.

Skanerët e porteve janë provë e dobët. Ata raportojnë portën si të mbyllur derisa aplikacioni të lidhet dhe të dëgjojë, ndaj përdorni një lidhje të vërtetë me shërbimin e vërtetë. Kur më në fund funksionon, mbajeni ekspozimin në atë portë të vetme: përcjellja e SSH ose e një paneli administrimi sepse rregulli i parë dukej i sikletshëm është një vendim shumë më i madh sesa publikimi i një shërbimi.