Avalda VPN-kliendi port CGNAT-i taga: kontroll-loend

Pane teenus sülearvutisse operaatori tasandi NAT-i taha, suuna see sülearvuti VPN-i kaudu VPS-ile ja keegi väljastpoolt ei pääse sellele ligi. Lisad VPS-ile sihtkoha NAT-reegli ja saad midagi hullemat kui vaikus: ühendused avanevad ja siis jäävad seisma. Vastus ei ole kadunud, see lahkub kliendi enda vaikimisi marsruudil, mis tähendab, et server ei näe seda kunagi. Käi need viis kontrolli järjekorras läbi ja peatu esimesel, mis ei pea.

Kinnita, et server üldse edastab

Märgi see ruut enne, kui kirjutad ühtki tõlget. DNAT-reegli paketi jaoks, mida tuum keeldub edastamast, võtab reeglite parser vastu ja seejärel viskab edastustee selle kõrvale, mis tekitab ajutõrke, mis näeb välja nagu tulemüüri probleem.

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

Selle seadmine töötavas tuumas ei ole sama, mis seadmine üle taaskäivituse. Kirjuta net.ipv4.ip_forward=1 faili /etc/sysctl.d/ all, käivita sysctl --system ja loe seejärel väärtus uuesti, selle asemel et usaldada, et fail haagiti. Konteiner, mis haldab oma võrgu nimeruumi, vajab sama väärtust selle nimeruumi sees, mitte ainult hostis.

Kui tagasilugemine on endiselt null, peatu siin. Midagi allpool ei hakka tööle.

Kinnita tunneliaadress enne, kui ükski reegel sellele viitab

Bassein jagab aadresse ühenduse järjekorras, nii et tänase rendi jaoks kirjutatud reegel võib järgmisel nädalal vaikselt osutada teisele kliendile. Seo aadress sertifikaadi identiteediga, mitte saabumise järjekorraga.

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

See paar on punkt-punkt-tunneli kliendiots ja partneriots, kusjuures server on seotud sertifikaadi üldnimega. Alambvõrgu topoloogias loetakse teist väärtust hoopis võrgumaskina, seega kirjuta vorm, mis vastab kasutatavale topoloogiale. Seejärel ühenda klient uuesti ja loe aadress kliendi enda pealt, sest serveri vaade basseinile ei ole tõestus selle kohta, mida klient seadistas.

Kui aadress pärast uuesti ühendamist muutub, peatu. Liikuvat sihtmärki järgiv NAT-reegel nurjub aeg-ajalt ega õpeta sulle midagi.

Tõlgi mõlemas suunas

Sihtkoha tõlge saadab sissetuleva paketi kliendile. Just lähtekoha tõlge paneb kliendi vastama serverile, mitte algsele saatjale, ja see on reegel, mille inimesed välja jätavad.

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

Ilma teise reeglita vastab klient oma ISP-i ülesvoo kaudu, nii et kauge partner näeb lähteaadressi, kellega ta kunagi rääkinud ei ole, samal ajal kui serveril ei ole vastuse jaoks ühtki jälgimiskirjet. Väline vaatleja näeb käepigistust, mis lõpeb poolelt, ja see on täpselt see sümptom, mis saadab inimesi otsima tulemüüri viga, mida ei ole olemas.

Loe mõlemad reeglid iptables -t nat -S abil tagasi ja kinnita, et liidese nimi on see, mis kannab avalikku aadressi. Hostis, mis juba filtreerib nftablesiga, kirjuta tõlge sobiva aadressiperekonna nftablesi NAT-ahelasse, selle asemel et tööriistu segada.

Lase filtriteabel läbi

NAT-tabelid kirjutavad päiseid ümber; need ei anna luba. Vaikimisi DROP-poliitika korral vajab edastatav voog omaenda luba, pluss tagasisuund, mille enamik poliitikaid juba established,related-reegliga katab.

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

Kontrolli FORWARD-ahela poliitikat enne millegi lisamist, sest varajase DROP-i järjekord otsustab, kas sinu reeglit üldse küsitakse. Hostis, mille filtreerimine elab nftablesis, lisa samaväärne reegel inet-tabeli forward-konksu ja kinnita, et baasahel näeb tõesti edastatavat liiklust, mitte ainult kohalikku sisendit. Kui uue reegli paketiloendur jääb nulli, samal ajal kui NAT-i loendurid tõusevad, visatakse pakett enne sinu reeglit ära. See on signaal lugeda ahelate järjekorda, mitte lisada sama reegli teist koopiat.

Tõesta seda välisest võrgust

Testi mitteseotud võrgust. Päring teisest masinast samas LAN-is võib läbida hairpin-NAT-i toe ega harjuta kunagi seda teed, mida kasutab kauge klient, nii et roheline tulemus seal tõestab vale asja.

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

Käivita püük serveris ja kliendis samal ajal. Serveri püük näitab, kas tõlgitud pakett lahkub tunneli suunas; kliendi püük näitab, kas päring saabub ja kuhu vastus on adresseeritud. Tõlkekirje conntrack -L sees tõestab, et reegel klappis, ja selle puudumine tõestab, et pakett ei jõudnud kunagi NAT-ahelani.

Pordiskannerid on nõrk tõestus. Need teatavad pordi suletuks, kuni rakendus on seotud ja kuulab, seega kasuta tõelist ühendust tõelise teenusega. Kui see lõpuks töötab, hoia avatus selle ühe pordi juures: SSH või halduspaneeli edastamine sellepärast, et esimene reegel tundus kohmakas, on palju suurem otsus kui teenuse avaldamine.