Yksi julkinen isäntä VPN:lle ja webille: miten roolit jaetaan

Yksi kone voi vastata kaikkiin kolmeen tarpeeseen kerralla: päättää tunneleita, vastata HTTPS-pyyntöihin ja välittää kahden yksityisen lähiverkon välillä. Onko se järkevää, riippuu kolmesta asiasta, jotka voi selvittää paperilla: kuka omistaa julkisen osoitteen, kuka omistaa kunkin portin ja protokollan parin ja mille prosessille pakettien välittäminen on sallittu. Jos nämä ovat oikein, jaettu isäntä on mitäänsanomaton. Jos ne ovat väärin, vietät viikonlopun palvelun kanssa, joka käynnistyy siististi eikä koskaan vastaa.

Seuraava on päätösmenettely, ei rakennusohje. Jokainen vaihe päättyy tarkistukseen, joka todistaa juuri lisätyn roolin todella eristetyksi.

Valitse osoitteen omistaja ennen portteja

Tunnelin päätepiste ja web-palvelin voivat jakaa ytimen; yhden osoitteen, portin ja protokollan jakaminen samaan aikaan on se, mikä epäonnistuu. WireGuard ottaa yleensä UDP 51820:n, OpenVPN ottaa UDP 1194:n tai TCP 443:n, ja web-palvelin ottaa TCP 443:n. Kipein pari on OpenVPN TCP 443:n yli HTTPS:n rinnalla, koska molemmat haluavat saman pistokkeen ja ydin antaa sen sille, joka sitoi ensin. Vain edessä oleva demultiplekseri, kuten sslh tai TLS:ää ymmärtävä välityspalvelin, päästää ne jakamaan tuon portin, ja se lisää komponentin, jonka vika näyttää täsmälleen palomuuriongelmalta.

Katso omistajia ennen kuin muutat mitään: ss -lntup tulostaa jokaisen kuuntelevan pistokkeen paikallisen osoitteen, portin ja prosessin. Kaksi riviä, joissa on 0.0.0.0:443, tarkoittaa, että toinen palvelu ei koskaan sitonut, kuinka iloinen sen init-skripti olikaan. Sillan luominen siirtää omistajaa myös. Kun eth0 liitetään siltaan br0, IP siirtyy osoitteeseen br0 ja jokainen palomuurisääntö, joka viittaa eth0 kohteeseen, lakkaa täsmäämästä, joten sido palvelut sillalle ja vahvista ip -br addr komennolla.

Sama omistussääntö selittää yllätyksen, joka ilmaantuu virtuaalikoneiden kanssa. Samassa lähiverkossa vieraan sisällä ajettava tunnelipalvelin pitää vieraan osoitteen, joten isännän omaan osoitteeseen tähtäävät yhteydet pysyvät isännällä eikä vieraan tunneli näe niitä koskaan, mitä asiakasprofiili väittääkään.

Reititä kahden lähiverkon välillä tai NAT:aa toinen puoli

Kaksi lähiverkkoa, jotka eivät näe toisiaan, voivat kumpikin soittaa julkiselle isännälle, joka välittää tunnelien välillä. Se reititetty rakenne tarvitsee kolme asiaa: välitys päälle, reitti kohti jokaista etäprefiksiä ja välityskäytäntö, joka päästää läpikulun. sysctl -w net.ipv4.ip_forward=1 kattaa ensimmäisen, ip route add 10.20.0.0/24 dev wg1 toisen, ja nftables-rivi kuten nft add rule inet filter forward iifname "wg0" oifname "wg1" accept kolmannen.

Lähde-NAT on helpompi lisätä ja vaikeampi debugata. Masquerade kirjoittaa asiakkaan osoitteen uudelleen, joten kaukopuoli näkee hubin eikä todellista isäntää, ja sen käyttösäännöt ja lokit lakkaavat olemasta hyödyllisiä attribuutiolle. Kun molemmat verkot ovat sinun, reititä. Kun toinen puoli kuuluu kolmannelle osapuolelle, joka ei lisää paluureittiä, NAT on se vaihtoehto, joka toimitetaan tällä viikolla. Kirjoita joka tapauksessa osoitesuunnitelma, koska kahta päällekkäistä /24:ää ei mikään määrä konfiguraatiota voi reitittää.

