NAT ya LAN kupitia tun0 kwenye lango la VPN la OpenBSD

Wahandisi wawili walio na lango moja la OpenBSD mara nyingi watakupa seti mbili tofauti za kanuni za kufikia mtandao wa mbali, na zote zinaweza kutetewa. Uchaguzi kati ya tafsiri ya chanzo na njia ya kurudi sio swali la sintaksia hata kidogo. Yote inategemea kile upande mwingine unachojua tayari kuhusu 192.168.88.0/24 na kile unachohitaji kuweka kwenye kumbukumbu zako. Kosea hapa na mstari wa nat-to utaonekana sahihi kabisa wakati majibu yanapotea kwenye lango la chaguo-msingi la mbali.

Uelekezaji na uandikaji upya hujibu maswali tofauti

Jedwali la uelekezaji huamua kuwa 172.20.0.0/16 inafikika kupitia tun0, na uamuzi huo hufanyika kabla ya tafsiri yoyote ya pf kushauriwa. Kisha tafsiri ya chanzo hubadilisha kichwa cha pakiti ili upande wa mbali uone anwani ya handaki ya lango badala ya mwenyeji wa LAN. Hakuna utaratibu unaobadilisha mwingine: kanuni ya nat haiwezi kuunda njia, na njia haiwezi kumshawishi kipanga njia cha mbali ambacho hakijawahi kusikia kuhusu mtandao wako wa kibinafsi. Wakati upande wa mbali hauna njia ya kurudi, majibu hutupwa au hupelekwa kwenye lango lake la chaguo-msingi, na urekebishaji wowote wa kanuni hautengenezi hilo.

Kwa urahisi, upelekaji hujibu trafiki inakokwenda na tafsiri hujibu inaonekana inatoka wapi. Weka vyote viwili kwenye masanduku tofauti ya mawazo unapounda seti ya kanuni.

Masharti matatu yanayoamua

Uliza maswali matatu kwa mpangilio na muundo mara nyingi hujichagua wenyewe. Je, mtandao wa mbali una njia tuli inayoelekeza kwenye anwani ya handaki kwa 192.168.88.0/24, au msimamizi wake anadhibiti vipanga njia vya njia hiyo? Ikiwa ndio, acha anwani za LAN zisafiri bila kubadilishwa na ruka tafsiri kabisa. Je, unahitaji mwonekano kwa kila mteja upande wa mbali, iwe kwa sera ya ufikiaji au kwa athari ya ukaguzi? Ikiwa ndio, kuhifadhi chanzo kunastahili kazi ya uelekezaji. Je, anwani ya handaki ni thabiti vya kutosha kuandikwa kwenye njia ya mbali, au inabadilika kati ya miunganisho upya?

Ikiwa jibu lolote ni hapana au halijulikani, nat-to ni chaguo la kiutendaji, na pia ndilo linaloweza kurudishwa. Kanuni ya tafsiri hutoka kwa mstari mmoja mara upande wa mbali unaongeza njia sahihi. Njia ya kurudi ambayo haikuwekwa kamwe hukugharimu uzi mmoja wa msaada kila mtu anapouliza kwa nini handaki inafanya kazi upande mmoja tu.

Weka kipande ili pf ikitathmini kwa kweli

Kipande kilicho hapa chini kinadhani LAN ni 192.168.88.0/24, mtandao wa mbali ni 172.20.0.0/16, na kiolesura cha handaki ni tun0. Hakuna kinachochagua hatua inayofuata ndani yake. Kinaandika upya chanzo kwenye pakiti ambazo tayari zinatoka kupitia handaki.

match out on tun0 inet from 192.168.88.0/24 to 172.20.0.0/16 nat-to (tun0)
pass in on em0 inet from 192.168.88.0/24 to any keep state

