Vienas viešas serveris VPN ir webui: kaip padalyti vaidmenis

Viena mašina gali iš karto patenkinti tris poreikius: užbaigti tunelius, atsakyti HTTPS ir persiųsti tarp dviejų privačių LAN. Ar tai prasminga, priklauso nuo trijų dalykų, kuriuos galima išspręsti popieriuje: kam priklauso viešas adresas, kam priklauso kiekviena prievado ir protokolo pora ir kuriam procesui leidžiama persiųsti paketus. Jei tai teisinga, bendras serveris niekuo neypatingas. Jei ne, praleisite savaitgalį prie paslaugos, kuri startuoja švariai ir niekada neatsako.

Toliau pateikiama sprendimo procedūra, o ne statybos lapas. Kiekvienas žingsnis baigiasi patikra, įrodančia, kad ką tik pridėtas vaidmuo tikrai izoliuotas.

Adreso savininką pasirinkite prieš prievadus

Tunelio galinis taškas ir web serveris gali dalytis branduoliu; vieno adreso, prievado ir protokolo dalijimasis tuo pačiu metu yra tai, kas nepavyksta. WireGuard paprastai naudoja UDP 51820, OpenVPN naudoja UDP 1194 arba TCP 443, o web serveris naudoja TCP 443. Skausminga pora yra OpenVPN per TCP 443 šalia HTTPS, nes abu nori to paties lizdo, o branduolys jį atiduoda tam, kuris prisijungė pirmas. Tik demultiplekseris priekyje, pavyzdžiui, sslh arba TLS suprantantis proxy, leidžia jiems dalytis šiuo prievadu, ir jis prideda komponentą, kurio gedimas atrodo lygiai kaip ugniasienės problema.

Pažiūrėkite į savininkus prieš ką nors keisdami: ss -lntup išspausdina kiekvieno klausančio lizdo vietinį adresą, prievadą ir procesą. Dvi eilutės, rodančios 0.0.0.0:443, reiškia, kad antroji paslauga niekada neprisijungė, kad ir koks linksmas buvo jos init scenarijus. Tiltas taip pat perkelia savininką. Kai eth0 prisijungia prie br0, IP pereina į br0 ir kiekviena ugniasienės taisyklė, kuri nurodo eth0, nustoja atitikti, todėl susiekite paslaugas su tiltu ir patvirtinkite su ip -br addr.

Ta pati nuosavybės taisyklė paaiškina netikėtumą, kuris pasitaiko su virtualiomis mašinomis. Tunelio serveris, veikiantis svečio viduje tame pačiame LAN, išlaiko svečio adresą, todėl jungtys, nukreiptos į paties serverio adresą, lieka serveryje, o svečio tunelis jų niekada nemato, ką bebūtų sakoma kliento profilyje.

Maršrutizuokite tarp dviejų LAN arba NAT vieną pusę

Du LAN, kurie nemato vienas kito, gali kiekvienas skambinti viešam serveriui, kuris tada persiunčia tarp tunelių. Šiam maršrutizuotam dizainui reikia trijų dalykų: įjungto persiuntimo, maršruto į kiekvieną nuotolinį prefiksą ir persiuntimo politikos, kuri praleidžia tranzitą. sysctl -w net.ipv4.ip_forward=1 apima pirmąjį, ip route add 10.20.0.0/24 dev wg1 antrąjį, o nftables eilutė, pavyzdžiui, nft add rule inet filter forward iifname "wg0" oifname "wg1" accept trečiąjį.

Šaltinio NAT lengviau pridėti ir sunkiau derinti. Maskavimas perrašo kliento adresą, todėl tolimoji pusė mato koncentratorių, o ne tikrąjį serverį, ir jos prieigos taisyklės bei žurnalai tampa netinkami atribucijai. Kai abu tinklai jūsų, maršrutizuokite. Kai viena pusė priklauso trečiajai šaliai, kuri nepridės grįžimo maršruto, NAT yra tas variantas, kuris išsiunčiamas šią savaitę. Bet kuriuo atveju užsirašykite adresų planą, nes dviejų persidengiančių /24 negali maršrutizuoti jokia konfigūracija.

