Bakit hindi nakikita ng nftables ang trapik ng OpenVPN sa pagitan ng mga kliyente

Dalawang kliyente sa isang server ang nagpapalitan ng mga file, nagtagumpay ang paglilipat, at bawat tuntunin ng pagpapasa na itinuro mo sa tunel ay nag-uulat ng sero na pakete. Hindi sira ang mga tuntunin at hindi mali ang pagkakalagay ng kadena. Kapag naka-on ang pagpapasa sa pagitan ng mga kapantay, inihahatid ang pakete sa loob ng proseso ng server at hindi kailanman nagiging router ang stack ng host, kaya wala nang mabibilang ang firewall ng kernel. Ang pag-unawa sa paghahating ito ang magpapasya kung pananatilihin mo ang shortcut o itatayo muli ang landas sa pamamagitan ng kernel.

Sundan ang isang pakete sa server

Sa isang rutadong tunel, ibinibigay ng daemon ang na-decrypt na pakete ng bawat kliyente sa aparato ng tunel. Mula roon, ini-ruta ito ng host, tumatakbo ang kawit ng pagpapasa, at ang tuntuning tumutugma sa aparato ng tunel ay makakabilang o makakatapon ng trapik. Iyan ang landas na ipinapalagay ng karamihan sa mga halimbawa ng firewall.

Inaalis ng shortcut ang host sa gitna. Ang na-decrypt na pakete ng isang sesyon ay ibinibigay sa ibang sesyon sa loob ng daemon, at ang panloob na pakete ay hindi kailanman inilalabas sa aparato ng tunel at hindi ini-ruta ng host. Tumatawid pa rin ang naka-encapsulate na trapik sa pisikal na interface, kaya ang panlabas na pagkuha ay mukhang abala habang tahimik ang mga panloob na tuntunin. Ang pagkuha sa aparato ng tunel ay walang ipinapakita, na ikinagulat ng sinumang umaasang mapapanood doon ang paglilipat. Ang kawalan ng simetriyang iyon ang pinakamabilis na paraan upang makilala ang shortcut mula sa labas ng daemon.

Ang pagsubok sa counter na nagpapasya kung aling landas ang tumakbo

Ikabit ang isang counter sa tuntuning dapat umiral, magpatakbo ng paglilipat sa pagitan ng dalawang kliyente na dapat harangin ng tuntuning iyon, at pagkatapos ay basahin ang counter.

sudo nft list ruleset
sudo nft add rule inet filter forward iifname "tun0" oifname "tun0" counter accept
sudo nft list chain inet filter forward

Kung nagtagumpay ang paglilipat at nanatili sa sero ang counter, hindi kailanman hinarap ng kernel ang mga paketeng iyon, at walang pagbabago sa tuntunin ang makapagbabago nito. Ulitin ang parehong pagsubok laban sa isang serbisyo sa server mismo, dahil dumadaan talaga ang daloy na iyon sa stack ng host at gumagalaw ang counter nito. Ang paghahambing ng dalawang resulta ang nagbibigay ng sagot.

Dalawang detalye ang pumipigil sa maling pagbasa. Ang pangalan ng interface na nakasulat sa isang label ng kadena ay walang sinasala sa sarili nito, dahil ang pagtutugma ay nangyayari sa mga field ng interface sa loob ng mga tuntunin. At ang naka-bridge na disenyo ng layer 2 ay kumikilos nang iba pa: doon ay nagbabahagi ang mga kliyente ng isang broadcast domain, kaya inaasahan ang pagtuklas ng kapantay at hindi ito depekto sa ruta.

Ang switch ay hindi listahan ng access

Ito ang bahaging kumakain ng isang hapon. Ang pagpapasa sa pagitan ng mga kapantay ay isang setting na naka-on o naka-off, at habang naka-on ito, ang daemon ang tanging punto ng pagpapasa. Hindi maipahayag ng firewall ng host kung sino ang makakaabot kanino, at ang mga file kada kliyente ay hindi ginagawang matrix ng patakaran ang switch.

Kung kailangan mo ng tuntunin kada kapantay, ang pagpipilian ay sa pagitan ng pagbitiw sa shortcut at pagbitiw sa firewall ng host bilang kontrol. Ang pag-off nito ay nagbabalik ng pagpapasa ng kernel, na nangangailangan ng pagpapasa ng IP sa server at malinaw na tuntunin para sa mga daloy na gusto mo. Ang pag-iwan nito na naka-on ay nangangahulugang nabubuhay ang patakaran sa konpigurasyon ng daemon, na sa praktika ay lahat ng kapantay o wala.

Ang magkahiwalay na proseso ng server na may sariling pool ng address at port ay ang praktikal na gitnang landas. Bawat proseso ay may dala nang eksaktong isang desisyon sa access, kaya dalawang grupo ang maaaring may magkaibang tuntunin nang walang matrix ng patakaran. Maaaring mag-ruta ang host sa pagitan ng mga pool kapag iyon ang layunin, at nakikita ng firewall ang mga daloy na iyon dahil tumatawid sila sa host. Ang halaga ay karagdagang port, karagdagang sertipiko at isang profile kada grupo.

Pagpili ng punto ng pagpapasa

Piliin ang pagpapasa ng kernel kapag ang firewall ang makina ng patakaran, kapag kailangan mo ng pag-log kada daloy, o kapag mahalaga ang accounting. Ang halaga ay ang throughput sa stack ng host at mas maraming tuntuning aalagaan. Ang pakinabang ay ang bawat umiiral na kasangkapan, mula sa counter hanggang sa flow exporter, ay muling naglalarawan ng trapik. Sa maliit na server ay hindi nakikita ang halagang iyon; sa abalang relay ay nakikita.

Piliin ang pagpapasa sa loob ng proseso kapag ang trapik sa pagitan ng mga kapantay ay buong pinapayagan o buong ipinagbabawal at ang server ay may sukat para doon. Ang halaga ay hindi na inilalarawan ng counter, disiplina ng pila at pagsubaybay ng koneksyon ang mga panloob na daloy; katanggap-tanggap lamang ito kung walang umaasa sa mga iyon sa hinaharap.

Anuman ang piliin mo, isulat ito sa tabi ng mga tuntunin ng firewall. Ang isang set ng tuntunin na mukhang pinapayagan ang trapik sa pagitan ng mga kapantay habang nagpapasya pa rin ang daemon ay nanliligaw sa susunod na taong magde-debug ng nabigong paglilipat. Sinumang nagbabasa lamang ng mga tuntunin ay ipapalagay na ang kernel ang pintuan.

Ano ang dapat tiyakin bago baguhin ang mga tuntunin

Basahin ang konpigurasyong aktwal na ni-load ng server, hindi ang file na natatandaan mong na-edit mo, at tiyakin kung naroon ang opsyon ng kapantay. Kung binago mo ito, tiyaking nag-reload ang serbisyo at hindi lamang muling nagsulat ng file sa disk.

Pagkatapos ay ulitin ang pagsubok gamit ang daloy mula kliyente patungo sa server upang patunayang tumutugma man lang ang tuntunin, at suriin ang mga itinulak na ruta, dahil ang nawawalang ruta ay eksaktong mukhang harang ng firewall mula sa panig ng kliyente. Baguhin ang pagkakasunod-sunod ng mga tuntunin kapag alam mo na kung aling punto ng pagpapasa ang may hawak ng desisyon.