Ang mga patakarang nagpapasa ng lahat ng port ay maaaring lumamon sa iyong WireGuard listener

May pampublikong gateway na nagpapatakbo na ng WireGuard sa UDP 51820, SSH sa 22, at isang application na dapat maabot mula sa internet. Ang nakakaakit na patakaran ay nagpapasa ng bawat port sa peer at idineklarang tapos na. Sa isang WireGuard gateway, maaaring mahuli ng patakarang iyon ang sariling transport ng tunnel at ikandado ka sa labas ng makina na nagtatapos nito. Ang paglalathala ay isang desisyon sa routing na may pagbubukod para sa control plane, hindi isang linyang DNAT.

Pampublikong pasukan o pasukan sa tunnel: pumili ng isa

Ang paglalathala ng serbisyo ay lumilikha ng bagong pasukan sa internet. Hindi ito katulad ng pagbibigay ng VPN membership sa isang peer, dahil hindi kailanman pumapasok ang bisita sa tunnel at nagiging pampublikong mukha ng backend ang gateway. Ang pagkakaibang iyon ang nagtatakda ng audience ng patakaran at ng certificate nito.

Bihirang nababagay ang mga administrative interface sa ganoong puwesto. Ang admin page na inaabot ng awtorisadong VPN client ay nagpapanatili ng attack surface sa loob ng tunnel at umiiwas na ilantad ang login form sa basta-bastang pag-scan. Ang mga pampublikong application endpoint ay kailangan pa rin ng sariling TLS certificate, authentication at rate limiting; hindi pinoprotektahan ng naka-encrypt na WireGuard hop ang bahagi ng bisita hanggang sa gateway.

Kung talagang kailangang maging pampubliko ang serbisyo, isulat ang hostname, ang certificate na sumasaklaw dito at ang mga hanay ng bisitang dapat makarating dito. Ang tatlong katotohanang iyon ang magtatakda ng hugis ng patakaran at ng patakaran sa pag-filter mamaya. Anumang labas sa mga iyon ay pagpapalawak ng saklaw sa isang pampublikong listener.

Isang port papasok, isang backend palabas

Gumamit ng isang pampublikong port at isang serbisyong backend. Sa halimbawang ito, dinadala ng eth0 ang pampublikong address na 198.51.100.20, ang tunnel address ng gateway ay 10.200.0.1, at pinapatakbo ng peer ang application sa 10.200.0.7. Ang pampublikong TCP 9443 ay namamapa sa TCP 8443 ng peer:

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

Tumutugma ang SNAT na patakaran sa isinaling backend at sa orihinal na pampublikong destination, kaya ang isa pang koneksyon sa parehong serbisyong backend ay nananatili sa labas ng mapping na ito. Itinatago rin nito ang address ng bisita mula sa peer, at iyon ang trade-off na gumagawa sa routed return na nagpapanatili ng source bilang hiwalay na disenyo. Ang reference ng mga extension ng iptables ay nagdodokumento sa parehong target at sa kanilang mga opsyon sa pagtutugma.

Kailangan pa ring paganahin ang pagpapasa, at ang filter chain ay nangangailangan ng pahintulot para sa isinaling destination at port kasama ang mga established na tugon. Nakikita ng FORWARD chain ang isinaling destination pagkatapos ng DNAT, kaya ang patakarang isinulat laban sa pampublikong address ay hindi tumutugma sa ipinapasang packet. Isulat ang pahintulot laban sa backend tuple, hindi sa pampubliko.

Dapat tanggapin ng peer ang koneksyon ng serbisyo mula sa tunnel address ng gateway at ipadala ang tugon pabalik sa tunnel. Dapat awtorisahin ng AllowedIPs nito ang source na aktwal nitong natatanggap, na sa ilalim ng source translation ay ang tunnel address ng gateway, at ang malawak na 0.0.0.0/0 entry sa bawat peer ay hindi kailangan para sa disenyong ito. Ang nagpapatumba sa return traffic ay isang peer na inaalis sa listahan ang address na iyon, o isang disenyong nagpapanatili ng source na sa halip ay nagpapasa ng address ng bisita, kaya suriin ang source na aktwal na nakikita ng peer, hindi ang nasa iyong patakaran.