Niekas tame, kad dėžė tarnauja kaip interneto išėjimas nešiojamajam kompiuteriui, netrukdo tai pačiai dėžei užbaigti gaunamus tunelius. Tai trukdo tik persidengiantys adresai, ir todėl adresų planas yra tas dokumentas, kuris svarbus.

Išbandykite padalijimą, kai du vaidmenys sustabdyti

Naudingas bandymas yra atimtis: sustabdykite du vaidmenis ir patvirtinkite, kad trečiasis vis dar atsako. Web užklausa turi būti baigta, kai tunelio paslauga išjungta, o tunelio rankos paspaudimas turi būti baigtas, kai web serveris sustabdytas. Jei abu veikia tik tada, kai viskas veikia, turite atsitiktinę priklausomybę, pavyzdžiui, bendrą ugniasienės lentelę, paklydusį maršrutą ar vardą, rodantį į neteisingą adresą.

Trys komandos padaro tą bandymą konkrečiu. curl -sk --resolve example.test:443:203.0.113.10 https://example.test/ įrodo, kad vietinis klausytojas atsako be išorinio DNS, wg show kliente įrodo, kad rankos paspaudimas baigtas, ir tcpdump -ni any port 51820 koncentratoriuje atskiria maršrutizavimo problemą nuo rakto problemos. Rankos paspaudimas, kuris niekada nepasimato įraše, mirė prieš serverį: tiekėjo ugniasienė, neteisingas viešas adresas arba NAT taisyklė kelyje.

Pakartokite atimtį persiunčiamiems LAN. Atjungus vieną partnerį, ping per koncentratorių turėtų nepavykti; vėl prijungus, ping turėtų atsistatyti neliečiant taisyklės. Ping, kuris atsistato tik paleidus tunelį iš naujo, nurodo politiką, o ne pasiekiamumą, ir tai kita pataisa.

Laikykite taisyklių rinkinį įskaitomą, kol atmetate vaidmenis. nft list ruleset turėtų rodyti po vieną priėmimo taisyklę kiekvienai krypčiai, kurios tikrai reikia, o persiuntimo grandinė, priimanti viską, nėra atskyrimas, tai veikianti demonstracija.

Tik IPv6 prieigos linijos ir IPv4 paslaugos

Kai kurios prieigos linijos suteikia tik IPv6 pasiekiamumą, o paslaugos vis tiek turi būti skelbiamos per IPv4. Pats tunelis keliauja šeima, kuri dar praleidžia srautą, o paskelbta paslauga yra adresu tunelio viduje. Tai apverčia įprastą prielaidą ir tyliai sugadina stebėjimą: ugniasienės taisyklė ar veikimo laiko patikra, parašyta IPv4 keliui, dabar stebi sąsają, kuri nieko neneša.

Išbandykite kiekvieną šeimą atskirai su curl -4 ir curl -6, nes viena sėkminga užklausa nieko nesako apie kelią, kurio nebandėte. Prievadų nuosavybė nesikeičia tarp šeimų, bet klausytojas keičiasi: ss -lntup išvardija IPv4 ir IPv6 lizdus atskirose eilutėse, o 0.0.0.0:443 neapima [::]:443, nebent procesas paprašė dual-stack lizdo.

Paslauga, kuri atsako vienoje šeimoje ir atsisako kitoje, paprastai yra klausytojo problema, o ne maršrutizavimo. Prieš skelbdami dizainą baigtu, patvirtinkite, kad kiekvienas vaidmuo turi savo adresą ar prievadą, kad persiuntimas įjungtas ir leidžiamas, ir kad kiekvienas vaidmuo vis dar atsako, kai kiti du sustabdyti.