Éin offentleg vert for VPN og nett: korleis dele rollene

Éin maskin kan dekkje alle tre behova samstundes: avslutte tunnelar, svare på HTTPS og videresende mellom to private nett. Om det er fornuftig kjem an på tre ting du kan avgjere på papiret: kven som eig den offentlege adressa, kven som eig kvart port- og protokollpar, og kva prosess som har løyve til å videresende pakkar. Får du desse rett, er den delte verten ikkje noko spesielt. Får du dei gale, brukar du ei helg på ei teneste som startar reint og aldri svarar.

Det som følgjer er ein avgjerdsprosedyre, ikkje eit byggjeark. Kvart steg endar med kontrollen som beviser at rolla du nettopp la til faktisk er isolert.

Vel eigaren av adressa før portane

Eit tunnelendepunkt og ein nettenar kan dele ein kjerne; å dele éi adresse, port og protokoll samstundes er det som feilar. WireGuard tek vanlegvis UDP 51820, OpenVPN tek UDP 1194 eller TCP 443, og ein nettenar tek TCP 443. Paret som svir er OpenVPN over TCP 443 ved sida av HTTPS, fordi begge vil ha same socket og kjernen gjev han til den som batt seg først. Berre ein demultipleksar framfor, som sslh eller ein TLS-medviten proxy, lèt dei dele den porten, og han legg til ein komponent der feilen ser nøyaktig ut som eit brannmurproblem.

Sjå på eigarane før du endrar noko: ss -lntup skriv ut lokal adresse, port og prosess for kvar lyttande socket. To rader som viser 0.0.0.0:443 tyder at den andre tenesta aldri batt seg, uansett kor blid init-skriptet var. Broing flyttar òg eigaren. Når eth0 blir med i br0, flyttar IP-en til br0 og kvar brannmurregel som nemner eth0 sluttar å stemme, så bind tenestene på brua og stadfest med ip -br addr.

Den same eigarregelen forklarer ei overrasking som dukkar opp med virtuelle maskinar. Ein tunnelserver som køyrer inne i ein gjest på same nett held på adressa til gjesten, så tilkoplingar retta mot verten si eiga adresse blir verande på verten og tunnelen til gjesten ser dei aldri, uansett kva klientprofilen seier.

Rut mellom dei to netta eller NAT éi side

To nett som ikkje ser kvarandre kan kvar ringje den offentlege verten, som deretter videresender mellom tunnelane. Det ruta designet treng tre ting på plass: videresending slått på, ei rute mot kvart eksterne prefiks og ein videresendingspolitikk som slepp transitten gjennom. sysctl -w net.ipv4.ip_forward=1 dekkjer det første, ip route add 10.20.0.0/24 dev wg1 det andre, og ei nftables-linje som nft add rule inet filter forward iifname "wg0" oifname "wg1" accept det tredje.

Kjelde-NAT er lettare å leggje til og vanskelegare å feilsøkje. Maskering skriv om klientadressa, så den fjerne sida ser huben i staden for den eigentlege verten, og tilgangsreglane og loggane sluttar å vere nyttige for attribusjon. Når begge netta er dine, rut. Når éi side høyrer til ein tredjepart som ikkje legg til ei returrute, er NAT alternativet som går ut denne veka. Uansett, skriv ned adresseplanen, fordi to overlappande /24 kan ikkje rutast av noko mengd konfigurasjon.

Ingenting ved å vere internettutgang for ein berbar PC hindrar den same boksen i å avslutte innkomande tunnelar. Berre overlappande adresser gjer det, og difor er adresseplanen dokumentet som betyr noko.

Test delinga medan to roller er stoppa

Den nyttige testen er subtraksjon: stopp to roller og stadfest at den tredje framleis svarar. Ei nettførespurnad bør fullførast med tunnelfenesta nede, og eit tunnelhandtrykk bør fullførast med nettenaren stoppa. Viss begge berre verkar når alt køyrer, har du ein tilfeldig avhengigheit, som ein delt brannmurtabell, ei vill rute eller eit namn som peikar på feil adresse.

Tre kommandoar gjer den testen konkret. curl -sk --resolve example.test:443:203.0.113.10 https://example.test/ beviser at den lokale lyttaren svarar utan ekstern DNS, wg show på klienten beviser at handtrykket er fullført, og tcpdump -ni any port 51820 på huben skil eit rutingsproblem frå eit nøkkelproblem. Eit handtrykk som aldri dukkar opp i opptaket døydde før verten: brannmuren til leverandøren, feil offentleg adresse eller ein NAT-regel undervegs.

Gjenta subtraksjonen for netta som blir videresende. Med éin peer fråkopla skal ein ping over huben feile; når han er tilkopla igjen, skal pinget kome tilbake utan å røre ein regel. Eit ping som berre kjem tilbake etter omstart av tunnelen peikar på politikk og ikkje på tilgjenge, og det er ei anna retting.

Hald regelsettet lesbart medan du trekkjer frå roller. nft list ruleset bør vise éin tillètingsregel per retning du faktisk treng, og ei videresendingskjede som tillèt alt er ikkje separasjon, det er ein fungerande demo.

Berre IPv6-tilgangslinjer og IPv4-tenester

Nokre tilgangslinjer gjev berre IPv6-tilgjenge, og tenester må framleis publiserast over IPv4. Sjølve tunnelen går over familien som framleis slepp trafikk gjennom, medan den publiserte tenesta sit på ei adresse inne i tunnelen. Det snur den vanlege føresetnaden og bryt overvakinga stille: ein brannmurregel eller oppetidskontroll skriven for IPv4-vegen overvakar no eit grensesnitt som ikkje ber noko.

Test kvar familie for seg med curl -4 og curl -6, fordi éin vellukka førespurnad ikkje seier noko om vegen du ikkje prøvde. Porteige endrar seg ikkje mellom familiar, men lyttaren gjer det: ss -lntup listar IPv4- og IPv6-soklar på separate rader, og 0.0.0.0:443 dekkjer ikkje [::]:443 med mindre prosessen bad om ein dual-stack-socket.

Ei teneste som svarar på éin familie og nektar på den andre er vanlegvis eit lyttarproblem, ikkje eit rutingsproblem. Før du kallar designet ferdig, stadfest at kvar rolle eig si eiga adresse eller port, at videresending er slått på og tillaten, og at kvar rolle framleis svarar med dei to andre stoppa.