Egy nyilvános gazdagép VPN-hez és webhez: hogyan osszuk fel a szerepeket
Egy nyilvános IP cím alagutakat terminálhat, HTTPS-t szolgálhat ki és elérhet két privát LAN-t. Előbb döntse el, kié a cím, az egyes portok és a továbbítási szabály.
Egy gép egyszerre mindhárom igényt kiszolgálhatja: alagutakat terminál, HTTPS-re válaszol és két privát LAN között továbbít. Hogy ez ésszerű-e, három dologra vezethető vissza, amit papíron el lehet dönteni: kié a nyilvános cím, kié az egyes port- és protokollpárok, és melyik folyamat továbbíthat csomagokat. Ha ezek rendben vannak, a megosztott gazdagép semmilyen különlegességet nem mutat. Ha elrontja, egy hétvégét tölt el egy szolgáltatással, amely tisztán indul és soha nem válaszol.
A következő döntési eljárás, nem építési lap. Minden lépés azzal az ellenőrzéssel zárul, amely bizonyítja, hogy az imént hozzáadott szerep valóban elkülönül.
A cím tulajdonosát a portok előtt válassza ki
Egy alagút végpontja és egy webszerver osztozhat egy kernelben; egy cím, port és protokoll egyidejű megosztása az, ami elromlik. A WireGuard általában UDP 51820-at használ, OpenVPN UDP 1194-et vagy TCP 443-at használ, a webszerver pedig TCP 443-at. A fájó pár a HTTPS mellett TCP 443-on futó OpenVPN, mert mindkettő ugyanazt a socketet akarja, és a kernel annak adja, aki előbb kötötte le. Csak az előtte álló demultiplexer, például az sslh vagy egy TLS-tudatos proxy engedi megosztani ezt a portot, és olyan komponenst ad hozzá, amelynek hibája pontosan tűzfalproblémának látszik.
Nézze meg a tulajdonosokat, mielőtt bármit módosít: ss -lntup kiírja minden hallgató socket helyi címét, portját és folyamatát. Két sor, amely 0.0.0.0:443 mutat, azt jelenti, hogy a második szolgáltatás soha nem kötötte le, bármennyire vidám volt az init szkriptje. A híd is áthelyezi a tulajdonost. Amikor eth0 csatlakozik ehhez a hídhoz: br0, az IP átkerül erre a címre: br0 és minden tűzfalszabály, amely eth0 megnevezi, megszűnik illeszkedni, ezért kösse a szolgáltatásokat a hídra, és ellenőrizze ip -br addr paranccsal.
Ugyanez a tulajdonosi szabály magyarázza meg azt a meglepetést, amely virtuális gépeknél jelentkezik. Az ugyanazon a LAN-on belüli vendégben futó alagútszerver megtartja a vendég címét, ezért a gazdagép saját címére irányuló kapcsolatok a gazdagépen maradnak, és a vendég alagútja soha nem látja őket, akármit is állít az ügyfélprofil.
Forgasson a két LAN között, vagy NAT-oljon egy oldalt
Két LAN, amely nem látja egymást, mindkettő tárcsázhatja a nyilvános gazdagépet, amely aztán továbbít az alagutak között. Ehhez az útvonalválasztó tervhez három dolog kell: bekapcsolt továbbítás, útvonal minden távoli előtaghoz, és továbbítási szabály, amely átengedi a tranzitot. sysctl -w net.ipv4.ip_forward=1 az elsőt fedi le, ip route add 10.20.0.0/24 dev wg1 a másodikat, és egy nftables-sor, mint nft add rule inet filter forward iifname "wg0" oifname "wg1" accept a harmadikat.
A forrás NAT-ot könnyebb feltenni és nehezebb hibakeresni. A masquerading átírja az ügyfél címét, ezért a távoli oldal a hubot látja a valódi gazdagép helyett, és a hozzáférési szabályai meg a naplói használhatatlanná válnak az attribúcióhoz. Ha mindkét hálózat az Öné, forgasson. Ha az egyik oldal egy harmadik félé, amely nem tesz visszaútvonalat, a NAT az a választás, amely ezen a héten kimegy. Mindkét esetben írja le a címtervet, mert két átfedő /24-et semmilyen konfiguráció nem tud átforgatni.
Semmi abban, hogy a doboz internetes kijáratként szolgál egy laptopnak, nem akadályozza meg ugyanazt a dobozt abban, hogy bejövő alagutakat termináljon. Csak az átfedő címek akadályozzák meg, és ezért a címterv az a dokumentum, amely számít.
Tesztelje a felosztást, miközben két szerep áll
A hasznos teszt a kivonás: állítson le két szerepet, és erősítse meg, hogy a harmadik még válaszol. Egy webkérésnek akkor is be kell fejeződnie, ha az alagútszolgáltatás áll, és egy alagút-kézfogásnak akkor is be kell fejeződnie, ha a webszerver le van állítva. Ha mindkettő csak akkor működik, amikor minden fut, véletlen függősége van, például megosztott tűzfaltábla, elkóborolt útvonal vagy rossz címre mutató név.
Három parancs teszi konkréttá ezt a tesztet. curl -sk --resolve example.test:443:203.0.113.10 https://example.test/ bizonyítja, hogy a helyi hallgató külső DNS nélkül válaszol, wg show az ügyfélen bizonyítja, hogy a kézfogás befejeződött, és tcpdump -ni any port 51820 a hubon elválasztja az útvonalválasztási problémát a kulcsproblémától. Az a kézfogás, amely soha nem jelenik meg a rögzítésben, a gazdagép előtt halt meg: szolgáltatói tűzfal, rossz nyilvános cím vagy egy NAT-szabály az úton.
Ismételje meg a kivonást a továbbított LAN-okra. Egy peer leválasztásával a hubon átmenő ping-nek meg kell hiúsulnia; újracsatlakoztatva a pingnek szabály érintése nélkül helyre kell állnia. Az a ping, amely csak az alagút újraindítása után áll helyre, szabályzatra mutat, nem elérhetőségre, és az más javítás.
Tartsa olvashatónak a szabálykészletet, miközben szerepeket von ki. nft list ruleset irányonként egy elfogadó szabályt mutasson, amelyre valóban szüksége van, és a mindent elfogadó továbbítási lánc nem elkülönítés, hanem működő demó.
Csak IPv6-os hozzáférési vonalak és IPv4-es szolgáltatások
Egyes hozzáférési vonalak csak IPv6-os elérhetőséget adnak, a szolgáltatásokat pedig mégis IPv4 fölött kell közzétenni. Maga az alagút azon a családon megy át, amely még átengedi a forgalmat, míg a közzétett szolgáltatás az alagúton belüli címen ül. Ez megfordítja a szokásos feltevést, és csendben elrontja a megfigyelést: az IPv4-es útra írt tűzfalszabály vagy üzemidő-ellenőrzés most olyan interfészt figyel, amely semmit nem hordoz.
Tesztelje mindkét családot külön ezzel: curl -4 és curl -6, mert egy sikeres kérés semmit nem mond arról az útról, amelyet nem próbált ki. A port tulajdonjoga nem változik a családok között, de a hallgató igen: ss -lntup külön sorokban listázza az IPv4-es és IPv6-os socketeket, és 0.0.0.0:443 nem fedi le [::]:443 kivéve, ha a folyamat dual-stack socketet kért.
Az a szolgáltatás, amely az egyik családon válaszol, a másikon pedig elutasít, általában hallgatóprobléma, nem útvonalválasztási. Mielőtt késznek nyilvánítja a tervet, erősítse meg, hogy minden szerep saját címmel vagy porttal rendelkezik, a továbbítás be van kapcsolva és engedélyezett, és minden szerep a másik kettő állása mellett is válaszol.