Een openbare gasheer vir VPN en web: hoe om die rolle te skei

Een masjien kan al drie behoeftes gelyktydig bevredig: tonnels beëindig, HTTPS beantwoord en tussen twee private LAN's deurstuur. Of dit sinvol is, hang van drie dinge af wat jy op papier kan bepaal: wie die openbare adres besit, wie elke poort-en-protokolpaar besit, en watter proses pakkette mag deurstuur. Kry dit reg en die gedeelde gasheer is niks besonders nie. Kry dit verkeerd en jy sal 'n naweek spandeer aan 'n diens wat skoon begin en nooit antwoord nie.

Wat volg is 'n besluitprosedure, nie 'n bouplan nie. Elke stap eindig met die kontrole wat bewys die rol wat jy pas bygevoeg het, is werklik geïsoleer.

Kies die eienaar van die adres voor die poorte

'n Tonnel-eindpunt en 'n webbediener kan 'n kernel deel; dieselfde adres, poort en protokol gelyktydig deel, is wat misluk. WireGuard neem gewoonlik UDP 51820, OpenVPN neem UDP 1194 of TCP 443, en 'n webbediener neem TCP 443. Die paar wat seermaak, is OpenVPN oor TCP 443 langs HTTPS, want albei wil dieselfde sokkel hê en die kernel gee dit aan wie eerste bind. Net 'n demultiplekser vooraan, soos sslh of 'n TLS-bewuste instaanbediener, laat hulle daardie poort deel, en dit voeg 'n komponent by wie se fout presies soos 'n vuurmuurprobleem lyk.

Kyk na die eienaars voordat jy enigiets verander: ss -lntup wys die plaaslike adres, poort en proses vir elke luisterende sokkel. Twee rye wat 0.0.0.0:443 wys, beteken die tweede diens het nooit gebind nie, hoe opgewek sy inisiasieskrip ook al was. Oorbrugging verskuif ook die eienaar. Wanneer eth0 by br0 aansluit, skuif die IP na br0 en elke vuurmuurreël wat eth0 noem, hou op pas, so bind dienste op die brug en bevestig met ip -br addr.

Dieselfde eienaarskapreël verduidelik 'n verrassing wat by virtuele masjiene opduik. 'n Tonnelbediener wat in 'n gas op dieselfde LAN loop, behou die gas se adres, so verbindings na die gasheer se eie adres bly op die gasheer en die gas se tonnel sien hulle nooit, wat die kliëntprofiel ook al voorstel.

Roeteer tussen die twee LAN's of NAT een kant

Twee LAN's wat mekaar nie kan sien nie, kan elkeen die openbare gasheer skakel, wat dan tussen die tonnels deurstuur. Daardie gerouteerde ontwerp het drie dinge nodig: deurstuur aangeskakel, 'n roete na elke afgeleë voorvoegsel, en 'n deurstuurbeleid wat die deurgang toelaat. sysctl -w net.ipv4.ip_forward=1 dek die eerste, ip route add 10.20.0.0/24 dev wg1 die tweede, en 'n nftables-reël soos nft add rule inet filter forward iifname "wg0" oifname "wg1" accept die derde.

Bron-NAT is makliker om by te las en moeiliker om te ontfout. Maskering herskryf die kliëntadres, so die ander kant sien die hub eerder as die werklike gasheer, en sy toegangsreëls en logs hou op om nuttig te wees vir toeskrywing. Wanneer albei netwerke joune is, roeteer. Wanneer een kant aan 'n derde party behoort wat nie 'n terugroete gaan byvoeg nie, is NAT die opsie wat hierdie week kan vertrek. Skryf die adresplan neer, want twee oorvleuelende /24's kan nie met enige hoeveelheid konfigurasie gerouteer word nie.

Niks daaraan om as internet-uitgang vir 'n skootrekenaar te dien, verhoed dieselfde boks om inkomende tonnels te beëindig nie. Net oorvleuelende adresse doen dit, en daarom is die adresplan die dokument wat saak maak.

Toets die splitsing terwyl twee rolle gestop is

Die nuttige toets is aftrekking: stop twee rolle en bevestig die derde antwoord steeds. 'n Webversoek moet voltooi met die tonneldiens af, en 'n tonnelhanddruk moet voltooi met die webbediener gestop. As albei net werk wanneer alles loop, het jy 'n toevallige afhanklikheid, soos 'n gedeelde vuurmuurtabel, 'n verdwaalde roete of 'n naam wat na die verkeerde adres wys.

Drie opdragte maak daardie toets konkreet. curl -sk --resolve example.test:443:203.0.113.10 https://example.test/ bewys die plaaslike luisteraar antwoord sonder eksterne DNS, wg show op die kliënt bewys die handdruk is voltooi, en tcpdump -ni any port 51820 op die hub skei 'n roeteprobleem van 'n sleutelprobleem. 'n Handdruk wat nooit in die opname verskyn nie, het voor die gasheer gesterf: verskaffer-vuurmuur, verkeerde openbare adres of 'n NAT-reël op die pad.

Herhaal die aftrekking vir die deurgestuurde LAN's. Met een eweknie ontkoppel, behoort 'n ping oor die hub te misluk; met dit weer gekoppel, behoort die ping te herstel sonder om 'n reël te raak. 'n Ping wat eers ná die herbegin van die tonnel herstel, wys na beleid eerder as bereikbaarheid, en dit is 'n ander regstelling.

Hou die reëlversameling leesbaar terwyl jy rolle aftrek. nft list ruleset behoort een aanvaardingsreël per rigting te wys wat jy werklik nodig het, en 'n deurstuurkring wat alles aanvaar, is nie skeiding nie, dit is 'n werkende demo.

Toegangslyne met net IPv6 en IPv4-dienste

Sommige toegangslyne gee net IPv6-bereikbaarheid, en dienste moet steeds oor IPv4 gepubliseer word. Die tonnel self reis oor watter familie ook al nog verkeer deurlaat, terwyl die gepubliseerde diens op 'n adres binne die tonnel sit. Dit keer die gewone aanname om en breek monitering stilweg: 'n vuurmuurreël of uptime-kontrole wat vir die IPv4-pad geskryf is, hou nou 'n koppelvlak dop wat niks dra nie.

Toets elke familie op sy eie met curl -4 en curl -6, want een suksesvolle versoek sê niks oor die pad wat jy nie probeer het nie. Poorteienaarskap verander nie tussen families nie, maar die luisteraar wel: ss -lntup wys IPv4- en IPv6-sokkel as aparte rye, en 0.0.0.0:443 dek nie [::]:443 tensy die proses 'n dubbelstapel-sokkel gevra het.

'n Diens wat op een familie antwoord en op die ander weier, is gewoonlik 'n luisteraarprobleem, nie 'n roeteprobleem nie. Voordat jy die ontwerp as klaar beskou, bevestig dat elke rol sy eie adres of poort besit, dat deurstuur aangeskakel en toegelaat is, en dat elke rol steeds antwoord met die ander twee gestop.