Paskelbkite VPN kliento prievadą už CGNAT: kontrolinis sąrašas
Vien tik paskirties NAT taisyklė duoda pusiau atidarytus ryšius. Užfiksuokite tunelio adresą, verskite abiem kryptimis ir prieš testą patvirtinkite atsakymo kelią.
Įdėkite paslaugą į nešiojamąjį kompiuterį už operatoriaus lygio NAT, nukreipkite tą kompiuterį į VPS per VPN, ir niekas iš išorės negalės jo pasiekti. Pridedate paskirties NAT taisyklę VPS ir gaunate ką nors blogiau nei tylą: ryšiai atsidaro ir tada sustoja. Atsakymas nedingsta, jis išeina pačio kliento numatytuoju maršrutu, o tai reiškia, kad serveris jo niekada nemato. Atlikite šiuos penkis patikrinimus iš eilės ir sustokite ties pirmuoju, kuris nepasitvirtina.
Patvirtinkite, kad serveris apskritai persiųs
Pažymėkite šį langelį prieš rašydami bent vieną vertimą. Paketo, kurio branduolys atsisako persiųsti, DNAT taisyklę priima taisyklių analizatorius, o paskui ją atmeta persiuntimo kelias, todėl atsiranda laiko limitas, kuris atrodo kaip ugniasienės problema.
sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
Nustatyti tai veikiančiame branduolyje nėra tas pats, kas nustatyti per paleidimą iš naujo. Įrašykite net.ipv4.ip_forward=1 į failą, esantį po /etc/sysctl.d/, paleiskite sysctl --system ir tada perskaitykite reikšmę iš naujo, o ne pasitikėkite, kad failas buvo paimtas. Konteineriui, kuris valdo savo tinklo vardų erdvę, tos pačios reikšmės reikia toje erdvėje, ne tik pagrindiniame kompiuteryje.
Jei perskaityta reikšmė vis dar nulis, sustokite čia. Niekas toliau neveiks.
Užfiksuokite tunelio adresą prieš bet kuriai taisyklei į jį nurodant
Telkinys dalija adresus ryšio tvarka, todėl taisyklė, parašyta šios dienos nuomai, kitą savaitę gali tyliai rodyti į kitą klientą. Susiekite adresą su sertifikato tapatybe, o ne su atvykimo tvarka.
client-config-dir /etc/openvpn/ccd
ifconfig-push 10.77.0.14 10.77.0.13
Ši pora yra taškas-taškas tunelio kliento galas ir partnerio galas, o serveris susietas su sertifikato bendruoju vardu. Potinklio topologijoje antroji reikšmė vietoj to skaitoma kaip tinklo kaukė, todėl rašykite formą, atitinkančią naudojamą topologiją. Tada iš naujo prijunkite klientą ir perskaitykite adresą pačiame kliente, nes serverio požiūris į telkinį nėra įrodymas, ką sukonfigūravo klientas.
Jei adresas pasikeičia po pakartotinio prisijungimo, sustokite. NAT taisyklė, kuri seka judantį taikinį, kartkartėmis suges ir nieko neišmokys.
Verskite abiem kryptimis
Paskirties vertimas siunčia gaunamą paketą klientui. Būtent šaltinio vertimas priverčia klientą atsakyti serveriui, o ne pirminiam siuntėjui, ir tai yra taisyklė, kurią žmonės praleidžia.
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
Be antrosios taisyklės klientas atsako per savo ISP išėjimo liniją, todėl nuotolinis partneris mato šaltinio adresą, su kuriuo niekada nekalbėjo, o serveris neturi jokio sekimo įrašo atsakymui. Išorinis stebėtojas mato pusiau pasibaigiantį rankos paspaudimą, ir būtent tai yra simptomas, kuris siunčia žmones ieškoti ugniasienės klaidos, kurios nėra.
Perskaitykite abi taisykles naudodami iptables -t nat -S ir patvirtinkite, kad sąsajos pavadinimas yra tas, kuris neša viešąjį adresą. Kompiuteryje, kuris jau filtruoja su nftables, rašykite vertimą atitinkamos adresų šeimos nftables NAT grandinėje, o ne maišykite įrankius.
Praleiskite filtro lentelę
NAT lentelės perrašo antraštes; jos nesuteikia leidimo. Esant numatytajai DROP politikai, persiunčiamas srautas turi turėti savo leidimą, be to, grįžtamąją kryptį, kurią dauguma politikų jau padengia established,related taisykle.
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
Patikrinkite FORWARD grandinės politiką prieš ką nors pridėdami, nes ankstyvos DROP tvarka lemia, ar jūsų taisyklė bus apskritai tikrinama. Kompiuteryje, kurio filtravimas gyvena nftables, pridėkite lygiavertę taisyklę prie inet lentelės forward kablio ir patvirtinkite, kad bazinė grandinė tikrai mato persiunčiamą srautą, o ne tik vietinį įėjimą. Jei naujos taisyklės paketų skaitiklis lieka nulyje, o NAT skaitikliai kyla, paketas metamas prieš jūsų taisyklę. Tai signalas skaityti grandinių tvarką, o ne pridėti antrą tos pačios taisyklės kopiją.
Įrodykite tai iš išorinio tinklo
Išbandykite iš nesusijusio tinklo. Patikra iš kitos mašinos tame pačiame LAN gali praeiti per hairpin NAT palaikymą ir niekada neišbandyti kelio, kurį naudoja nuotolinis klientas, todėl žalias rezultatas ten įrodo netinkamą dalyką.
tcpdump -ni any port 29443
conntrack -L | grep 29443
Vykdykite surinkimą serveryje ir kliente vienu metu. Serverio surinkimas rodo, ar išverstas paketas išeina link tunelio; kliento surinkimas rodo, ar užklausa ateina ir kur adresuojamas atsakymas. Vertimo įrašas conntrack -L įrodo, kad taisyklė sutapo, o jo nebuvimas įrodo, kad paketas niekada nepasiekė NAT grandinės.
Prievadų skaitytuvai yra silpnas įrodymas. Jie praneša prievadą kaip uždarytą, kol programa susieta ir klausosi, todėl naudokite tikrą ryšį su tikra paslauga. Kai pagaliau pradeda veikti, laikykite poveikį tame viename prievade: persiųsti SSH ar administravimo skydelį todėl, kad pirmoji taisyklė pasirodė nepatogi, yra daug didesnis sprendimas nei paskelbti paslaugą.