Isang pampublikong host para sa VPN at web: paano hatiin ang mga tungkulin

Ang isang makina ay maaaring tumugon sa tatlong pangangailangan nang sabay: tapusin ang mga tunnel, sumagot sa HTTPS at magpasa sa pagitan ng dalawang pribadong LAN. Kung makatuwiran ito ay nakasalalay sa tatlong bagay na maaari mong pagpasyahan sa papel: kanino ang pampublikong address, kanino ang bawat pares ng port at protocol, at aling proseso ang pinapayagang magpasa ng mga packet. Kung tama ang mga ito, wala itong espesyal sa pinagsasaluhang host. Kung mali, gugugol ka ng katapusan ng linggo sa isang serbisyong nagsisimula nang malinis at hindi kailanman sumasagot.

Ang sumusunod ay isang pamamaraan ng pagpapasya, hindi isang dahon ng pagbuo. Ang bawat hakbang ay nagtatapos sa pagsusuring nagpapatunay na ang tungkuling idinagdag mo lang ay tunay na nakahiwalay.

Piliin ang may-ari ng address bago ang mga port

Ang dulo ng tunnel at isang web server ay maaaring magbahagi ng kernel; ang pagbabahagi ng isang address, port at protocol nang sabay ang nabibigo. Karaniwang kumukuha ang WireGuard ng UDP 51820, OpenVPN kumukuha ng UDP 1194 o TCP 443, at ang web server ay kumukuha ng TCP 443. Ang pares na masakit ay OpenVPN sa TCP 443 sa tabi ng HTTPS, dahil pareho silang gustong gamitin ang parehong socket at ibinibigay ito ng kernel sa naunang nagbind. Tanging isang demultiplexer sa harap, tulad ng sslh o isang proxy na marunong ng TLS, ang nagpapahintulot sa kanila na magbahagi ng port na iyon, at nagdaragdag ito ng sangkap na ang pagkasira ay eksaktong mukhang problema sa firewall.

Tingnan ang mga may-ari bago magbago ng anuman: ss -lntup ipinapakita ang lokal na address, port at proseso ng bawat socket na nakikinig. Ang dalawang hilera na nagpapakita ng 0.0.0.0:443 ay nangangahulugang hindi kailanman nagbind ang ikalawang serbisyo, gaano man kasaya ang script nitong init. Inililipat din ng bridging ang may-ari. Kapag ang eth0 ay sumali sa br0, lumilipat ang IP sa br0 at bawat tuntunin ng firewall na nagbabanggit ng eth0 ay tumitigil sa pagtutugma, kaya i-bind ang mga serbisyo sa tulay at kumpirmahin gamit ang ip -br addr.

Ipinapaliwanag ng parehong tuntunin ng pagmamay-ari ang sorpresang lumilitaw sa mga virtual machine. Ang isang tunnel server na tumatakbo sa loob ng bisita sa parehong LAN ay nagpapanatili ng address ng bisita, kaya ang mga koneksyong naka-target sa address ng host mismo ay nananatili sa host at hindi kailanman nakikita ng tunnel ng bisita, anuman ang sabihin ng profile ng kliyente.

Mag-ruta sa pagitan ng dalawang LAN o gawing NAT ang isang panig

Ang dalawang LAN na hindi nagkikita ay maaaring tumawag sa pampublikong host, na pagkatapos ay nagpapasa sa pagitan ng mga tunnel. Ang rutang disenyong iyon ay nangangailangan ng tatlong bagay: nakabukas ang pagpapasa, ruta patungo sa bawat malayong prefix at patakaran sa pagpapasa na nagpapadaan sa transit. sysctl -w net.ipv4.ip_forward=1 saklaw nito ang una, ip route add 10.20.0.0/24 dev wg1 ang pangalawa, at isang linyang nftables tulad ng nft add rule inet filter forward iifname "wg0" oifname "wg1" accept ang pangatlo.

Ang source NAT ay mas madaling idagdag at mas mahirap i-debug. Ang masquerading ay nagsusulat muli ng address ng kliyente, kaya nakikita ng malayong panig ang hub sa halip na ang tunay na host, at ang mga tuntunin nito sa pag-access at mga log ay hindi na kapaki-pakinabang para sa attribution. Kapag parehong network mo, mag-ruta. Kapag ang isang panig ay pagmamay-ari ng ikatlong partido na hindi magdaragdag ng return route, ang NAT ang opsyong lumalabas ngayong linggo. Sa anumang kaso, isulat ang plano ng address, dahil ang dalawang magkapatong na /24 ay hindi maaaring iruta ng anumang configuration.

