Regler som videresender alle porter, kan sluke WireGuard-lytteren din

En offentlig gateway kjører allerede WireGuard på UDP 51820, SSH på 22 og én applikasjon som må være tilgjengelig fra internett. Den fristende regelen videresender hver port til peeren og erklærer saken som ferdig. På en WireGuard-gateway kan en slik regel fange tunnels egen transport og låse deg ute fra maskinen som terminerer den. Publisering er en rutingbeslutning med et unntak for kontrollplanet, ikke én enkelt DNAT-linje.

Offentlig inngang eller tunnelinngang: velg én

Å publisere en tjeneste skaper et nytt inngangspunkt mot internett. Det er ikke det samme som å gi en peer VPN-medlemskap, fordi den besøkende aldri blir med i tunnelen, og gatewayen blir backendens offentlige ansikt. Den forskjellen avgjør regelens publikum og sertifikatet den trenger.

Administrative grensesnitt hører sjelden hjemme på den plassen. En admin-side som nås av autoriserte VPN-klienter, holder angrepsflaten inne i tunnelen og unngår å eksponere et påloggingsskjema for vilkårlig skanning. Offentlige applikasjonsendepunkter trenger fortsatt sitt eget TLS-sertifikat, autentisering og hastighetsbegrensning; det krypterte WireGuard-hoppet beskytter ikke den besøkendes del av veien fram til gatewayen.

Hvis tjenesten virkelig må være offentlig, skriv ned vertsnavnet, sertifikatet som dekker det, og hvilke besøksområder som skal nå det. De tre faktaene avgjør regelens form og filterpolitikken senere. Alt utenfor dem er omfangsøkning på en offentlig lytter.

Én port inn, én backend ut

Bruk én offentlig port og én backend-tjeneste. I dette eksempelet bærer eth0 den offentlige adressen 198.51.100.20, gatewayens tunneladresse er 10.200.0.1, og peeren kjører applikasjonen på 10.200.0.7. Offentlig TCP 9443 mappes til peerens TCP 8443:

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 matcher den oversatte backenden og den opprinnelige offentlige destinasjonen, så en annen tilkobling til samme backend-tjeneste holder seg utenfor denne mappingen. Den skjuler også den besøkendes adresse for peeren, og det er avveiningen som gjør en kildebevarende rutet returvei til et eget design. Referansen for iptables-utvidelser dokumenterer begge målene og deres matchvalg.

Videresending må fortsatt være slått på, og filterkjeden trenger en tillatelse for den oversatte destinasjonen og porten pluss etablerte svar. FORWARD-kjeden ser den oversatte destinasjonen etter DNAT, så en regel skrevet mot den offentlige adressen matcher ikke pakken som videresendes. Skriv tillatelsen mot backend-tuppelen, ikke mot den offentlige.

Peeren må godta tjenestetilkoblingen fra gatewayens tunneladresse og sende svaret tilbake gjennom tunnelen. AllowedIPs må autorisere kilden den faktisk mottar, som ved kildetranslasjon er gatewayens tunneladresse, og en bred 0.0.0.0/0-oppføring på hver peer er ikke nødvendig for dette designet. Det som dropper returtrafikken, er en peer hvis liste utelater den adressen, eller et kildebevarende design som i stedet videresender den besøkendes egen adresse, så sjekk kilden peeren virkelig ser, ikke den som står i regelen din.

Hold gatewayens egne lyttere utenfor regelen

Bytt portmatchen mot en regel som dekker hver TCP- og UDP-destinasjon, og gatewayens egen WireGuard-socket faller innenfor. Destinasjonstranslasjon skjer før maskinen avgjør at en pakke er lokal, så UDP 51820 kan ende hos peeren i stedet for hos prosessen som holder hver peer-tilkobling. Regelen lastes uten feil og tunnelen dør, og det er en vanskelig feil å lese fra peer-siden.

SSH, overvåkingsagenter og enhver annen tjeneste som kjøres på gatewayen, har samme eksponering. En regel som videresender alt, skiller ikke kontrollplanet fra den publiserte applikasjonen, og den første omstarten etter endringen er når utelåsingen blir åpenbar. Regelen som fanger alt, varsler ikke om tjenesten den stille overtar. Du oppdager det når neste tilkobling feiler.

Hvis bred videresending virkelig er nødvendig, reserver kontrollportene før regelen som fanger alt, eller bruk en egen offentlig adresse til publisering. Det andre alternativet er renere fordi kontrolladressen beholder sin egen policy, men leverandøren må levere den adressen; en ekstra DNS-oppføring tildeler ingen.

Bred TCP- og UDP-videresending er heller ikke alle protokoller. ICMP, IPv6, path-MTU-tilbakemelding og den ytre VPN-transporten trenger sin egen policy, og en regel som dekker TCP og UDP, overlater disse tilfellene til standardkjeden.

Velg modellen før du skriver regler

Fire former dekker de fleste publiseringer fra en gateway, og valget avhenger av hvor mange tjenester du kjører og hvor mye risiko i kontrollplanet du tåler. Tabellen nedenfor ordner dem fra den smaleste til den bredeste.

Start med den smale modellen selv om du forventer flere tjenester senere. Den er lettest å revidere, og å gjøre om et sett smale regler til en gjennomgått regel som fanger alt, er enklere enn å oppdage hvilken lytter en bred regel fanget. Uansett hvilken modell du velger, hold reglene hos den som eier brannmuren. Å legge iptables-linjer ved siden av en UFW- eller nftables-konfigurasjon som også styrer de samme kjedene, gir en policy som endrer seg avhengig av oppstartsrekkefølgen.

Bevis både publiseringen og kontrollveien

Test fra en autorisert ekstern klient med det godkjente vertsnavnet og et sertifikat som er gyldig for det. Bekreft hvilken backend som svarte, og kontroller deretter at urelaterte offentlige porter fortsatt er avvist. En deaktivert sertifikatkontroll er ikke en bestått HTTPS-test, og en tilkobling som når feil backend, er verre enn en som feiler.

Etterpå verifiserer du gatewayen selv: koble til en WireGuard-peer, åpne en SSH-økt og bekreft at overvåkingen fortsatt rapporterer. Den publiserte tjenesten kan fungere selv om kontrollplanet er ødelagt, så begge kontrollene hører hjemme i samme endringsvindu. Start én gang på nytt for å bevise at reglene brukes igjen i forventet rekkefølge, og fjern deretter publiseringen og bekreft at fjerningen faktisk samsvarer med tilføyelsen. Et stort sett med oppstartstilføyelser og ufullstendig opprydding er hvordan en midlertidig test blir en permanent åpning.