Alles-dekkende poortdoorstuur kan jou WireGuard-luisteraar insluk
’n Breë doorstuur-reël kan die gateway se eie WireGuard- en SSH-luisteraars insluk. Kies nou reëls of ’n aparte openbare adres, en toets dan die beheerpad.
’n Openbare gateway laat reeds WireGuard op UDP 51820, SSH op 22 en een toepassing wat van die internet af bereikbaar moet wees, loop. Die verleidelike reël stuur elke poort na die peer en noem dit klaar. Op ’n WireGuard-gateway kan daardie reël die tonnel se eie vervoer vasvang en jou uitsluit uit die masjien wat dit termineer. Publikasie is ’n roeteringsbesluit met ’n beheervlak-uitsondering, nie ’n enkele DNAT-reël nie.
Openbare toegang, tonneltoegang: kies een
Om ’n diens te publiseer skep ’n nuwe internet-toegangspunt. Dit is nie dieselfde as om VPN-lidmaatskap aan ’n peer te gee nie, want die besoeker sluit nooit by die tonnel aan nie en die gateway word die openbare gesig van die backend. Daardie onderskeid bepaal die reël se teikengehoor en sy sertifikaat.
Administratiewe koppelvlakke hoort selde op daardie plek. ’n Admin-bladsy wat deur gemagtigde VPN-kliënte bereik word, hou sy aanvalsoppervlak binne die tonnel en vermy dit om ’n aanmeldvorm aan arbitrêre skandering bloot te stel. Openbare toepassing-eindpunte het steeds hul eie TLS-sertifikaat, verifikasiemeganisme en tempo-beperking nodig; die geënkripteerde WireGuard-sprong beskerm nie die besoeker se been na die gateway nie.
As die diens werklik openbaar moet wees, skryf die gasheernaam neer, die sertifikaat wat dit dek en die besoekerreekse wat dit moet bereik. Daardie drie feite bepaal later die vorm van die reël en die filterbeleid. Enigiets buite hulle is omvangverruiming op ’n openbare luisteraar.
Een poort in, een backend uit
Gebruik een enkele openbare poort en een backend-diens. In hierdie voorbeeld dra eth0 die openbare adres 198.51.100.20, is die gateway se tonneladres 10.200.0.1, en laat die peer die toepassing op 10.200.0.7 loop. Openbare TCP 9443 word na die peer se TCP 8443 gekarteer:
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.1Die SNAT-reël pas by die vertaalde backend en die oorspronklike openbare bestemming, so bly ’n ander verbinding na dieselfde backend-diens buite hierdie kartering. Dit verberg ook die besoeker se adres vir die peer, en dit is die afweging wat ’n bronbehoudende gerouteerde terugkeer ’n aparte ontwerp maak. Die verwysing na iptables-uitbreidings dokumenteer albei teikens en hul bypassende opsies.
Doorstuur moet steeds geaktiveer word, en die filterketting het ’n toelating nodig vir die vertaalde bestemming en poort plus gevestigde antwoorde. Die FORWARD-ketting sien die vertaalde bestemming ná DNAT, so ’n reël wat teen die openbare adres geskryf is, pas nie by die doorgestuurde pakket nie. Skryf die toelating teen die backend-tupel, nie die openbare een nie.
Die peer moet die diensverbinding van die gateway se tonneladres aanvaar en die antwoord deur die tonnel terugstuur. Sy AllowedIPs moet die bron magtig wat hy werklik ontvang, wat onder brontranslasie die gateway se tonneladres is, en ’n breë 0.0.0.0/0-inskrywing op elke peer is nie vir hierdie ontwerp nodig nie. Wat die terugkeerverkeer laat val, is ’n peer wie se lys daardie adres weglaat, of ’n bronbehoudende ontwerp wat eerder die besoeker se eie adres deurstuur, so kontroleer die bron wat die peer werklik sien, nie die een in jou reël nie.
Hou die gateway se eie luisteraars uit die reël
Vervang die poortpassing met ’n reël wat elke TCP- en UDP-bestemming dek, en die gateway se eie WireGuard-sok sit binne-in dit. Bestemmingsvertaling gebeur voordat die masjien besluit ’n pakket is plaaslik, so UDP 51820 kan by die peer beland eerder as by die proses wat elke peer-verbinding hou. Die reël laai suksesvol en die tonnel sterf, wat ’n moeilike faling is om van die peer-kant te lees.
SSH, moniteringsagente en enige ander diens wat op die gateway gehuisves word, het dieselfde blootstelling. ’n Reël wat alles deurstuur, onderskei nie die beheervlak van die gepubliseerde toepassing nie, en die eerste herlaai ná die verandering is wanneer die uitsluiting duidelik word. Die alles-dekkende reël waarsku nie oor die diens wat hy stilweg oorneem nie. Jy ontdek dit wanneer die volgende verbinding misluk.
As breë doorstuur werklik nodig is, reserveer die beheerpoorte voor die alles-dekkende reël of gebruik ’n aparte openbare adres vir publikasie. Die tweede opsie is skoner, want die beheeradres hou sy eie beleid, maar die verskaffer moet daardie adres lewer; om ’n DNS-rekord by te voeg, ken nie een toe nie.
Breë TCP- en UDP-doorstuur is ook nie alle protokolle nie. ICMP, IPv6, pad-MTU-terugvoer en die buitenste VPN-vervoer het hul eie beleid nodig, en ’n reël wat TCP en UDP dek, laat daardie gevalle aan die verstekketting oor.
Kies die model voordat jy reëls skryf
Vier vorms dek die meeste gateway-publikasies, en die keuse hang daarvan af hoeveel dienste jy loop en hoeveel beheervlak-risiko jy kan verdra. Die tabel hieronder orden hulle van die nouste tot die breedste.
| 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 |
Begin met die nou model, selfs al verwag jy later meer dienste. Dit is die maklikste om te oudit, en om ’n stel nou reëls in ’n hersiene alles-dekkende reël te omskep, is eenvoudiger as om te ontdek watter luisteraar ’n breë reël vasgevang het. Watter model jy ook kies, hou die reëls by die brandmuur-eienaar. Om iptables-reëls langs ’n UFW- of nftables-konfigurasie toe te pas wat dieselfde kettings ook bestuur, lewer ’n beleid wat afhang van die selflaai-volgorde.
Bewys beide die publikasie en die beheerpad
Toets van ’n gemagtigde buite-kliënt met die goedgekeurde gasheernaam en ’n sertifikaat wat daarvoor geldig is. Bevestig watter backend geantwoord het, en kontroleer dan dat onverwante openbare poorte steeds geweier word. ’n Gedeaktiveerde sertifikaatkontrole is nie ’n geslaagde HTTPS-toets nie, en ’n verbinding wat die verkeerde backend bereik, is erger as een wat misluk.
Daarna, verifieer die gateway self: verbind ’n WireGuard-peer, open ’n SSH-sessie en bevestig dat monitering steeds rapporteer. Die gepubliseerde diens kan werk terwyl die beheervlak stukkend is, so albei kontroles hoort in dieselfde veranderingsvenster. Herlaai een keer om te bewys dat die reëls in die verwagte volgorde weer toegepas word, verwyder dan die publikasie en bevestig dat die verwydering werklik by die byvoeging pas. ’n Groot stel selflaai-byvoegings met onvolledige opruiming is hoe ’n tydelike toets ’n permanente opening word.