Maelezo mawili kwenye mstari huo wa kwanza yanabeba uzito mkubwa. Mabano kuzunguka tun0 yanaiambia pf isome anwani ya kiolesura kila inapounda ingizo la hali, jambo ambalo ni muhimu wakati handaki inapewa namba mpya baada ya kuunganishwa upya. Neno match linamaanisha kanuni inaandika upya kisha inaanguka chini, kwa hivyo kanuni tofauti ya pass bado lazima iruhusu mtiririko. Kiolesura kilichotajwa kwenye mstari wa match lazima pia kiwe kile kinachochaguliwa na jedwali la uelekezaji, vinginevyo pf itatathmini kanuni kwenye njia tofauti ya kutoka kuliko ile pakiti inayochukua kwa kweli.

Usisahau upande wa kernel. Upelekaji wa IPv4 lazima uwezeshwe, na kanuni za pass zenye hali kwa handaki na LAN lazima ziwepo kabla ya haya yote kuwa na maana. Sehemu ya PF NAT kwenye OpenBSD FAQ ni rejea sahihi kwa mpangilio wa maneno muhimu hapa.

Thibitisha seti ya kanuni kabla ya kuamini trafiki

Kwanza angalia sintaksia kwa pfctl -nf /etc/pf.conf, ambayo huchanganua faili bila kuipakia. Kisha pakia sera na usome tena kile kernel inachoshikilia kwa kweli, kwa sababu kanuni iliyochanganuliwa vizuri bado inaweza kufunikwa au kuunganishwa na kiolesura kisicho sahihi. pfctl -sn huchapisha kanuni za tafsiri katika umbo lake lililopakiwa, na pfctl -sr huchapisha kanuni za kichujio kwa mpangilio wa tathmini.

Kisha tazama waya. Kwenye lango, tcpdump -ni tun0 'host 172.20.0.10' huonyesha kama anwani ya chanzo inayotoka kwenye handaki ni anwani ya handaki au mwenyeji wa LAN. netstat -rn -f inet ya haraka huthibitisha kiolesura ambacho lengo linatatuliwa. Trafiki ikiwa inatiririka, pfctl -ss huorodhesha maingizo ya hali; ikiwa mtiririko haukuunda hali, pakiti haikukutana kamwe na kanuni inayounda moja.

Ikiwa upande wa handaki unaonekana sahihi na majibu bado hayaji, acha kuhariri pf. Hitilafu iliyobaki iko kwenye kipanga njia cha mbali, ambapo jibu linapelekwa kuelekea anwani ya kibinafsi ambayo upande huo hauwezi kufikia.

Wakati tafsiri inagharimu zaidi kuliko inavyookoa

Tafsiri huficha wateja, na wakati mwingine huo ndio ubadilishanaji mbaya kabisa. Mitandao midogo inayopishana ni kisa kimoja: ikiwa upande wa mbali pia unatumia 192.168.88.0/24 ndani, kuwasilisha wenyeji wa LAN kama lango hufanya mgongano kuwa mbaya zaidi badala ya bora. Sera za IPsec zinazochagua trafiki kwa jozi ya anwani ni kisa kingine, kwa sababu hifadhidata ya sera ya usalama hulinganishwa kabla ya tafsiri na haioni kamwe pakiti yako iliyoandikwa upya. Uwekaji wowote unaotoza, unaoweka kikomo au unaokagua kwa mtumiaji pia hupoteza utambulisho unaouhitaji wakati chanzo kinaporomoka kuwa anwani moja.

Vito vya pf vinavyobebeka ni mtego tofauti. Bidhaa zinazotengeneza faili zao za kanuni zinatarajia NAT isanidiwe kupitia kiolesura chao, na vipande vilivyohaririwa kwa mkono hufunikwa kwenye upakiaji upya unaofuata. Seti za kanuni zilizonakiliwa kutoka miongozo iliyoandikwa kabla ya neno muhimu match kuwepo hazitapakiwa kwenye kernel ya sasa, kwa hivyo hamisha sintaksia na usome hitilafu badala ya kubahatisha.

Kanuni ya uamuzi inayostahimili mawasiliano na mitandao halisi ni fupi: weka njia ya kurudi unapoweza, tafsiri usipoweza, na andika ni sharti gani kati ya matatu lilikufanya uchague hivyo. Kumbuka hilo humwokoa mtu anayefuata mchana mzima.