Ilayo ang sariling listener ng gateway sa patakaran

Palitan ang port match ng patakarang sumasaklaw sa bawat TCP at UDP destination, at ang sariling WireGuard socket ng gateway ay napapaloob dito. Nangyayari ang destination translation bago magpasya ang makina na lokal ang isang packet, kaya ang UDP 51820 ay maaaring mapunta sa peer sa halip na sa prosesong humahawak sa bawat peer connection. Matagumpay na naglo-load ang patakaran at namamatay ang tunnel, isang pagkabigo na mahirap basahin mula sa panig ng peer.

Ang SSH, monitoring agent at anumang iba pang serbisyong naka-host sa gateway ay may parehong exposure. Ang patakarang nagpapasa ng lahat ay hindi nakikilala ang control plane sa inilathalang application, at ang unang reboot pagkatapos ng pagbabago ang sandaling nagiging halata ang lockout. Hindi nagbabala ang patakarang humuhuli sa lahat tungkol sa serbisyong tahimik nitong kinukuha. Malalaman mo ito kapag nabigo ang susunod na koneksyon.

Kung talagang kailangan ang malawak na pagpapasa, ireserba ang control port bago ang patakarang humuhuli sa lahat o gumamit ng hiwalay na pampublikong address para sa paglalathala. Mas malinis ang ikalawang opsyon dahil pinapanatili ng control address ang sariling patakaran, ngunit kailangang ibigay ng provider ang address na iyon; ang pagdagdag ng DNS record ay hindi naglalaan ng isa.

Ang malawak na pagpapasa ng TCP at UDP ay hindi rin lahat ng protocol. Ang ICMP, IPv6, path-MTU feedback at ang panlabas na VPN transport ay nangangailangan ng sariling patakaran, at ang patakarang sumasaklaw sa TCP at UDP ay nag-iiwan sa mga kasong iyon sa default chain.

Piliin ang modelo bago magsulat ng patakaran

Apat na hugis ang sumasaklaw sa karamihan ng paglalathala mula sa gateway, at ang pagpili ay depende sa bilang ng serbisyong pinapatakbo mo at sa dami ng panganib sa control plane na kaya mong tiisin. Iniaayos sila ng talahanayan sa ibaba mula sa pinakamakitid hanggang sa pinakamalawak.

Magsimula sa makitid na modelo kahit inaasahan mong mas maraming serbisyo mamaya. Ito ang pinakamadaling i-audit, at ang pagpapalit ng isang set ng makitid na patakaran tungo sa nasuring patakarang humuhuli sa lahat ay mas simple kaysa sa pagtuklas kung aling listener ang nahuli ng malawak na patakaran. Alinmang modelo ang piliin mo, itago ang patakaran sa may-ari ng firewall. Ang paglapat ng mga linyang iptables sa tabi ng UFW o nftables configuration na namamahala rin ng parehong chain ay lumilikha ng patakarang nagbabago depende sa pagkakasunod-sunod ng boot.

Patunayan ang paglalathala at ang control path

Subukan mula sa awtorisadong panlabas na client gamit ang aprubadong hostname at certificate na valid para dito. Kumpirmahin kung aling backend ang tumugon, pagkatapos ay tiyakin na ang mga walang kaugnayang pampublikong port ay nananatiling tinatanggihan. Ang patay na certificate check ay hindi isang pasado na HTTPS test, at ang koneksyong umaabot sa maling backend ay mas masama kaysa sa nabigo.

Pagkatapos, i-verify ang gateway mismo: ikonekta ang isang WireGuard peer, buksan ang isang SSH session at kumpirmahing nag-uulat pa rin ang monitoring. Maaaring gumana ang inilathalang serbisyo habang sira ang control plane, kaya parehong pagsusuri ay kabilang sa parehong change window. Mag-reboot nang isang beses upang patunayang muling inilalapat ang mga patakaran sa inaasahang ayos, pagkatapos ay alisin ang paglalathala at kumpirmahing talagang tumutugma ang pag-alis sa pagdaragdag. Ang malaking set ng pagdaragdag sa pagsisimula na may hindi kumpletong paglilinis ay kung paano nagiging permanenteng butas ang isang pansamantalang pagsubok.