Üks avalik host VPN-ile ja veebile: kuidas rolle jagada

Üks masin võib täita kõiki kolme vajadust korraga: lõpetada tunnelid, vastata HTTPS-ile ja vahendada kahe privaatse lokaalvõrgu vahel. Kas see on mõistlik, sõltub kolmest asjast, mille saab paberil selgeks vaielda: kes omab avalikku aadressi, kes omab iga pordi ja protokolli paari ning millisel protsessil on lubatud pakette edasi saata. Kui need on õigesti, ei ole jagatud hostis midagi märkimisväärset. Kui need on valesti, veedad nädalavahetuse teenusega, mis käivitub puhtalt ega vasta kunagi.

Järgnev on pigem otsustusprotseduur kui ehitamise juhend. Iga samm lõpeb kontrolliga, mis tõestab, et äsja lisatud roll on tõesti isoleeritud.

Vali aadressi omanik enne porte

Tunneli otspunkt ja veebiserver võivad jagada tuuma; ühe aadressi, pordi ja protokolli samaaegne jagamine on see, mis ebaõnnestub. WireGuard kasutab tavaliselt UDP-porti 51820, OpenVPN kasutab UDP-porti 1194 või TCP-porti 443 ning veebiserver kasutab TCP-porti 443. Valus paar on OpenVPN üle TCP-pordi 443 HTTPS-i kõrval, sest mõlemad tahavad sama soklit ja tuum annab selle sellele, kes esimesena sidus. Ainult demultiplekser ees, näiteks sslh või TLS-i mõistev puhverserver, lubab neil seda porti jagada, ja see lisab komponendi, mille rike näeb välja täpselt nagu tulemüüri probleem.

Vaata omanikke enne, kui midagi muudad: ss -lntup väljastab iga kuulava sokli kohaliku aadressi, pordi ja protsessi. Kaks rida, kus on 0.0.0.0:443, tähendavad, et teine teenus ei sidunud kunagi, ükskõik kui rõõmsameelne selle init-skript ka oli. Sildamine liigutab omanikku samuti. Kui eth0 ühineb br0-ga, liigub IP aadressile br0 ja iga tulemüürireegel, mis nimetab eth0-t, lakkab sobimast, seega seo teenused sillale ja kinnita ip -br addr-ga.

Sama omandireegel seletab üllatust, mis ilmneb virtuaalmasinatega. Tunnelserver, mis töötab samas lokaalvõrgus asuva külalismasina sees, hoiab külalise aadressi, seega hosti enda aadressile suunatud ühendused jäävad hosti juurde ja külalise tunnel ei näe neid kunagi, ükskõik mida kliendi profiil väidab.

Marsruudi kahe lokaalvõrgu vahel või NAT-i üks pool

Kaks lokaalvõrku, mis üksteist ei näe, võivad mõlemad helistada avalikule hostile, mis seejärel vahendab tunnelite vahel. See marsruuditud lahendus nõuab kolme asja: sisse lülitatud edastamist, iga kaugema prefiksi poole osutavat marsruuti ja edastuspoliitikat, mis laseb transiidi läbi. sysctl -w net.ipv4.ip_forward=1 katab esimese, ip route add 10.20.0.0/24 dev wg1 teise, ja nftables'i rida nagu nft add rule inet filter forward iifname "wg0" oifname "wg1" accept kolmanda.

Lähteaadressi NAT on lihtsam külge panna ja raskem siluda. Maskeerimine kirjutab kliendi aadressi ümber, nii et kaugem pool näeb jaoturit, mitte tegelikku hosti, ja selle juurdepääsureeglid ning logid ei ole enam atribuutimiseks kasulikud. Kui mõlemad võrgud on sinu omad, marsruudi. Kui üks pool kuulub kolmandale osapoolele, kes tagasiteed ei lisa, on NAT see valik, mis sel nädalal valmis jõuab. Mõlemal juhul pane aadressiplaan kirja, sest kahte kattuvat /24 ei saa ükski konfiguratsioon marsruutida.

Miski selles, et seade toimib sülearvuti internetiväljapääsuna, ei takista sama masinat lõpetamast sissetulevaid tunneleid. Seda teevad ainult kattuvad aadressid, mistõttu on aadressiplaan dokument, mis loeb.

Testi jaotust, kui kaks rolli on peatatud

Kasulik test on lahutamine: peata kaks rolli ja kinnita, et kolmas vastab endiselt. Veebipäring peaks lõpule jõudma, kui tunneliteenus on maas, ja tunneli käepigistus peaks lõpule jõudma, kui veebiserver on peatatud. Kui mõlemad töötavad ainult siis, kui kõik töötab, on sul juhuslik sõltuvus, näiteks jagatud tulemüüritabel, eksinud marsruut või vale aadressi osutav nimi.

Kolm käsku teevad selle testi konkreetseks. curl -sk --resolve example.test:443:203.0.113.10 https://example.test/ tõestab, et kohalik kuulaja vastab ilma välise DNS-ita, wg show kliendi poolel tõestab, et käepigistus lõppes, ja tcpdump -ni any port 51820 jaoturil eristab marsruutimisprobleemi võtmeprobleemist. Käepigistus, mis püüdmises kunagi ei ilmu, suri enne hosti: teenusepakkuja tulemüür, vale avalik aadress või NAT-reegel teel.

Korda lahutamist edastatavate lokaalvõrkude puhul. Kui üks peer on lahti ühendatud, peaks ping üle jaoturi ebaõnnestuma; kui see on uuesti ühendatud, peaks ping taastuma ilma reegli puutumiseta. Ping, mis taastub alles pärast tunneli taaskäivitamist, osutab poliitikale, mitte kättesaadavusele, ja see on teine parandus.

Hoia reeglistik loetav, kui rolle lahutad. nft list ruleset peaks näitama üht lubamisreeglit iga suuna kohta, mida sa tegelikult vajad, ja edastusahel, mis lubab kõike, ei ole eraldamine, vaid töötav demo.

Ainult IPv6-ga liinid ja IPv4 teenused

Mõned liinid annavad ainult IPv6 kättesaadavust ja teenuseid tuleb ikkagi avaldada üle IPv4. Tunnel ise liigub selle perekonna kaudu, mis veel liiklust läbi laseb, samal ajal kui avaldatud teenus asub tunneli sees oleval aadressil. See pöörab tavapärase eelduse tagurpidi ja rikub vaikselt monitooringu: IPv4 teele kirjutatud tulemüürireegel või tööaja kontroll jälgib nüüd liidest, mis ei kanna midagi.

Testi kumbagi perekonda eraldi käsuga curl -4 ja curl -6, sest üks õnnestunud päring ei ütle midagi tee kohta, mida sa ei proovinud. Pordi omand ei muutu perekondade vahel, aga kuulaja muutub: ss -lntup loetleb IPv4 ja IPv6 soklid eraldi ridadena ning 0.0.0.0:443 ei kata [::]:443, kui protsess ei küsinud kahe virna soklit.

Teenus, mis vastab ühes perekonnas ja keeldub teises, on tavaliselt kuulaja probleem, mitte marsruutimise oma. Enne kui nimetad disaini valmis, kinnita, et iga roll omab oma aadressi või porti, et edastamine on sisse lülitatud ja lubatud, ning et iga roll vastab endiselt, kui kaks ülejäänut on peatatud.