Mikään siinä, että laatikko toimii kannettavan internet-uloskäyntinä, ei estä samaa laatikkoa päättämästä saapuvia tunneleita. Vain päällekkäiset osoitteet estävät, ja siksi osoitesuunnitelma on se dokumentti, jolla on väliä.

Testaa jako, kun kaksi roolia on pysäytettyinä

Hyödyllinen testi on vähennyslasku: pysäytä kaksi roolia ja vahvista, että kolmas vastaa yhä. Web-pyynnön pitäisi valmistua tunnelipalvelun ollessa alas, ja tunnelin kättelyn pitäisi valmistua web-palvelimen ollessa pysäytettynä. Jos molemmat toimivat vain, kun kaikki on käynnissä, sinulla on tahaton riippuvuus, kuten jaettu palomuuritaulu, harhautunut reitti tai väärään osoitteeseen osoittava nimi.

Kolme komentoa tekevät testistä konkreettisen. curl -sk --resolve example.test:443:203.0.113.10 https://example.test/ todistaa, että paikallinen kuuntelija vastaa ilman ulkoista DNS:ää, wg show asiakkaalla todistaa, että kättely valmistui, ja tcpdump -ni any port 51820 hubilla erottaa reititysongelman avainongelmasta. Kättely, joka ei koskaan ilmesty kaappaukseen, kuoli ennen isäntää: tarjoajan palomuuri, väärä julkinen osoite tai matkalla oleva NAT-sääntö.

Toista vähennys välitetyille lähiverkoille. Kun yksi vastapuoli on irti, ping hubin yli pitäisi epäonnistua; kun se on taas yhdistetty, pingin pitäisi palautua sääntöön koskematta. Ping, joka palautuu vasta tunnelin uudelleenkäynnistyksen jälkeen, osoittaa käytäntöön eikä tavoitettavuuteen, ja se on eri korjaus.

Pidä sääntöjoukko luettavana, kun vähennät rooleja. nft list ruleset pitäisi näyttää yksi accept-sääntö per suunta, jota todella tarvitset, ja välitysketju, joka hyväksyy kaiken, ei ole erottelua vaan toimiva demo.

Vain IPv6:n liityntälinjat ja IPv4-palvelut

Jotkut liityntälinjat antavat vain IPv6-tavoitettavuutta, ja palvelut on silti julkaistava IPv4:n yli. Itse tunneli kulkee sen perheen yli, joka vielä läpäisee liikennettä, kun taas julkaistu palvelu istuu tunnelin sisäisessä osoitteessa. Tämä kääntää tavallisen oletuksen ympäri ja rikkoo hiljaa valvonnan: IPv4-polulle kirjoitettu palomuurisääntö tai käytettävyystarkistus tarkkailee nyt rajapintaa, joka ei kanna mitään.

Testaa kumpikin perhe erikseen komennolla curl -4 ja curl -6, koska yksi onnistunut pyyntö ei kerro mitään polusta, jota et kokeillut. Portin omistus ei muutu perheiden välillä, mutta kuuntelija muuttuu: ss -lntup listaa IPv4- ja IPv6-pistokkeet eri riveinä, ja 0.0.0.0:443 ei kata [::]:443 ellei prosessi pyytänyt dual-stack-pistoketta.

Palvelu, joka vastaa yhdessä perheessä ja kieltäytyy toisessa, on yleensä kuuntelijan ongelma, ei reitityksen. Ennen kuin kutsut suunnitelman valmiiksi, vahvista, että jokainen rooli omistaa oman osoitteensa tai porttinsa, että välitys on päällä ja sallittu, ja että jokainen rooli vastaa yhä kahden muun ollessa pysäytettyinä.