Mteja wa VPN kwenye seva ya LAN: kwa nini majibu yanatoka kwa njia isiyofaa

Dalili zinafuata umbo moja: mwenyeji anafanya kazi, kisha anajiunga na VPN kama mteja, na sasa wateja wa LAN wanamfikia wakati majibu yake yanapotea. Ukamataji kwenye mwenyeji unaonyesha kuwa majibu yanatoka kupitia kifaa cha handaki badala ya kiolesura cha LAN. Hakuna kilichovunjika kwenye handaki, na suluhisho ni njia, si kuunganisha tena. Fanya ukaguzi nne hapa chini kwa mpangilio na usimame kwenye ule wa kwanza unaoshindikana.

Jibu ni pakiti mpya, si kurudi kwa njia ile ile

Inasaidia kuacha wazo kwamba jibu linarudi kwa njia ambayo ombi lilienda. Uelekezaji huamuliwa kwa kila pakiti, kwa kila mwelekeo, kwenye mwenyeji anayetuma. Ombi lililofika kutoka 10.64.0.23 ndani ya handaki haliundi njia ya kurudi; mwenyeji anapojibu, jibu hilo hulinganishwa na jedwali kama pakiti mpya na hutoka kwa njia inayoshinda.

Ndiyo sababu mteja wa handaki kamili kwenye mashine inayohudumia LAN pia huzalisha hitilafu ya kuchanganya kama hii. Mteja husakinisha njia chaguo-msingi, au nusu-njia mbili za chaguo-msingi ambazo wateja wengine hupendelea, na jibu kwa mteja wa LAN sasa linaendana na handaki. Linaenda kwa mtoa huduma, ambaye hana sababu ya kulisambaza, na mteja wa LAN anaona muda umeisha ingawa mwenyeji yuko hai na anajibu kienyeji. Ukamataji unaifanya iwe dhahiri, na jedwali la uelekezaji linaieleza.

Kumbuka subneti mbili unaposoma sehemu iliyobaki. Moja ni bwawa la anwani za VPN ambako wateja wa mbali wanatoka, katika mfano huu 10.64.0.0/24. Nyingine ni LAN inayopaswa kuendelea kufanya kazi, 172.16.24.0/24 na kipanga njia chake kwenye 172.16.24.1. Hitilafu ni kwamba trafiki kati yao huamuliwa na njia chaguo-msingi.

Thibitisha kwa ukamataji na utafutaji

Kabla ya kubadilisha chochote, thibitisha kifaa gani jibu litatumia. Utafutaji ni wa haraka kuliko ukamataji na hujibu swali lile lile ambalo kerneli itajibu wakati pakiti inajengwa.

ip route get 10.64.0.23 from 172.16.24.10
tcpdump -ni any -c 6 icmp

Soma jibu kwa sehemu mbili. Ikiwa linataja dev tun0, mwenyeji atafunga jibu na kumkabidhi mtoa huduma, na mteja wa LAN hataliona kamwe. Ikiwa linataja dev eth0 lakini mteja bado anapata muda umeisha, njia tayari ni sahihi na pakiti inatupwa baadaye, ambayo ni tatizo lingine na suluhisho lingine.

Ukamataji katika hatua hiyo hiyo huamua shaka ambayo ping haiwezi. Jibu la mwangwi linalofika kwa mteja wa LAN linathibitisha kwamba njia fulani inafanya kazi, si kiolesura gani kiliibeba, kwa hiyo endesha ukamataji kwenye mwenyeji mwenyewe na uangalie fremu zinatoka wapi. Printa kwenye subneti hiyo hiyo inaendelea kujibu, kwa sababu njia yake ya moja kwa moja ni mahususi zaidi kuliko njia chaguo-msingi ya handaki. Bandari iliyosambazwa hushindikana sawa na mkondo mwingine wowote, kwa sababu kiolesura huchaguliwa na jedwali, si muunganisho.

Sakinisha njia nyembamba zaidi inayozidi handaki

Urefu wa kiambishi awali huamua, si metriki, kwa hiyo njia ya bwawa la wateja kupitia kipanga njia cha LAN hushinda njia yoyote chaguo-msingi ambayo mteja wa VPN husakinisha. Upasuaji wa metriki hauhitajiki, na njia chaguo-msingi inaweza kubaki mahali pamoja na mteja alipoiweka.

ip route replace 10.64.0.0/24 via 172.16.24.1 dev eth0
ip route get 10.64.0.23 from 172.16.24.10

Tumia replace badala ya add, kwa sababu mteja anayeunganisha tena atakuwa amesakinisha ingizo lake mwenyewe na add ya pili hushindikana na hitilafu ya njia iliyopo ambayo husomwa kama tatizo la ruhusa. Kwenye mwenyeji wa Windows kifananishi ni route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p, ambapo -p huhifadhi ingizo katika kuwasha upya, kwa kuwa mteja anaweza kujenga jedwali upya handaki linaporudi. Kwenye mwenyeji wa kisasa wa Windows kifananishi kinachotumika ni New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore, na amri ya zamani ya route huhifadhiwa kama umbo la zamani.

Kipengele kimoja huamua kama hii ni sahihi au inaaminika tu: hop inayofuata lazima iwe kipanga njia kinachomiliki kwa kweli njia ya kurudi kwa wateja. Kuelekeza njia kwa anwani ambayo yenyewe hufikiwa kupitia handaki huunda mzunguko unaoonekana kama upotevu wa vipindi badala ya hitilafu safi. Thibitisha kuwa hop inayofuata iko kwenye subneti ya LAN kabla ya kuthibitisha mstari.

Hifadhi jibu baada ya kuunganisha tena

Njia iliyoongezwa kwa mkono hudumu vyema hadi muunganisho unaofuata. Ikiwa bwawa la wateja ni la kubadilika, bandika kwenye usanidi wa seva ili kiambishi awali ulichoelekeza kibaki kuwa kiambishi awali wateja wanachopokea; vinginevyo ingizo linaelekeza kwenye safu tupu na dalili hurudi baada ya wiki bila sababu dhahiri. Kuandika njia kwenye skripti ya up ya mteja mwenyewe ni chaguo lingine la kuaminika, kwa sababu huendeshwa baada ya mteja kuandika jedwali upya.

Firewall ya hali inaweza bado kushinda njia sahihi. Ikiwa ukamataji sasa unaonyesha jibu linatoka kupitia eth0 na mteja bado anapata muda umeisha, angalia kama mwenyeji anatupa pakiti kabla ya kuituma. Uchujaji mkali wa njia ya nyuma na net.ipv4.conf.all.rp_filter iliyowekwa kuwa 1 hutupa pakiti ambazo chanzo chake hakingeelekezwa nyuma kupitia kiolesura kilichoingia, na hiyo ndiyo hali isiyo na ulinganifu uliyounda sasa hivi kisha ukairekebisha, na hali ya conntrack inasimulia hadithi hiyo hiyo kwa bandari zilizosambazwa.

Ukaguzi wa mwisho ni ule ambao watu huuruka: rudia utafutaji baada ya handaki kushuka na kupanda tena. Thamani nne zinapaswa kuendana na ulichoandika: lengwa, hop inayofuata, kifaa na chanzo kilichochaguliwa. Ikiwa moja yao imehamia, mteja ameandika jedwali upya na suluhisho liko kwenye ndoano zake, si kwenye historia ya shell.