Kwa nini sheria yako ya iptables haioni kamwe trafiki ya VPN kupitia daraja

Mashine mbili pepe kwenye mwenyeji mmoja hufikia LAN kupitia daraja, na sheria iliyowekwa kwenye mnyororo wa ip forward inaonyesha kihesabu ambacho hakisogei kamwe. Fremu ni halisi, trafiki inapita, na sheria haiko kwenye njia yake. Kulinganisha njia mbili ambazo Linux huonyesha trafiki kupitia daraja kunaeleza ukimya huu, na pia kunaeleza kwa nini kupakia moduli moja ya zamani ni jibu baya kuliko inavyoonekana.

Njia mbili kupitia mwenyeji mmoja

Kifurushi kinaweza kuondoka kwenye mwenyeji huyu kwa njia mbili tofauti sana, na tofauti hiyo huamua ni ndoano zipi zitakazokiona. Ikiwa lengo liko ng'ambo ya bandari halisi na fremu inabadilishwa kati ya bandari mbili za daraja, mwenyeji hupeleka fremu ya Ethernet; msimbo wa uelekezaji haufanywi, na hakuna hatua iliyoelekezwa inayotokea. Ikiwa lengo ni mwenyeji mwenyewe, au mtandao unaofikiwa kupitia kiolesura cha handaki, kifurushi kinaelekezwa na ndoano za tabaka la IP hutumika kweli. Kumbuka mgawanyiko huu, kwa sababu kila swali la baadaye kuhusu minyororo na familia linatokana na njia ipi kati ya hizo mbili fremu inachukua.

Tofauti hiyo ni hadithi yote nyuma ya sheria isiyohesabu kitu. Fremu kupitia daraja kutoka veth9a1 hadi enp3s0 huvuka daraja, si rafu ya IP, kwa hivyo mnyororo ip forward hauoni kitu cha kulinganisha. Majina ya violesura kwenye mfano wa zamani hayaamui ni njia ipi uliyonayo, na ndiyo sababu hatua ya kwanza ni kuangalia topolojia badala ya seti ya sheria.

Handaki huongeza kisa cha tatu kinachostahili jina. Kifaa cha TUN hukabidhi vifurushi vya IP kwa mwenyeji, kwa hivyo vinaelekezwa na hupita kweli kwenye minyororo ya IP, wakati kifaa cha TAP kilichounganishwa na daraja hukabidhi fremu na hufanya kama kisa cha daraja. Aina ya kifaa, si jina la bidhaa, ndiyo huamua.

Linganisha familia mbili zinazoweza kuona fremu kupitia daraja

Linux inaunga mkono uchujaji asilia wa daraja kupitia familia ya bridge ya nftables, na haihitaji moduli yoyote ya zamani kukagua na kutupa fremu wakati wa kukimbia. Nyaraka za daraja za kerneli yenyewe hutoa pendekezo hilo moja kwa moja, jambo ambalo linafaa kujulikana kabla matokeo ya utafutaji hayajakuambia upakie moduli.

Kutumia amri ya nft badala ya iptables hakuweki sheria kwenye familia sahihi yenyewe. Mnyororo uliotangazwa katika familia ya bridge huona fremu; mnyororo uliotangazwa katika ip, ip6 au inet hauoni, bila kujali ni faili gani la binary lililoiunda. Familia ni sifa ya mnyororo, si ya chombo kilichoandika.

Njia ya zamani hufanya kazi tofauti, na ndiyo sababu inafaa kulinganisha badala ya kuchagua upande kwa mazoea. Kupakia br_netfilter na kuwasha mipangilio ya bridge-nf-call kunaonyesha tena trafiki ya IPv4 na IPv6 kupitia daraja kupitia ndoano za tabaka la IP, hivyo sheria ya kawaida ya iptables hatimaye inaweza kulinganisha nayo. Fremu hazibadiliki; seti ya ndoano zinazopita hubadilika, ambayo inamaanisha kila sheria iliyopo ya mwenyeji sasa ina hadhira mpya.

