Lokal na app, panuntunan ng VPN: bakit hindi kailanman umuusad ang iyong FORWARD chain

Naglalagay ka ng panuntunan para sa trapikong VPN sa FORWARD chain, pinapatakbo ang kahilingan mula sa parehong Linux machine, at nananatiling sero ang counter. Malamang tama ang panuntunan. Hindi kailanman dumaan ang pakete sa landas na iyon, dahil ang kahilingang nalikha sa makina mismo ay hindi ipinapasa nito. Ang pagsunod sa buhay ng pakete mula sa socket hanggang sa kable ang nagpapaliwanag kung bakit, at kung saan dapat naroon ang panuntunan.

Alamin kung saan isinilang ang pakete

Hinihiwalay ng pagkakasunod-sunod ng hook ng Netfilter ang tatlong kaso, at isa lamang sa mga ito ang may kinalaman sa FORWARD:

Nagsisimula ang lokal na aplikasyon sa landas ng OUTPUT, dahil natukoy na ng kernel na dito nagmumula ang pakete at hindi kailanman ito kandidato para ipasa. Hindi binabago ng paggawa ng tunnel ang klasipikasyong iyon; ang tunnel ay isang device na maaaring labasan ng pakete, hindi isang yugtong ginagawang transit ang lokal na output.

Dalawang pakete, isang kuwento

Kapag nakataas na ang tunnel, ang panloob na pakete ng app at ang naka-encrypt na panlabas na pakete ay magkaibang bagay. Dinadala ng panloob na pakete ang destinasyon at payload na pinili ng app. Dinadala ng panlabas na pakete ang ciphertext patungo sa address at port ng kapares, at iyon ang aktuwal na tumatawid sa pisikal na interface.

Ang patakaran mo ay tungkol sa isa sa kanila, at ang pagpili ng mali ay karaniwang dahilan kung bakit parang walang ginagawa ang isang panuntunan. Ang panuntunang tumutugma sa panlabas na address ng kapares ay nakikita ang bawat pakete ng tunnel nang pareho, anuman ang ginagawa ng app sa loob. Ang panuntunang tumutugma sa panloob na destinasyon ay nakikita ang trapikong mahalaga sa iyo, at uusad lamang ito kapag naabot ng paketeng iyon ang hook kung saan mo inilagay ang panuntunan.

Inililipat ng namespace ang hangganan

Pinapahirap ito ng container nang hindi binabago ang prinsipyo. Ang kahilingan ng app ay lokal na output sa loob ng network namespace ng container. Tinatanggap ng host ang trapikong iyon sa isang virtual na interface ng Ethernet at maaari itong ipasa, kaya ang panuntunang FORWARD sa host ay maaaring makabuluhan kahit hindi kailanman hinawakan ng prosesong lumikha ng kahilingan ang OUTPUT chain ng host.

Bago pumili ng hook, alamin kung saan talaga nakatira ang hanay ng panuntunan at ang tunnel. Ang tunnel sa loob ng container, tunnel sa host na naka-route ang container sa pamamagitan nito, at tunnel sa hiwalay na namespace ay tatlong magkaibang topolohiya na may tatlong magkaibang lokasyon ng panuntunan. Basahin ang mga panuntunan sa loob ng namespace na nagmamay-ari ng device, hindi lamang sa default.

Itanong kung kailangan mo ba talaga ng mark

Kung layunin na ipadala ang isang prefix ng destinasyon sa tunnel, maaaring sapat na ang ruta para sa prefix na iyon. Suriin muna ang mabisang ruta, kasama ang anumang itinulak ng server: ang redirect na default ay nagpapadala ng mas maraming trapiko sa VPN kaysa sa makitid na patakarang nasa isip mo, at walang dami ng mark ang magpapaaayon sa resulta sa layunin.

Kailangan ang klasipikasyon kapag ang desisyon ay nakasalalay sa isang bagay na hindi maipahayag ng ruta, tulad ng pinagmulan, gumagamit o proseso. Para sa natatanggap na trapiko, gumagana ang mark sa PREROUTING. Para sa lokal na trapiko, kailangang mangyari ang mark sa yugto ng output na makapag-uudyok ng bagong paghahanap ng ruta matapos mailagay ang mark. Sa nftables, iyon ay chain na uri route sa hook ng output; ang ordinaryong chain ng filter sa output ay maglalagay ng halaga at iiwan ang ruta na hindi nagbago.

Sa iptables, ang katumbas ay nasa kaayusan ng mangle OUTPUT, at parehong kundisyon ang nalalapat: kailangang muling suriin ang desisyon sa ruta matapos magkaroon ng mark. Pagkatapos, dapat gamitin ng panuntunan ng patakaran ang mark at tumuro sa isang talahanayan na may magagamit na ruta. Ang paglalagay ng conntrack mark ay ikatlo, hiwalay na operasyon; nagtatago ito ng halaga sa daloy at hindi nito mismo inilalagay ang halagang iyon sa kasalukuyang pakete para mabasa ng ruta.

Suriin ang paghahanap at ang counter nang sabay

nft list ruleset
ip route get 198.51.100.25
ip route get 198.51.100.25 mark 0x1

Ang address at mark ay halimbawa lamang, at ang dalawang tanong sa ruta ay sumasagot sa magkaibang tanong. Ang pangalawa ay nagtatanong kung ano ang gagawin ng kernel kung may dalang mark ang pakete; hindi nito ipinapakita na naglalaan ang hanay ng panuntunan mo ng isa. Ituring itong pagsubok ng haka-haka, hindi bilang ebidensiyang gumagana ang patakaran.

Pagkatapos, magpatakbo ng walang pinsalang kahilingan at panoorin ang dalawang bagay nang sabay: ang counter sa hook na pinili mo, at ang labasan na aktuwal na kinuha ng pakete. Kung gumagalaw ang counter at lumalabas ang pakete sa ibang lugar, mali ang mark o ang talahanayan. Kung wala sa dalawa ang gumagalaw, hindi talaga umaabot ang pakete sa hook na iyon, at ang susunod na tanong ay ang namespace o ang landas.

Panghuli, limitahan ang pagsubok sa kaya nitong ipahayag ng mekanismo. Ang isang ruta para sa isang address ay hindi nagiging permanenteng patakaran para sa serbisyong umiikot ang mga address. Pagpasyahan muna ang saklaw ng pakete, pagkatapos ay suriin kung kayang panatilihin ng disenyo ng ruta at mark ang saklaw na iyon pagkatapos ng muling pagkonekta.