Videresendelse af alle porte kan sluge din WireGuard-lytter

En offentlig gateway kører allerede WireGuard på UDP 51820, SSH på 22 og én applikation, der skal kunne nås fra internettet. Den fristende regel videresender hver port til peeren og kalder det færdigt. På en WireGuard-gateway kan denne regel opsnappe tunnelens egen transport og låse dig ude af maskinen, der terminerer den. Udgivelse er en routingbeslutning med en undtagelse for kontrolplanet, ikke én DNAT-linje.

Offentlig indgang, tunnelindgang: vælg én

Udgivelse af en tjeneste skaber et nyt indgangspunkt til internettet. Det er ikke det samme som at give et peer VPN-medlemskab, fordi den besøgende aldrig slutter sig til tunnelen, og gatewayen bliver backendens offentlige ansigt. Den forskel afgør reglens publikum og dens certifikat.

Administrative grænseflader hører sjældent hjemme der. En adminside, som autoriserede VPN-klienter når, holder angrebsfladen inde i tunnelen og undgår at udsætte en loginformular for vilkårlig scanning. Offentlige applikationsendepunkter har stadig brug for deres eget TLS-certifikat, godkendelse og hastighedsbegrænsning; det krypterede WireGuard-hop beskytter ikke den besøgendes ben til gatewayen.

Hvis tjenesten virkelig skal være offentlig, så skriv værtsnavnet ned, certifikatet der dækker det, og de besøgsområder, der skal nå det. De tre kendsgerninger afgør senere reglens form og filterpolitikken. Alt uden for dem er udvidelse af omfanget på en offentlig lytter.

Én port ind, én backend ud

Brug én offentlig port og én backend-tjeneste. I dette eksempel bærer eth0 den offentlige adresse 198.51.100.20, gatewayens tunneladresse er 10.200.0.1, og peeren kører applikationen 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-reglen matcher den oversatte backend og den oprindelige offentlige destination, så en anden forbindelse til samme backend-tjeneste forbliver uden for denne mapping. Den skjuler også den besøgendes adresse for peeren, og det er afvejningen, der gør en kildbevarende rutet returvej til et separat design. Referenceværket for iptables-udvidelser dokumenterer begge mål og deres matchmuligheder.

Videresendelse skal stadig aktiveres, og filterkæden skal have tilladelse til den oversatte destination og port plus etablerede svar. FORWARD-kæden ser den oversatte destination efter DNAT, så en regel skrevet mod den offentlige adresse matcher ikke den videresendte pakke. Skriv tilladelsen mod backend-tuppelen, ikke den offentlige.

Peeren skal acceptere tjenesteforbindelsen fra gatewayens tunneladresse og sende svaret tilbage gennem tunnelen. Dens AllowedIPs skal autorisere den kilde, den faktisk modtager, hvilket under kildeoversættelse er gatewayens tunneladresse, og en bred 0.0.0.0/0-post på hver peer er ikke nødvendig for dette design. Det, der dropper returtrafikken, er en peer, hvis liste udelader den adresse, eller et kildbevarende design, der videresender den besøgendes egen adresse i stedet, så kontroller den kilde, peeren faktisk ser, ikke den i din regel.

Hold gatewayens egne lyttere ude af reglen

Erstat portmatchningen med en regel, der dækker hver TCP- og UDP-destination, og gatewayens egen WireGuard-socket falder ind under den. Destinationstranslation sker, før maskinen beslutter, at en pakke er lokal, så UDP 51820 kan ende hos peeren i stedet for hos den proces, der holder hver peer-forbindelse. Reglen indlæses med succes, og tunnelen dør, hvilket er en svær fejl at læse fra peersiden.

SSH, overvågningsagenter og enhver anden tjeneste, der hostes på gatewayen, har samme eksponering. En regel, der videresender alt, skelner ikke kontrolplanet fra den udgivne applikation, og den første genstart efter ændringen er, hvor låsen bliver tydelig. Catch-all-reglen advarer ikke om den tjeneste, den lydløst overtager. Du opdager det, når den næste forbindelse fejler.

Hvis bred videresendelse virkelig er nødvendig, så reserver kontrolportene før catch-all-reglen, eller brug en separat offentlig adresse til udgivelse. Den anden mulighed er renere, fordi kontroladressen beholder sin egen politik, men udbyderen skal levere den adresse; at tilføje en DNS-post tildeler ikke en.

Bred TCP- og UDP-videresendelse er heller ikke alle protokoller. ICMP, IPv6, MTU-feedback for stien og den ydre VPN-transport har brug for deres egen politik, og en regel, der dækker TCP og UDP, overlader de tilfælde til standardkæden.

Vælg modellen, før du skriver regler

Fire former dækker de fleste gateway-udgivelser, og valget afhænger af, hvor mange tjenester du kører, og hvor meget kontrolplanrisiko du kan tolerere. Tabellen nedenfor ordner dem fra den snævreste til den bredeste.

Start med den smalle model, selv om du forventer flere tjenester senere. Den er lettest at revidere, og at omdanne et sæt smalle regler til en gennemgået catch-all er enklere end at opdage, hvilken lytter en bred regel opsnappede. Uanset hvilken model du vælger, så hold reglerne hos firewall-ejeren. At anvende iptables-linjer ved siden af en UFW- eller nftables-konfiguration, der også styrer de samme kæder, giver en politik, der ændrer sig afhængigt af bootrækkefølgen.

Bevis både udgivelsen og kontrolstien

Test fra en autoriseret ekstern klient med det godkendte værtsnavn og et certifikat, der er gyldigt for det. Bekræft, hvilken backend der svarede, og kontroller derefter, at ikke-relaterede offentlige porte stadig afvises. En deaktiveret certifikatkontrol er ikke en bestået HTTPS-test, og en forbindelse, der når den forkerte backend, er værre end en mislykket.

Derefter skal du verificere gatewayen selv: tilslut en WireGuard-peer, åbn en SSH-session og bekræft, at overvågningen stadig rapporterer. Den udgivne tjeneste kan virke, mens kontrolplanet er brudt, så begge kontroller hører til i samme ændringsvindue. Genstart én gang for at bevise, at reglerne anvendes igen i den forventede rækkefølge, fjern derefter udgivelsen og bekræft, at fjernelsen faktisk matcher tilføjelsen. Et stort sæt tilføjelser ved opstart med ufuldstændig fjernelse er, hvordan en midlertidig test bliver en permanent åbning.