Einn opinber hýsill fyrir VPN og vef: hvernig skipta á hlutverkum

Ein vél getur svarað öllum þremur þörfum í einu: ljúka göngum, svara HTTPS og áfram senda milli tveggja einkaneta. Hvort það er skynsamlegt veltur á þremur hlutum sem hægt er að gera upp á pappír: hver á hið opinbera heimilisfang, hver á hvert port- og samskiptareglupar og hvaða ferli má áfram senda pakka. Ef þetta er rétt er sameiginlegi hýsillinn ekkert sérstakur. Ef það er rangt eyðir þú helgi í þjónustu sem byrjar hreint og svarar aldrei.

Það sem hér fer á eftir er ákvörðunarferli, ekki byggingarblað. Hvert skref endar á prófuninni sem sannar að hlutverkið sem þú varst að bæta við sé í raun einangrað.

Veldu eiganda heimilisfangsins áður en portin

Endapunktur göngs og vefþjónn geta deilt kjarna; að deila einu heimilisfangi, porti og samskiptareglu á sama tíma er það sem mistekst. WireGuard tekur venjulega UDP 51820, OpenVPN tekur UDP 1194 eða TCP 443, og vefþjónn tekur TCP 443. Parið sem særir er OpenVPN yfir TCP 443 við hlið HTTPS, því bæði vilja sama sokkann og kjarninn gefur honum sem skráði sig fyrst. Aðeins demultiplexer fyrir framan, eins og sslh eða milliþjónn sem þekkir TLS, leyfir þeim að deila þessu porti, og hann bætir við hluta sem bilunin í honum lítur nákvæmlega út eins og eldveggsvandamál.

Skoðaðu eigendurna áður en þú breytir einhverju: ss -lntup prentar staðbundið heimilisfang, port og ferli hvers hlustandi sokka. Tvær línur sem sýna 0.0.0.0:443 þýða að önnur þjónustan skráði sig aldrei, hversu glöð sem init-skriftan hennar var. Brúun færir eigandann líka. Þegar eth0 tengist br0, færist IP yfir á br0 og hver eldveggsregla sem nefnir eth0 hættir að passa, svo skráðu þjónustur á brúnni og staðfestu með ip -br addr.

Sama eignarregla útskýrir óvænt atvik sem kemur upp með sýndarvélum. Göngþjónn sem keyrir inni í gesti á sama neti heldur heimilisfangi gestsins, svo tengingar sem beinast að heimilisfangi hýsilsins sjálfs dvelja á hýslinum og göng gestsins sjá þær aldrei, hvað sem biðlarasniðið segir.

Leiddu á milli netanna tveggja eða NAT-aðu aðra hlið

Tvö net sem sjá hvort annað ekki geta hvort um sig hringt í opinbera hýsilinn, sem síðan sendir áfram milli ganganna. Sú leiðaða hönnun þarf þrjá hluti: áframsendingu kveikta, leið að hverju fjarlægu forskeyti og stefnu sem hleypir gegnumferðinni í gegn. sysctl -w net.ipv4.ip_forward=1 nær yfir þann fyrsta, ip route add 10.20.0.0/24 dev wg1 þann annan, og nftables-lína eins og nft add rule inet filter forward iifname "wg0" oifname "wg1" accept þann þriðja.

Upprunanat er auðveldara að setja upp og erfiðara að kemba. Masquerading skrifar heimilisfang biðlarans upp á nýtt, svo fjarlæga hliðin sér hubinn í stað raunverulega hýsilsins, og aðgangsreglur hans og annálar hætta að nýtast til að rekja uppruna. Þegar bæði netin eru þín, leiddu. Þegar önnur hliðin tilheyrir þriðja aðila sem bætir ekki við bakleið er NAT valkosturinn sem fer út þessa viku. Hvort sem er, skrifaðu heimilisfangaáætlunina niður, því tvö skarast /24 er ekki hægt að leiða með neinu magni af stillingum.

Ekkert við að vera internetútgangur fyrir fartölvu kemur í veg fyrir að sama kassinn ljúki innkomnum göngum. Aðeins skarast heimilisföng gera það, og þess vegna er heimilisfangaáætlunin skjalið sem skiptir máli.

Prófaðu skiptinguna meðan tvö hlutverk eru stöðvuð

Nyttuga prófið er frádráttur: stöðvaðu tvö hlutverk og staðfestu að það þriðja svari enn. Vefbeiðni á að klárast meðan göngþjónustan er niðri, og handaband ganganna á að klárast meðan vefþjónninn er stöðvaður. Ef bæði virka aðeins þegar allt keyrir hefur þú fengið óviljandi háð, eins og sameiginlega eldveggstöflu, villuleið eða nafn sem bendir á rangt heimilisfang.

Þrjár skipanir gera það próf áþreifanlegt. curl -sk --resolve example.test:443:203.0.113.10 https://example.test/ sannar að staðbundni hlustandinn svari án ytri DNS, wg show á biðlaranum sannar að handabandið kláraðist, og tcpdump -ni any port 51820 á hubnum aðgreinir leiðavandamál frá lykilvandamáli. Handaband sem birtist aldrei í upptökunni dó fyrir hýsilinn: eldveggur veitandans, rangt opinbert heimilisfang eða NAT-regla á leiðinni.

Endurtaktu frádráttinn fyrir netin sem send eru áfram. Með einn jafningja ótengdan á ping í gegnum hubinn að mistakast; þegar hann er tengdur aftur á pingið að lagast án þess að snerta reglu. Ping sem lagast aðeins eftir endurræsingu gangsins bendir á stefnu frekar en aðgengi, og það er önnur lagfæring.

Haltu reglusettinu læsilegu meðan þú dregur hlutverk frá. nft list ruleset ætti að sýna eina samþykkisreglu fyrir hverja átt sem þú þarft í raun, og áframsendingarkeðja sem samþykkir allt er ekki aðgreining, hún er vinnandi kynning.

Aðgangslínur eingöngu IPv6 og IPv4-þjónustur

Sumar aðgangslínur gefa aðeins IPv6-aðgengi, og enn þarf að birta þjónustur yfir IPv4. Göngin sjálf fara yfir þá fjölskyldu sem enn hleypir umferð í gegn, á meðan birt þjónustan situr á heimilisfangi inni í göngunum. Það snýr við hinni venjulegu forsendu og brýtur vöktunina hljóðlega: eldveggsregla eða uppitímaprófun sem skrifuð var fyrir IPv4-leiðina fylgist nú með viðmóti sem ber ekkert.

Prófaðu hvora fjölskyldu fyrir sig með curl -4 og curl -6, því ein farsæl beiðni segir ekkert um leiðina sem þú reyndir ekki. Eign portanna breytist ekki milli fjölskyldna, en hlustandinn gerir það: ss -lntup listar IPv4- og IPv6-sokka á aðskildum línum, og 0.0.0.0:443 nær ekki yfir [::]:443 nema ferlið hafi beðið um dual-stack sokka.

Þjónusta sem svarar á einni fjölskyldu og neitar á hinni er venjulega hlustandavandamál, ekki leiðavandamál. Áður en þú kallar hönnunina fullbúna skaltu staðfesta að hvert hlutverk eigi sitt eigið heimilisfang eða port, að áframsending sé kveikt og leyfð, og að hvert hlutverk svari enn meðan hin tvö eru stöðvuð.