Jibu linatoka kupitia LAN, si kupitia handaki: kwa nini na jinsi

Huduma iliyochapishwa kupitia lango hufanya kazi kutoka sehemu kubwa ya intaneti na hushindwa kutoka ofisi moja. Mtu hukagua handaki, huona ombi likiwasili na huhitimisha kwamba jibu lazima lirudi kwa njia hiyo hiyo. Linux haifanyi kazi hivyo, na uchunguzi wowote wa handaki haubadilishi jibu. Jibu huelekezwa kulingana na lengwa, na huyo mpigaji mmoja anayeshindwa yuko kwenye subnet ambayo mwenyeji tayari anaifikia moja kwa moja.

Kinachoamua pakiti inayotoka kwa kweli

Kernel hutafuta njia kwa lengwa la pakiti, hukagua kanuni za sera kwa mpangilio wa kipaumbele kisha jedwali ambalo kanuni inayolingana huchagua. Kiolesura ambacho pakiti iliwasilia hakina nafasi yoyote, isipokuwa kanuni au alama imeandikwa kuifanya iwe muhimu. Hii ni hali ya uelekezaji ya mwenyeji huyu, si hitilafu kwenye handaki.

Kwa hivyo ombi linalopokelewa kupitia handaki linaweza kutoa jibu linalotoka kupitia kiolesura halisi, na mtiririko hugeuka kuwa wa upande mmoja bila kifaa chochote kuripoti hitilafu. Kagua pande zote mbili kabla ya kufikia hitimisho kuhusu handaki. Jibu linalotoka upande usiofaa hupotea kutoka vihesabu vya handaki, ndiyo sababu pande mbili hazikubaliani kama kitu kilitumwa. Angalia ni kihesabu kipi kilichosogea kabla ya kugusa kanuni.

Kwa nini subnet ya ndani hushinda

Mwenyeji mwenye anwani kwenye mtandao wa ndani ana njia iliyounganishwa kwa kiambishi hicho kwenye jedwali kuu, na njia iliyounganishwa ni ulinganifu wa moja kwa moja. Mpigaji anapotoka kwenye subnet hiyo hiyo, utafutaji hupata kiungo cha ndani kabla handaki halijazingatiwa.

Uwiano huo ndio unaofanya utambuzi uchanganye. Wapigaji kutoka intaneti pana hufanya kazi kwa sababu hawalingani na njia yoyote ya ndani, ilhali mpigaji pekee anayeshiriki kiambishi cha ofisi hushindwa, na ndiye mpigaji ambaye mtu hujaribu naye.

Ufikiaji wa peer si sawa na njia zilizowekwa

Kwa upande wa handaki, masafa yanayoruhusiwa ya peer hueleza kinachoweza kutumwa kwenye handaki na vyanzo vipi hukubaliwa kutoka humo. Hazisemi chochote kuhusu wapi jedwali la uelekezaji la ndani litatuma pakiti.

Ikiwa zana ya handaki itaweka njia chaguo-msingi kwenye mwenyeji, inaweza kuvuta trafiki isiyohusiana kwenye handaki kama uharibifu wa kando. Mahali ambapo kanuni ya sera inapaswa kumiliki uamuzi, chaguo la uwekaji wa njia za zana liko mahsusi ili kuzuia hilo, na anwani, funguo na mipangilio ya kituo cha mwisho hubaki sawa kabisa. Njia chaguo-msingi iliyoongezwa kwa urahisi ni njia ya kawaida ambayo mwenyeji hupoteza mtandao wake wa ndani.

Chagua jedwali kwa anwani ya chanzo

Kanuni inayotegemea chanzo hutuma majibu kutoka anwani ya huduma kwenye jedwali la faragha ambalo chaguo-msingi lake ni handaki, ilhali kila kitu kingine kinaendelea kutumia jedwali kuu. Chagua namba za jedwali na kipaumbele ambazo hazitumiwi ndani, na usome kanuni zilizopo kabla ya kuingiza chochote. Soma kanuni zilizo hai badala ya faili iliyohifadhiwa, kwa sababu zote mbili zinaweza kutofautiana baada ya kuwasha upya.

ip -6 route add default dev wg0 table 200
ip -6 rule add priority 32000 from 2001:db8:aa::20/128 lookup 200
ip -6 rule add priority 32001 from 2001:db8:aa::20/128 unreachable

Mstari wa mwisho hufanya njia inayokosekana ishindwe kwa kuonekana badala ya kurudi kwenye kiungo cha ndani. Chanzo lazima kiwe kimepewa mwenyeji kwa kweli, na utafutaji wa kawaida wa ndani na ule kuu lazima ubaki kwenye nafasi zake za awali. Kanuni huchagua jedwali kwa chanzo; hailiganishi urefu wa kiambishi kati ya majedwali.

Thibitisha njia, kisha huduma

Uliza kernel ingefanya nini badala ya kukisia kutoka kwenye kunasa, ukitumia anwani ya huduma kama kichaguzi cha chanzo. Jibu sahihi hapa huokoa ufuatiliaji mzima wa pakiti.

ip -6 route get 2001:db8:bb::30 from 2001:db8:aa::20

Matokeo yanapaswa kutaja handaki. Kisha jaribu chanzo usichokigusa na uthibitishe kwamba bado kinachukua kiungo cha ndani, ili mabadiliko yabaki kwenye anwani moja. Kichaguzi kipana zaidi hakingethibitisha chochote kuhusu malalamiko ya awali.

Mambo ambayo hii hairekebishi

Acha usambazaji, kanuni za firewall na tabia ya ICMPv6 kwenye lango kama zilivyokuwa, kwa sababu njia ya chanzo haibadilishi hata moja yao. Ujumbe wa Packet Too Big unaokosekana bado huvunja majibu makubwa, jedwali lolote lililoshinda utafutaji. Rekebisha hilo kabla ya kuongeza kanuni za uelekezaji, vinginevyo dalili itaendelea baada ya mabadiliko.

Thibitisha mfumo wa uchapishaji kabla ya kutumia chochote kati ya hivi. Proksi ya kinyume inayofungua muunganisho wake wa backend huwasilisha chanzo chake na haihifadhi mpigaji, kwa hivyo hitilafu hii haiwezi kutokea katika muundo huo. Kutumia kanuni huko kunaongeza kighairi cha uelekezaji kisichotatua chochote na kuficha sababu halisi.

Mwisho, andika namba za kanuni na jedwali kwenye usimamizi wa usanidi wa mwenyeji. Kanuni ya sera iliyoongezwa kwa mkono hupotea kwenye ujenzi upya unaofuata, na mpigaji wa ofisi hurudi na malalamiko yale yale.