Regels die alle poorten doorsturen kunnen je WireGuard-listener opslokken

Een publieke gateway draait al WireGuard op UDP 51820, SSH op 22 en één applicatie die vanaf internet bereikbaar moet zijn. De verleidelijke regel stuurt elke poort naar de peer en verklaart de klus klaar. Op een WireGuard-gateway kan zo'n regel het transport van de tunnel zelf vangen en je buitensluiten van de machine die hem termineert. Publiceren is een routeringsbeslissing met een uitzondering voor het controlespoor, niet één DNAT-regel.

Publieke ingang of tunnelingang: kies er één

Een dienst publiceren maakt een nieuw toegangspunt op internet. Het is niet hetzelfde als een peer VPN-lidmaatschap geven, omdat de bezoeker nooit de tunnel in gaat en de gateway het publieke gezicht van de backend wordt. Dat onderscheid bepaalt het publiek van de regel en het certificaat ervan.

Beheerinterfaces horen daar zelden. Een beheerpagina die door geautoriseerde VPN-clients wordt bereikt, houdt het aanvalsoppervlak binnen de tunnel en voorkomt dat een loginformulier aan willekeurige scans wordt blootgesteld. Publieke applicatie-eindpunten hebben nog steeds hun eigen TLS-certificaat, authenticatie en snelheidsbegrenzing nodig; de versleutelde WireGuard-hop beschermt het stuk van de bezoeker naar de gateway niet.

Als de dienst echt publiek moet zijn, noteer dan de hostnaam, het certificaat dat hem dekt en de bezoekersbereiken die hem moeten bereiken. Die drie feiten bepalen later de vorm van de regel en het filterbeleid. Alles daarbuiten is een uitbreiding van de reikwijdte op een publieke listener.

Eén poort erin, één backend eruit

Gebruik één publieke poort en één backenddienst. In dit voorbeeld draagt eth0 het publieke adres 198.51.100.20, is het tunneladres van de gateway 10.200.0.1 en draait de peer de applicatie op 10.200.0.7. Publieke TCP 9443 wordt op TCP 8443 van de peer afgebeeld:

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

De SNAT-regel komt overeen met de vertaalde backend en de oorspronkelijke publieke bestemming, zodat een andere verbinding naar dezelfde backenddienst buiten deze afbeelding blijft. Hij verbergt ook het adres van de bezoeker voor de peer, en dat is de afweging waardoor een gerouteerde terugweg met behoud van bron een apart ontwerp is. De referentie voor iptables-extensies documenteert beide targets en hun matchopties.

Doorsturen moet nog steeds aan staan, en de filterketen heeft een toestemming nodig voor de vertaalde bestemming en poort plus gevestigde antwoorden. De FORWARD-keten ziet de vertaalde bestemming na DNAT, dus een regel tegen het publieke adres komt niet overeen met het doorgestuurde pakket. Schrijf de toestemming tegen de backend-tuple, niet tegen de publieke.

De peer moet de dienstverbinding vanaf het tunneladres van de gateway accepteren en het antwoord via de tunnel terugsturen. Zijn AllowedIPs moet de bron autoriseren die hij werkelijk ontvangt, wat onder bronvertaling het tunneladres van de gateway is, en een brede 0.0.0.0/0-vermelding op elke peer is voor dit ontwerp niet nodig. Wat het terugverkeer laat vallen is een peer wiens lijst dat adres weglaat, of een ontwerp met behoud van bron dat in plaats daarvan het adres van de bezoeker doorstuurt, dus controleer de bron die de peer echt ziet, niet die in je regel.

Houd de eigen listeners van de gateway buiten de regel

Vervang de poortmatch door een regel die elke TCP- en UDP-bestemming dekt, en de eigen WireGuard-socket van de gateway valt erbinnen. Bestemmingsvertaling gebeurt voordat de machine bepaalt dat een pakket lokaal is, dus UDP 51820 kan bij de peer belanden in plaats van bij het proces dat elke peerverbinding vasthoudt. De regel laadt zonder fout en de tunnel sterft, een storing die van de peer-kant moeilijk te lezen is.

SSH, monitoringagents en elke andere dienst op de gateway hebben dezelfde blootstelling. Een regel die alles doorstuurt onderscheidt het controlespoor niet van de gepubliceerde applicatie, en de eerste herstart na de wijziging is wanneer de buitensluiting duidelijk wordt. De regel die alles vangt waarschuwt niet voor de dienst die hij stil overneemt. Je ontdekt het wanneer de volgende verbinding faalt.

Als breed doorsturen echt nodig is, reserveer de controlepoorten dan vóór de regel die alles vangt, of gebruik een apart publiek adres voor publicatie. De tweede optie is schoner omdat het controleadres zijn eigen beleid houdt, maar de provider moet dat adres leveren; een DNS-record toevoegen wijst er geen toe.

Breed TCP- en UDP-doorsturen is ook niet alle protocollen. ICMP, IPv6, path-MTU-feedback en het buitenste VPN-transport hebben hun eigen beleid nodig, en een regel die TCP en UDP dekt laat die gevallen aan de standaardketen.

Kies het model voordat je regels schrijft

Vier vormen dekken de meeste publicaties vanaf een gateway, en de keuze hangt af van hoeveel diensten je draait en hoeveel risico in het controlespoor je kunt verdragen. De tabel hieronder rangschikt ze van smal naar breed.

Begin met het smalle model, ook als je later meer diensten verwacht. Het is het eenvoudigst te auditen, en een reeks smalle regels omzetten in een beoordeelde regel die alles vangt is eenvoudiger dan ontdekken welke listener een brede regel heeft gevangen. Welk model je ook kiest, houd de regels bij de eigenaar van de firewall. Iptables-regels toepassen naast een UFW- of nftables-configuratie die dezelfde ketens beheert, levert een beleid op dat afhangt van de opstartvolgorde.

Bewijs zowel de publicatie als het controlespoor

Test vanaf een geautoriseerde externe client met de goedgekeurde hostnaam en een daarvoor geldig certificaat. Bevestig welke backend antwoordde en controleer daarna dat niet-gerelateerde publieke poorten geweigerd blijven. Een uitgeschakelde certificaatcontrole is geen geslaagde HTTPS-test, en een verbinding die bij de verkeerde backend uitkomt is erger dan een mislukte.

Verifieer daarna de gateway zelf: verbind een WireGuard-peer, open een SSH-sessie en bevestig dat monitoring nog steeds rapporteert. De gepubliceerde dienst kan werken terwijl het controlespoor stuk is, dus beide controles horen in hetzelfde wijzigingsvenster. Herstart één keer om te bewijzen dat de regels in de verwachte volgorde opnieuw worden toegepast, verwijder daarna de publicatie en bevestig dat de verwijdering echt bij de toevoeging past. Een grote reeks toevoegingen bij het opstarten met een onvolledige opruiming is hoe een tijdelijke test een permanente opening wordt.