Un singur host public pentru VPN și web: cum împarți rolurile

O singură mașină poate satisface toate cele trei nevoi deodată: să termine tuneluri, să răspundă la HTTPS și să redirecționeze între două rețele LAN private. Dacă asta e rezonabil se reduce la trei lucruri pe care le poți stabili pe hârtie: cine deține adresa publică, cine deține fiecare pereche de port și protocol și cărui proces îi este permis să redirecționeze pachete. Dacă le nimerești, hostul partajat nu are nimic special. Dacă greșești, vei petrece un weekend cu un serviciu care pornește curat și nu răspunde niciodată.

Ce urmează este o procedură de decizie, nu o fișă de construcție. Fiecare pas se termină cu verificarea care dovedește că rolul adăugat acum este într-adevăr izolat.

Alege proprietarul adresei înaintea porturilor

Un punct final de tunel și un server web pot împărți un kernel; împărțirea unei adrese, a unui port și a unui protocol în același timp este ceea ce eșuează. WireGuard ia de obicei UDP 51820, OpenVPN ia UDP 1194 sau TCP 443, iar un server web ia TCP 443. Perechea dureroasă este OpenVPN peste TCP 443 lângă HTTPS, pentru că ambele vor același socket, iar kernelul îl dă celui care s-a legat primul. Doar un demultiplexor în față, cum ar fi sslh sau un proxy conștient de TLS, le lasă să împartă acel port, și adaugă o componentă a cărei defecțiune arată exact ca o problemă de firewall.

Uită-te la proprietari înainte de a schimba ceva: ss -lntup tipărește adresa locală, portul și procesul fiecărui socket care ascultă. Două rânduri care arată 0.0.0.0:443 înseamnă că al doilea serviciu nu s-a legat niciodată, oricât de vesel era scriptul lui init. Puntea mută și proprietarul. Când eth0 se alătură la br0, IP-ul trece la br0 și fiecare regulă de firewall care numește eth0 încetează să se potrivească, așa că leagă serviciile pe punte și confirmă cu ip -br addr.

Aceeași regulă de proprietate explică o surpriză care apare la mașinile virtuale. Un server de tunel care rulează într-un oaspete din aceeași rețea LAN păstrează adresa oaspetelui, așa că conexiunile îndreptate spre adresa hostului rămân pe host, iar tunelul oaspetelui nu le vede niciodată, orice ar spune profilul clientului.

Rutează între cele două rețele LAN sau fă NAT pe o parte

Două rețele LAN care nu se văd pot fiecare să sune hostul public, care apoi redirecționează între tuneluri. Acest design rutat are nevoie de trei lucruri: redirecționare pornită, o rută către fiecare prefix îndepărtat și o politică de redirecționare care lasă tranzitul să treacă. sysctl -w net.ipv4.ip_forward=1 acoperă primul, ip route add 10.20.0.0/24 dev wg1 al doilea, iar o linie nftables precum nft add rule inet filter forward iifname "wg0" oifname "wg1" accept al treilea.

NAT-ul de sursă este mai ușor de adăugat și mai greu de depanat. Mascarea rescrie adresa clientului, așa că partea îndepărtată vede hubul în loc de hostul real, iar regulile de acces și jurnalele ei nu mai sunt utile pentru atribuire. Când ambele rețele sunt ale tale, rutează. Când o parte aparține unui terț care nu va adăuga o rută de retur, NAT este opțiunea care pleacă săptămâna asta. În orice caz, scrie planul de adrese, pentru că două /24 suprapuse nu pot fi rutate de nicio configurație.

Nimic din faptul că mașina servește drept ieșire la internet pentru un laptop nu împiedică aceeași mașină să termine tuneluri de intrare. Doar adresele suprapuse o împiedică, și de aceea planul de adrese este documentul care contează.

Testează împărțirea cu două roluri oprite

Testul util este scăderea: oprește două roluri și confirmă că al treilea încă răspunde. O cerere web trebuie să se finalizeze cu serviciul de tunel oprit, iar un handshake de tunel trebuie să se finalizeze cu serverul web oprit. Dacă ambele funcționează doar când totul rulează, ai o dependență accidentală, cum ar fi un tabel de firewall partajat, o rută rătăcită sau un nume care indică adresa greșită.

Trei comenzi fac testul concret. curl -sk --resolve example.test:443:203.0.113.10 https://example.test/ dovedește că ascultătorul local răspunde fără DNS extern, wg show pe client dovedește că handshake-ul s-a finalizat, iar tcpdump -ni any port 51820 pe hub separă o problemă de rutare de una de cheie. Un handshake care nu apare niciodată în captură a murit înainte de host: firewall-ul furnizorului, adresă publică greșită sau o regulă NAT pe drum.

Repetă scăderea pentru rețelele LAN redirecționate. Cu un partener deconectat, un ping prin hub trebuie să eșueze; reconectat, pingul trebuie să revină fără să atingă o regulă. Un ping care revine doar după repornirea tunelului indică politica, nu accesibilitatea, iar aceea este altă corectură.

Păstrează setul de reguli lizibil în timp ce scazi roluri. nft list ruleset ar trebui să arate o regulă de acceptare pentru fiecare direcție de care ai nevoie cu adevărat, iar un lanț de redirecționare care acceptă tot nu este separare, este o demonstrație funcțională.

Linii de acces doar IPv6 și servicii IPv4

Unele linii de acces oferă doar accesibilitate IPv6, iar serviciile trebuie totuși publicate prin IPv4. Tunelul în sine călătorește prin familia care încă lasă traficul să treacă, în timp ce serviciul publicat stă pe o adresă din interiorul tunelului. Asta inversează presupunerea obișnuită și strică monitorizarea în liniște: o regulă de firewall sau o verificare de uptime scrisă pentru calea IPv4 supraveghează acum o interfață care nu duce nimic.

Testează fiecare familie separat cu curl -4 și curl -6, pentru că o cerere reușită nu spune nimic despre calea pe care nu ai încercat-o. Proprietatea porturilor nu se schimbă între familii, dar ascultătorul se schimbă: ss -lntup listează socketurile IPv4 și IPv6 pe rânduri separate, iar 0.0.0.0:443 nu acoperă [::]:443 decât dacă procesul a cerut un socket dual-stack.

Un serviciu care răspunde pe o familie și refuză pe cealaltă este de obicei o problemă de ascultător, nu de rutare. Înainte de a declara designul terminat, confirmă că fiecare rol deține propria adresă sau propriul port, că redirecționarea este pornită și permisă și că fiecare rol încă răspunde cu celelalte două oprite.