Walang anuman sa pagiging internet exit para sa isang laptop ang pumipigil sa parehong kahon na tapusin ang mga papasok na tunnel. Ang mga magkapatong na address lamang ang pumipigil, at iyon ang dahilan kung bakit ang plano ng address ang dokumentong mahalaga.

Subukan ang paghahati habang dalawang tungkulin ang nakatigil

Ang kapaki-pakinabang na pagsubok ay subtraction: ihinto ang dalawang tungkulin at kumpirmahin na sumasagot pa rin ang pangatlo. Dapat matapos ang web request habang patay ang serbisyo ng tunnel, at dapat matapos ang handshake ng tunnel habang nakatigil ang web server. Kung pareho lamang gumagana kapag tumatakbo ang lahat, mayroon kang aksidenteng dependency, tulad ng pinagsasaluhang talahanayan ng firewall, naligaw na ruta o pangalang tumuturo sa maling address.

Ginagawang kongkreto ng tatlong utos ang pagsubok na iyon. curl -sk --resolve example.test:443:203.0.113.10 https://example.test/ pinatutunayan na sumasagot ang lokal na tagapakinig nang walang external DNS, wg show sa kliyente pinatutunayan na natapos ang handshake, at tcpdump -ni any port 51820 sa hub inihihiwalay ang problema sa routing mula sa problema sa key. Ang handshake na hindi kailanman lumilitaw sa capture ay namatay bago ang host: firewall ng provider, maling pampublikong address o tuntunin ng NAT sa daan.

Ulitin ang subtraction para sa mga LAN na ipinapasa. Kapag isang peer ang nadiskonekta, dapat mabigo ang ping sa hub; kapag nakakonekta muli, dapat gumaling ang ping nang hindi hinahawakan ang isang tuntunin. Ang ping na gumagaling lamang pagkatapos i-restart ang tunnel ay tumuturo sa patakaran at hindi sa maabot, at iyon ay ibang pagwawasto.

Panatilihing nababasa ang set ng tuntunin habang binabawasan mo ang mga tungkulin. nft list ruleset dapat magpakita ng isang tuntunin sa pagtanggap bawat direksyong talagang kailangan mo, at ang kadena ng pagpapasa na tumatanggap ng lahat ay hindi paghihiwalay, ito ay gumaganang demo.

Mga linya ng pag-access na IPv6 lamang at mga serbisyong IPv4

Ang ilang linya ng pag-access ay nagbibigay lamang ng maabot na IPv6, at ang mga serbisyo ay dapat pa ring ilathala sa IPv4. Ang tunnel mismo ay dumadaan sa pamilyang nagpapadaan pa ng trapiko, habang ang inilathalang serbisyo ay nakaupo sa isang address sa loob ng tunnel. Binabaligtad nito ang karaniwang palagay at tahimik na sinisira ang pagsubaybay: ang tuntunin ng firewall o pagsusuri ng uptime na isinulat para sa landas na IPv4 ay nanonood na ngayon ng interface na walang dalang anuman.

Subukan ang bawat pamilya nang hiwalay gamit ang curl -4 at curl -6, dahil ang isang matagumpay na request ay walang sinasabi tungkol sa landas na hindi mo sinubukan. Ang pagmamay-ari ng port ay hindi nagbabago sa pagitan ng mga pamilya, ngunit ang tagapakinig ay nagbabago: ss -lntup inililista ang mga socket ng IPv4 at IPv6 sa magkahiwalay na hilera, at 0.0.0.0:443 hindi sinasaklaw ang [::]:443 maliban kung humiling ang proseso ng dual-stack socket.

Ang serbisyong sumasagot sa isang pamilya at tumatanggi sa isa pa ay karaniwang problema ng tagapakinig, hindi ng routing. Bago mo ideklarang tapos ang disenyo, kumpirmahin na ang bawat tungkulin ay may sariling address o port, nakabukas at pinapayagan ang pagpapasa, at sumasagot pa rin ang bawat tungkulin habang nakatigil ang dalawa.