Regler som vidarebefordrar alla portar kan sluka din WireGuard-lyssnare
En bred vidarebefordringsregel kan sluka gatewayens egna WireGuard- och SSH-lyssnare. Välj smala regler eller en separat publik adress och testa sedan kontrollvägen.
En publik gateway kör redan WireGuard på UDP 51820, SSH på 22 och en applikation som måste nås från internet. Den frestande regeln vidarebefordrar varje port till peeren och förklarar saken klar. På en WireGuard-gateway kan en sådan regel fånga tunnelns egen transport och låsa dig ute från maskinen som avslutar den. Publicering är ett routingbeslut med ett undantag för kontrollplanet, inte en enda DNAT-rad.
Publik ingång eller tunnelingång: välj en
Att publicera en tjänst skapar en ny ingång på internet. Det är inte samma sak som att ge en peer VPN-medlemskap, eftersom besökaren aldrig går in i tunneln och gatewayen blir backendens publika ansikte. Den skillnaden avgör regelns publik och dess certifikat.
Administrativa gränssnitt hör sällan hemma där. En admin-sida som nås av auktoriserade VPN-klienter håller attackytan inne i tunneln och undviker att exponera ett inloggningsformulär för godtycklig skanning. Publika applikationsändpunkter behöver fortfarande sitt eget TLS-certifikat, autentisering och hastighetsbegränsning; det krypterade WireGuard-hoppet skyddar inte besökarens del fram till gatewayen.
Om tjänsten verkligen måste vara publik, skriv ned värdnamnet, certifikatet som täcker det och de besöksintervall som ska nå det. De tre fakta bestämmer regelns form och filterpolicyn senare. Allt utanför dem är omfångsökning på en publik lyssnare.
En port in, en backend ut
Använd en enda publik port och en enda backendtjänst. I det här exemplet bär eth0 den publika adressen 198.51.100.20, gatewayens tunneladress är 10.200.0.1 och peeren kör applikationen på 10.200.0.7. Publik TCP 9443 mappas till 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.1SNAT-regeln matchar den översatta backenden och den ursprungliga publika destinationen, så en annan anslutning till samma backendtjänst stannar utanför den här mappningen. Den döljer också besökarens adress för peeren, och det är avvägningen som gör en källbevarande routad returväg till en egen design. Referensen för iptables-tillägg dokumenterar båda målen och deras matchningsalternativ.
Vidarebefordran måste fortfarande vara påslagen, och filterkedjan behöver ett tillstånd för den översatta destinationen och porten plus upprättade svar. FORWARD-kedjan ser den översatta destinationen efter DNAT, så en regel skriven mot den publika adressen matchar inte det vidarebefordrade paketet. Skriv tillståndet mot backend-tupeln, inte mot den publika.
Peeren måste acceptera tjänsteanslutningen från gatewayens tunneladress och skicka svaret tillbaka genom tunneln. Dess AllowedIPs måste auktorisera den källa den faktiskt tar emot, vilket vid källöversättning är gatewayens tunneladress, och en bred 0.0.0.0/0-post på varje peer behövs inte för den här designen. Det som tappar returtrafiken är en peer vars lista utelämnar den adressen, eller en källbevarande design som i stället vidarebefordrar besökarens egen adress, så kontrollera den källa peeren verkligen ser, inte den i din regel.
Håll gatewayens egna lyssnare utanför regeln
Byt portmatchen mot en regel som täcker varje TCP- och UDP-destination, och gatewayens egen WireGuard-socket faller inom den. Destinationsöversättning sker innan maskinen avgör att ett paket är lokalt, så UDP 51820 kan hamna hos peeren i stället för hos processen som håller varje peeranslutning. Regeln laddas utan fel och tunneln dör, ett fel som är svårt att läsa från peersidan.
SSH, övervakningsagenter och varje annan tjänst som körs på gatewayen har samma exponering. En regel som vidarebefordrar allt skiljer inte kontrollplanet från den publicerade applikationen, och den första omstarten efter ändringen är när utelåsningen blir uppenbar. Regeln som fångar allt varnar inte för tjänsten den tyst tar över. Du upptäcker det när nästa anslutning misslyckas.
Om bred vidarebefordran verkligen behövs, reservera kontrollportarna före regeln som fångar allt, eller använd en separat publik adress för publicering. Det andra alternativet är renare eftersom kontrolladressen behåller sin egen policy, men leverantören måste leverera den adressen; en extra DNS-post tilldelar ingen.
Bred TCP- och UDP-vidarebefordran är inte heller alla protokoll. ICMP, IPv6, path-MTU-återkoppling och den yttre VPN-transporten behöver sin egen policy, och en regel som täcker TCP och UDP lämnar de fallen till standardkedjan.
Välj modell innan du skriver regler
Fyra former täcker de flesta publiceringar från en gateway, och valet beror på hur många tjänster du kör och hur mycket risk i kontrollplanet du tål. Tabellen nedan ordnar dem från den smalaste till den bredaste.
| Model | What it protects | Cost | Use when |
|---|---|---|---|
| Narrow port forward | Every other listener, including the VPN | One rule per service | Few services, stable ports |
| Catch-all with reserved ports | Ports named in the exception list | Rule order becomes critical | Many services and disciplined review |
| Separate public address | Control address fully isolated | Provider must supply the address | High-value publication |
| VPN-only access | No public entry at all | Visitors need the tunnel | Admin interfaces and internal tools |
Börja med den smala modellen även om du väntar fler tjänster senare. Den är enklast att granska, och att göra om en uppsättning smala regler till en granskad regel som fångar allt är enklare än att upptäcka vilken lyssnare en bred regel fångade. Vilken modell du än väljer, håll reglerna hos den som äger brandväggen. Att lägga iptables-rader bredvid en UFW- eller nftables-konfiguration som också hanterar samma kedjor ger en policy som ändras beroende på startordningen.
Bevisa både publiceringen och kontrollvägen
Testa från en auktoriserad extern klient med det godkända värdnamnet och ett certifikat som är giltigt för det. Bekräfta vilken backend som svarade och kontrollera sedan att orelaterade publika portar fortfarande nekas. En avstängd certifikatkontroll är inte ett godkänt HTTPS-test, och en anslutning som når fel backend är värre än en som misslyckas.
Verifiera därefter gatewayen själv: anslut en WireGuard-peer, öppna en SSH-session och bekräfta att övervakningen fortfarande rapporterar. Den publicerade tjänsten kan fungera medan kontrollplanet är trasigt, så båda kontrollerna hör till samma ändringsfönster. Starta om en gång för att bevisa att reglerna tillämpas igen i förväntad ordning, ta sedan bort publiceringen och bekräfta att borttagningen verkligen motsvarar tillägget. En stor uppsättning tillägg vid start med ofullständig städning är hur ett tillfälligt test blir en permanent öppning.