Soma njia halisi kabla ya kuongeza sheria

Amri tatu hubainisha ulipo: daraja limeunganishwa na nini, kama moduli ya zamani inafanya kazi, na minyororo ipi tayari ipo katika familia ya bridge. Zifanye kabla ya kuandika kitu, kwa sababu jibu huamua ni muundo upi kati ya miwili unaoupana. Kuruka hatua hii ndiyo njia ambayo sheria sahihi huishia kwenye mnyororo ambao hakuna kitu hupita.

bridge link show
lsmod | grep br_netfilter
nft list ruleset | grep -A4 "chain forward"

Matokeo hutenganisha visa kwa usafi. Bandari zilizoorodheshwa chini ya daraja hukuambia ni violesura vipi vinabadilishwa; matokeo tupu ya lsmod yanamaanisha hakuna uonekano wa tabaka la IP wa fremu za daraja; mnyororo wa forward wa familia ya bridge uliopo tayari unamaanisha mmiliki wa sera tayari yupo na sheria yako inafaa huko si kwenye mnyororo mpya wake.

Kisha ongeza sheria moja ambayo ni rahisi kusoma tena, ikiwa na kihesabu na bila kubadilisha uamuzi, na peleka mtiririko mmoja wa mwakilishi kupitia daraja. Kihesabu kinachosogea kinathibitisha kuwa fremu ilifika kwenye sheria. Hiyo ndiyo yote inayothibitisha, kwa hivyo fuata pia njia iliyokataliwa, kwa kuwa sera inayokubali kila kitu pia hutoa kihesabu kinachosogea.

nft add rule bridge filter forward iifname "veth9a1" oifname "enp3s0" counter accept

Ambapo moduli ya zamani hubadilisha tabia

Kuwasha njia ya zamani kwenye daraja linalofanya kazi si kitendo cha kawaida cha kuongeza uonekano. Sheria zilizokuwa hazifikiki kwa trafiki ya daraja zinakuwa zinafikika, ikiwa ni pamoja na sheria za mwenyeji zilizoandikwa kwa kiolesura kingine, na sera ya drop ya msingi kwenye mnyororo wa ip forward inaweza ghafla kutumika kwa fremu zilizokuwa zikipita bila kuguswa. Kwenye mwenyeji unaosimamiwa kupitia daraja hilo, matokeo ni kufungwa bila konsoli. Hii si hali ya kushindwa ya kufikirika; ni matokeo ya kawaida ya kupanua seti ya ndoano kwenye mashine unayoifikia kwa njia uliyoipanua hivi punde.

Mfululizo salama zaidi ni kuamua familia ipi inamiliki sera, kuandika sheria huko, na kudumisha njia huru ya urejeshaji kabla ya kubadilisha sysctl yoyote. Ikiwa familia mbili zinashikilia sheria, andika rasmi ipi yenye mamlaka; sera mbili zinazopishana ndiyo njia ambayo kifurushi hukubaliwa mahali pamoja na kutupwa mahali pengine bila faili moja ya kusoma.

Utengaji wenyewe bado unahitaji muundo kamili. Kuruhusu chanzo kimoja kufikia lengo moja kunathibitisha tu kuwa mtiririko mmoja unafanya kazi, wakati hitaji kwa kawaida ni kwamba VM haiwezi kufikia majirani zake au mwenyeji. Vihesabu kwenye sheria za kukataa ni muhimu zaidi kuliko kihesabu kwenye sheria ya kukubali, kwa sababu kihesabu cha kukubali ndicho ulichokuwa ukitazamia kisogee.

Mwisho, weka kisa cha pembejeo la mwenyeji kando. Trafiki inayoelekezwa kwa IP ya daraja yenyewe hufika kwenye input, si forward, na sheria iliyo kwenye forward haitaiona kamwe, familia yoyote unayochagua. Visa vitatu, familia mbili, somo moja: njia huamua ndoano, na ndoano huamua kama sheria yako ipo kabisa.