Publicați un port de client VPN din spatele CGNAT: listă de verificare

Puneți un serviciu pe un laptop în spatele unui NAT de nivel de operator, îndreptați acel laptop către un VPS printr-un VPN, și nimeni din exterior nu poate ajunge la el. Adăugați o regulă NAT de destinație pe VPS și obțineți ceva mai rău decât liniștea: conexiunile se deschid, apoi se blochează. Răspunsul nu lipsește, el pleacă pe ruta implicită proprie a clientului, ceea ce înseamnă că serverul nu îl vede niciodată. Parcurgeți aceste cinci verificări în ordine și opriți-vă la prima care nu se susține.

Confirmați că serverul va redirecționa măcar

Bifați această casetă înainte de a scrie măcar o traducere. O regulă DNAT pentru un pachet pe care kernelul refuză să îl redirecționeze este acceptată de parserul de reguli și apoi aruncată de calea de redirecționare, ceea ce produce un timeout care arată ca o problemă de firewall.

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

Setarea ei într-un kernel în execuție nu este același lucru cu setarea ei peste o repornire. Scrieți net.ipv4.ip_forward=1 într-un fișier sub /etc/sysctl.d/, rulați sysctl --system și apoi recitiți valoarea în loc să vă bazați pe faptul că fișierul a fost preluat. Un container care își administrează propriul spațiu de nume de rețea are nevoie de aceeași valoare în interiorul acelui spațiu, nu doar pe gazdă.

Dacă recitirea este încă zero, opriți-vă aici. Nimic mai jos nu va funcționa.

Fixați adresa tunelului înainte ca vreo regulă să o menționeze

Poolul distribuie adrese în ordinea conexiunilor, așa că o regulă scrisă pentru închirierea de azi poate indica în liniște un alt client săptămâna viitoare. Legați adresa de identitatea certificatului și nu de ordinea sosirii.

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

Acea pereche este capătul clientului și capătul perechii unui tunel punct-la-punct, iar serverul este legat de numele comun al certificatului. Într-o topologie de subrețea a doua valoare este citită ca mască de rețea, așa că scrieți forma care corespunde topologiei folosite. Apoi reconectați clientul și citiți adresa pe clientul însuși, pentru că viziunea serverului asupra poolului nu este dovada a ceea ce a configurat clientul.

Dacă adresa se schimbă după o reconectare, opriți-vă. O regulă NAT care urmărește o țintă mobilă va eșua intermitent și nu vă va învăța nimic.

Traduceți în ambele sensuri

Traducerea de destinație trimite pachetul de intrare la client. Traducerea de sursă este cea care face clientul să răspundă serverului și nu expeditorului original, și este regula pe care oamenii o omit.

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

Fără a doua regulă clientul răspunde prin legătura sa ISP, așa că perechea îndepărtată vede o adresă de sursă cu care nu a vorbit niciodată, în timp ce serverul nu păstrează nicio intrare de urmărire pentru răspuns. Observatorul din exterior vede un handshake care se finalizează pe jumătate, și exact acesta este simptomul care trimite oamenii să caute o eroare de firewall care nu există.

Recitiți ambele reguli cu iptables -t nat -S și confirmați că numele interfeței este cel care poartă adresa publică. Pe o gazdă care filtrează deja cu nftables, scrieți traducerea într-un lanț NAT nftables al familiei de adrese potrivite în loc să amestecați uneltele.

Lăsați tabela de filtrare să treacă

Tabelele NAT rescriu antete; ele nu acordă permisiune. Cu o politică DROP implicită, fluxul redirecționat are nevoie de propria acceptare, plus direcția de retur pe care majoritatea politicilor o acoperă deja cu o regulă 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

Verificați politica lanțului FORWARD înainte de a adăuga ceva, pentru că ordinea unui DROP timpuriu decide dacă regula dumneavoastră va fi consultată vreodată. Pe o gazdă a cărei filtrare trăiește în nftables, adăugați regula echivalentă la cârligul forward al tabelei inet și confirmați că lanțul de bază vede într-adevăr trafic redirecționat și nu doar intrare locală. Dacă un contor de pachete al noii reguli rămâne la zero în timp ce contoarele NAT cresc, pachetul este aruncat înaintea regulii dumneavoastră. Acesta este semnalul pentru a citi ordinea lanțurilor, nu pentru a adăuga o a doua copie a aceleiași reguli.

Demonstrați-o dintr-o rețea externă

Testați dintr-o rețea neînrudită. O sondă de pe altă mașină din același LAN poate trece prin suportul NAT hairpin și nu exercită niciodată calea pe care o folosește un client îndepărtat, așa că un rezultat verde acolo dovedește lucrul greșit.

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

Rulați captura pe server și pe client în același timp. Captura pe server arată dacă pachetul tradus pleacă spre tunel; captura pe client arată dacă cererea ajunge și unde este adresat răspunsul. O intrare de traducere în conntrack -L dovedește că regula s-a potrivit, iar absența ei dovedește că pachetul nu a ajuns niciodată la lanțul NAT.

Scanerele de porturi sunt dovezi slabe. Raportează portul ca închis până când aplicația este legată și ascultă, așa că folosiți o conexiune reală la serviciul real. Când în sfârșit funcționează, păstrați expunerea la acel singur port: a redirecționa SSH sau un panou de administrare pentru că prima regulă părea incomodă este o decizie mult mai mare decât publicarea unui serviciu.