Mga downstream client sa likod ng upstream VPN: ruta o NAT?

Isang gateway ang nagpapatakbo ng WireGuard para sa iyong sariling mga aparato at ng kliyenteng OpenVPN patungo sa network ng iba. Gumagana ang pagpapasa sa pagitan ng dalawang panloob na interface, at madaling isipin na ang downstream subnet ay bahagi na ngayon ng upstream service. Hindi. Ang rutang hinihila ng client ay nagsasabi sa iyong gateway kung saan ipapadala ang mga kahilingan; wala itong sinasabi tungkol sa kung paano ibinabalik ng malayong network ang trapiko sa mga aparatong hindi pa nito narinig. Pumili ng modelong pabalik na talagang sinusuportahan ng upstream bago ka magdagdag ng kahit isang tuntunin.

Magpasya sa modelong pabalik bago mo hawakan ang routing

Sa gabay na ito, gumagamit ang mga downstream client ng 10.90.0.0/24, ang upstream tunnel address na itinalaga sa gateway ay 10.80.0.6, at ang aprubadong malayong mapagkukunan ay 172.20.0.30. Dalawang modelo ang umaangkop sa hugis na iyon: panatilihin ang downstream na pinagmulan at gawing ruta ito ng malayong panig, o isalin ang pinagmulan sa sariling tunnel address ng gateway. Lahat ng sumusunod sa desisyong ito ay mekanikal, at ang desisyon mismo ay nangangailangan ng may-ari ng serbisyo. Ang isang hilera sa itaas ay kasunduan sa routing sa malayong panig; ang isa ay lokal na pagbabago sa patakaran na kaya mong gawin nang mag-isa. Ang paghahalo ng dalawa ang nagiging dahilan kung bakit nagiging negosasyon ang sampung minutong pagbabago.

preserved:  10.90.0.23 -> 172.20.0.30
translated: 10.80.0.6  -> 172.20.0.30

Pumili ng isang hilera at manatili rito. Ang mga hilera ay alternatibo, hindi hakbang, at ang paghahalo sa kanila ay gumagawa ng disenyong walang makapagpapaliwanag sa pagsusuri.

Pangangalaga sa pinagmulan sa pamamagitan ng ruta

Tumatanggap ang malayong panig ng kahilingan mula sa downstream address, kaya kailangan nito ng sinusuportahang ruta at pagmamay-ari ng peer para sa subnet na iyon, at pahintulot na tanggapin ito. Mga setting sa malayo ang mga ito, at walang lokal na rutang Linux ang gumagawa sa kanila. Hilingin ang mga ito nang tahasan at nakasulat, kasama ang prefix at ang peer ng tunnel na magdadala nito, at asahan na ang sagot ay nakasalalay sa kung sinusuportahan ng serbisyo ang mga kaayusang site-to-site.

Kung oo ang sagot, maliit lamang ang lokal na configuration: bukas ang pagpapasa, ang allowed-ips ng WireGuard peer na sumasaklaw sa downstream range, at patakaran ng firewall na nagpapahintulot sa pagtawid sa dalawang direksyon.

Sadyang pagsasalin ng pinagmulan

Kung ibinabalik lamang ng serbisyo ang trapiko sa address ng konektadong client, isalin ang pinagmulan sa address na iyon palabas at panatilihin ang conntrack state na nagbabalik nito para sa mga tugon. Limitahan ang tuntunin sa mga inilaan na downstream na pinagmulan, sa mga inilaan na malayong destinasyon at sa upstream interface. Ang tuntuning nagsasalin ng lahat ng lumalabas sa bawat interface ay mas malaking patakaran kaysa sa pangangailangang ito, at mabibigla ka mamaya.

Kailangan ng IPv6 ng sarili nitong disenyo; ang pagkopya ng IPv4 masquerade line ay hindi arkitektura. Subukan ang isinaling landas gamit ang bagong koneksyon sa halip na naka-cache.

Kailangan pa ring gumana ang lokal na landas ng datos

Hindi inaalis ng pagsasalin ang lokal na gawain: kailangan pa rin ng gateway ng ruta patungo sa downstream na destinasyon, tamang pagmamay-ari ng pinagmulan ng WireGuard peer, bukas na pagpapasa at makitid na patakaran ng firewall sa pagitan ng mga interface. Ang kahilingang nalikha sa gateway mismo ay hindi nagsasanay ng alinman sa mga pahintulot na iyon, kaya pumapasa ang lokal na pagsubok sa gateway habang nabibigo pa rin ang mga downstream na aparato.

Subukan mula sa tunay na downstream na aparato, hindi sa gateway. Ang address ng pinagmulan ang buong punto ng pagsasanay na ito.

Ang isang pinagmulan ay nangangahulugan ng isang pagkakakilanlan ng sesyon

Nakikita ng malayong serbisyo ang awtentikadong sesyon ng gateway at ang isinaling address nito, hindi ang hiwalay na awtentikasyon para sa bawat downstream na aparato. Panatilihing tahasan ang mga pahintulot bawat aparato at ang mga pagkakakilanlan ng aplikasyon, at kumpirmahin sa may-ari ng serbisyo na ang gateway na kumikilos para sa maraming aparato ay pinapayagan. Ang pagsasalin ay hindi paraan upang laktawan ang pangangailangan ng pagpaparehistro bawat aparato; kung hinihingi ng serbisyo na magparehistro ang bawat aparato, gamitin ang modelong iyon o makipagnegosasyon ng kaayusang site-to-site.

Isulat ang kumpirmasyong iyon sa runbook sa tabi ng tuntunin, dahil itatanong ng susunod na tagasuri kung naaprubahan ang disenyo o naging maginhawa lamang.

Tukuyin ang estado ng pagkadiskonekta, pagkatapos subukan ang tatlong kahilingan

Magpasya kung ano ang mangyayari kapag bumagsak ang upstream tunnel. Ang awtorisadong malayong trapiko ay hindi dapat tahimik na sumunod sa ordinaryong WAN fallback kung saan ipinagbabawal iyon, kaya ang patakaran ng firewall na nagpapahintulot sa pagtawid ay dapat ding mabigo nang sarado. Pagkatapos subukan ang tatlong kaso mula sa tunay na downstream na aparato: isang pinapayagang kahilingan na gumagana, isang hindi pinapayagang kahilingan na nabibigo, at isang pagkasira sa upstream na humihinto sa pinapayagan.

Itala ang pag-urong sa isang hilera bawat tuntunin, upang maibalik ang pagbabago nang hindi binabalik ang layunin.