Reglar som videresendar alle portar kan sluke WireGuard-lyttaren din

Ein offentleg gateway køyrer alt WireGuard på UDP 51820, SSH på 22 og éin applikasjon som må vere tilgjengeleg frå internett. Den freistande regelen videresendar kvar port til peeren og seier saka er ferdig. På ein WireGuard-gateway kan ein slik regel fange transporten til tunnelen sjølv og låse deg ute frå maskinen som terminerer han. Publisering er eit rutingsval med eit unntak for kontrollplanet, ikkje éi einaste DNAT-linje.

Offentleg inngang eller tunnelinngang: vel éin

Å publisere ein teneste skaper eit nytt inngangspunkt mot internett. Det er ikkje det same som å gje ein peer VPN-medlemskap, fordi den besøkjande aldri blir med i tunnelen, og gatewayen blir det offentlege andletet til backenden. Den skilnaden avgjer publikumet til regelen og sertifikatet han treng.

Administrative grensesnitt høyrer sjeldan heime på den plassen. Ei admin-side som autoriserte VPN-klientar når, held åtaksflata inne i tunnelen og unngår å eksponere eit innloggingsskjema for vilkårleg skanning. Offentlege applikasjonsendepunkt treng framleis sitt eige TLS-sertifikat, autentisering og fartsavgrensing; det krypterte WireGuard-steget vernar ikkje delen til den besøkjande fram til gatewayen.

Viss tenesta verkeleg må vere offentleg, skriv ned vertsnamnet, sertifikatet som dekkjer det og dei besøkjande områda som skal nå det. Dei tre fakta avgjer forma på regelen og filterpolitikken seinare. Alt utanfor dei er auke i omfang på ein offentleg lyttar.

Éin port inn, éin backend ut

Bruk éin offentleg port og éin backend-teneste. I dette dømet ber eth0 den offentlege adressa 198.51.100.20, tunneladressa til gatewayen er 10.200.0.1, og peeren køyrer applikasjonen på 10.200.0.7. Offentleg TCP 9443 blir mappa til TCP 8443 hos peeren:

iptables -t nat -A PREROUTING -i eth0 -d 198.51.100.20 -p tcp --dport 9443 -j DNAT --to-destination 10.200.0.7:8443
iptables -t nat -A POSTROUTING -o wg0 -d 10.200.0.7 -p tcp --dport 8443 -m conntrack --ctorigdst 198.51.100.20 --ctorigdstport 9443 -j SNAT --to-source 10.200.0.1

SNAT-regelen passar med den omsette backenden og den opphavlege offentlege destinasjonen, slik at ei anna tilkopling til den same backend-tenesta held seg utanfor denne mappinga. Han skjuler òg adressa til den besøkjande for peeren, og det er byttet som gjer ein rutelagd returveg som tek vare på kjelda til eit eige design. Referansen for iptables-utvidingar dokumenterer begge måla og matchingsvala deira.

Videresending må framleis slåast på, og filterkjeda treng ei tillating for den omsette destinasjonen og porten pluss etablerte svar. FORWARD-kjeda ser den omsette destinasjonen etter DNAT, så ein regel skriven mot den offentlege adressa passar ikkje på den videresende pakken. Skriv tillatinga mot backend-tupelen, ikkje den offentlege.

Peeren må ta imot tenestetilkoplinga frå tunneladressa til gatewayen og sende svaret tilbake gjennom tunnelen. AllowedIPs hans må autorisere den kjelda han faktisk får, som under kjeldeomsetjing er tunneladressa til gatewayen, og ei brei 0.0.0.0/0-oppføring på kvar peer er ikkje naudsynt for dette designet. Det som feller returtrafikken er ein peer som listar bort den adressa, eller eit design som tek vare på kjelda og sender adressa til den besøkjande i staden, så sjekk kjelda peeren verkeleg ser og ikkje den i regelen din.

Hald lyttarane til gatewayen sjølv utanfor regelen

Omsetjing av destinasjon skjer før maskinen avgjer at ein pakke er lokal, så UDP 51820 kan hamne hos peeren i staden for hos prosessen som held kvar peertilkopling. Regelen lastar utan feil og tunnelen døyr, noko som er ein vanskeleg feil å lese frå peeren si side.

SSH, overvakingsagentar og kvar annan teneste på gatewayen har same eksponering. Ein regel som sender alt vidare skil ikkje kontrollplanet frå den publiserte applikasjonen, og den første omstarten etter endringa er då utelukkinga blir openber. Regelen som dekkjer alt varslar ikkje om tenesta han stille tek over. Du oppdagar det når den neste tilkoplinga feilar.

Viss brei videresending verkeleg er naudsynt, reserver kontrollportane før regelen som dekkjer alt, eller bruk ei eiga offentleg adresse for publisering. Det andre valet er reinare fordi kontrolladressa held sin eigen politikk, men tilbydaren må levere den adressa; å leggje til ein DNS-record tildeler ingen.

Brei TCP- og UDP-videresending er heller ikkje alle protokollar. ICMP, IPv6, MTU-tilbakemelding på vegen og den ytre VPN-transporten treng sin eigen politikk, og ein regel som dekkjer TCP og UDP lèt dei tilfella liggje til standardkjeda.

Vel modellen før du skriv reglar

Fire former dekkjer dei fleste gateway-publiseringane, og valet avheng av kor mange tenester du køyrer og kor mykje risiko i kontrollplanet du toler. Tabellen nedanfor ordnar dei frå den smalaste til den breiaste.

Start med den smale modellen sjølv om du ventar fleire tenester seinare. Han er enklast å revidere, og å gjere om eit sett smale reglar til ein gjennomgått regel som dekkjer alt, er enklare enn å finne ut kva lyttar ein brei regel fanga. Kva modell du enn vel, hald reglane hos eigaren av brannmuren. Å leggje iptables-linjer ved sida av ein UFW- eller nftables-konfigurasjon som òg styrer dei same kjedene, gjev ein politikk som endrar seg etter oppstartsrekkjefølgja.

Prov både publiseringa og kontrollvegen

Test frå ein autorisert ekstern klient med det godkjende vertsnamnet og eit sertifikat som er gyldig for det. Stadfest kva backend som svara, og sjekk så at urelaterte offentlege portar framleis blir avviste. Ein deaktivert sertifikatkontroll er ikkje ein bestått HTTPS-test, og ei tilkopling som når feil backend er verre enn ei som feilar.

Etterpå skal du stadfeste gatewayen sjølv: kople til ein WireGuard-peer, opne ein SSH-sesjon og stadfest at overvakinga framleis rapporterer. Den publiserte tenesta kan fungere medan kontrollplanet er brote, så begge kontrollane høyrer heime i same endringsvindauge. Start om éin gong for å prove at reglane blir lagde på nytt i venta rekkjefølgje, fjern så publiseringa og stadfest at fjerninga verkeleg svarar til tillegginga. Mange tillegg ved oppstart med ufullstendig opprydding er korleis ein mellombels test blir ei varig opning.