Kiingilio cha pili cha WAN VPN kinashindwa wakati cha msingi bado kinafanya kazi

Handaki kuu linabaki wazi, watumiaji wanaendelea kufanya kazi, na mzunguko wa pili wa ISP unakaa bure bila kujali unabadilisha nini. Ulichapisha anwani ya mzunguko wa akiba, ukaelekeza jina kwake, labda ukaongeza kiingilio cha akiba kwenye mteja, na mteja ama hajaribu kamwe au anathibitisha na kisha anakufa. Katika kesi nilizofuatilia, kipengele cha uhamisho kwa kawaida kilikuwa sawa; kilichokosekana kilikuwa kimoja cha mambo matano yanayofanya kiingilio kutumika. Jina linaweza kutatuliwa hadi anwani ya akiba wakati hakuna kinachosikiliza kwenye kiolesura hicho, na kisikilizaji kinaweza kukubali muunganisho wakati jibu linatoka kupitia cha msingi. Chukulia kila WAN kama kiingilio tofauti chenye mkataba wake, na hitilafu itaacha kuonekana kama mdudu wa mteja.

Kila WAN inahitaji mkataba wake wa kiingilio

Rekodi sehemu tano kwa kila WAN: jina na anwani ya umma, usafirishaji na bandari, kiolesura au muktadha unaoikamilisha, utambulisho wa mwenzake unaopaswa kuonyesha, na mahali jibu linatoka. Mizunguko miwili inamaanisha seti mbili kamili. Ikiwa seti ya pili haina kiolesura cha kumaliza au haina njia ya kurudi, huna kiingilio cha akiba; una rekodi ya DNS inayoeleza nia.

Kifaa na toleo lake pia lazima viunge mkono mpangilio huu. Rekodi ya DNS haiwezi kufungua huduma kwenye kiolesura kingine, na kwenye majukwaa mengi kisikilizaji husanidiwa kwa anwani badala ya kifaa. IPsec inayotegemea kiolesura kwenye ASA inafunga ramani za crypto na vikundi vya handaki kwenye kiolesura cha nje, kwa hivyo kiunganishi cha pili kinahitaji sera mahali ambapo pakiti hizo zinafika kwa kweli. Miundo inayotegemea njia hufanya tofauti: kisikilizaji kinaweza kushikamana na kila anwani au anwani moja iliyotajwa, na chaguo hilo huamua kama ISP B inaweza kujibu kabisa.

Hakikisha WAN ya pili inajibu kweli

Jaribu kutoka nje ya mizunguko yote miwili, si kutoka kwa mashine iliyo nyuma ya lango, na jaribu jina kamili ambalo wasifu wa mteja unatumia. Kwa kisikilizaji cha TLS, ukaguzi wa haraka ni openssl s_client -connect ADDRESS:443 -servername vpn.example.com -showcerts unaoendeshwa kutoka kwa mwenyeji nje ya mtandao wako. Unataka makubaliano ya mkono yaliyokamilika ambayo mnyororo wake unalingana na jina katika wasifu, si bandari ya TCP inayokubali muunganisho pekee.

RFC 9525 inaeleza kile mteja anachokagua: utambulisho aliokusudia kufikia, ukilinganishwa na cheti ambacho huduma inawasilisha. Kiingilio cha pili kinachorudisha cheti cha kiingilio cha msingi, au cheti chaguo-msingi kisichoorodhesha jina lolote, kinashindwa jaribio hili ingawa bandari iko wazi na ngome inairuhusu.

Mifumo miwili inaeleza hitilafu nyingi hapa. Muunganisho unaoning'inia kwa kawaida humaanisha hakuna kisikilizaji kwenye kiolesura hicho, kanuni ya ufikiaji inayoruhusu subnet za msingi pekee, au kifaa cha mtoa huduma mbele ya mzunguko wa pili kinachoacha bandari. Makubaliano ya mkono yanayomalizika na utambulisho usiofaa kwa kawaida humaanisha sehemu nyingine ya uaminifu, mwenyeji pepe chaguo-msingi, au usanidi ulionakiliwa kutoka wa msingi bila kurekebisha utambulisho.

Fuatilia jibu, si ombi pekee

WAN ya pili kwa kawaida huvunjika njiani kurudi. Ombi hufika kwa ISP B, kifaa kinajibu, na jibu linatoka kupitia njia chaguo-msingi kwa ISP A likiwa na anwani ya chanzo ambayo mteja hakuwahi kuomba. Tafsiri yenye hali huifanya kuwa mbaya zaidi: ikiwa ramani ilijengwa kwa kiolesura cha msingi, pakiti inayorudi inakosa tafsiri au hubeba chanzo ambacho ngome ya mteja inatupa. Watoa huduma pia hutupa anwani za chanzo zisizomilikiwa na mzunguko waliokupa, ndiyo sababu hii inaonekana kama shimo jeusi la upande mmoja badala ya hitilafu safi ya itifaki.

Kagua uamuzi wa uelekezaji kwa trafiki inayotoka kwenye kiingilio cha pili. Jibu linapaswa kutoka kwenye kiolesura ambacho ombi lilifika, au angalau kubeba anwani ambayo upande wa mbali unakubali kama ya njia hiyo. Kwenye majukwaa ya uelekezaji wa sera, hiyo inamaanisha kanuni iliyofungwa kwa kiolesura kinachoingia au chanzo kilichotafsiriwa, pamoja na taarifa ya tafsiri iliyofungwa kwa kila kiolesura cha nje. Nasa kwenye violesura vyote viwili kwa wakati mmoja wakati mteja anajiunga; SYN inayofika kwa ISP B na SYN-ACK inayotoka kwa ISP A hutatua swali katika mbio moja.

Mpe mteja njia ya kujua kuhusu kiingilio cha pili

Uhamisho ni uamuzi wa upande wa mteja, na kila familia ya wateja hujifunza kuhusu njia mbadala kwa namna tofauti. Kwenye ASA, orodha ya seva za akiba huwasilishwa kupitia sifa za webvpn za sera ya kikundi, wakati wateja wengine wanatarajia orodha ndani ya wasifu au wasifu wa pili wa mwongozo ambao mtumiaji huchagua. Mwongozo wa sera za muunganisho wa Cisco unaeleza taarifa za akiba zilizosanidiwa na mteja na zile zinazotolewa na lango, na maelezo hayo mahususi kwa itifaki hayapaswi kujumlishwa kwa kila mteja au hali ya handaki. Thibitisha ni utaratibu gani mteja aliyesambazwa anautekeleza kabla ya kujenga kiingilio cha pili kuzunguka ule usiofaa.

Utaratibu wowote, mteja lazima aweze kutatua jina mbadala kabla ya kupoteza njia ya msingi. Utegemezi huo ndio watu wanaukosa: ikiwa jina la akiba linajibiwa na kitatuzi kinachofikiwa tu kupitia handaki lililoshindwa hivi punde, akiba haiwezi hata kuanza. Chapisha jina la pili katika kitatuzi kinachojibu ndani au kupitia mtandao. Tarajia uthibitishaji mpya na kipindi kipya cha programu baada ya kuhamia, kwa sababu uhamisho wa mteja si uhamisho wenye hali na vipindi vya muda mrefu havistahimili.

Anwani moja kwa watoa huduma wawili ni bidhaa tofauti

Kuweka anwani moja ya umma ikifikiwa kupitia mizunguko yote miwili ni huduma ya uelekezaji, si kisanduku cha kuteua kwenye VPN. Inahitaji nafasi ya anwani ambayo watoa huduma wote wawili wako tayari kuibeba, ikitangazwa kwa namna ambayo mitandao yao inakubali, na hiyo ndiyo inayotolewa na multihoming yenye nafasi isiyotegemea mtoa huduma na BGP. Kugawa anwani ya ISP A kwa kiolesura cha ISP B hakukupeleki huko; pakiti inafika kwenye mtandao ambao haukuwahi kutangaza kiambishi hicho na hutupwa juu ya mkondo.

Huhitaji chochote kati ya hivyo ili kuchapisha viingilio viwili. Ikiwa mteja anaweza kushikilia majina mawili na kuhamishwa kati yao, viingilio viwili huru vinatosha, na unaepuka namba ya AS, mpangilio wa peering, na kiambishi kinachopaswa kukubaliwa kila mahali. Fikiria chaguo la anwani inayobebeka tu unapohitaji kwa kweli sehemu moja thabiti ya kuingia ambayo wateja hawawezi kusanidiwa upya kuibadilisha, au wakati uhamisho unaotegemea DNS wenye ucheleweshaji wa TTL ukiwa wa polepole mno kwa hitilafu unayounda.

Nini cha kukagua baadaye

Fanya kazi kuelekea nje kutoka kiingilio kinachoshindwa kwa mpangilio huu: anwani ya pili inajibu kutoka nje, inawasilisha utambulisho ambao mteja anatarajia, jibu linatoka kwa njia ambayo ombi lilifika, na mteja anaweza kujifunza jina kabla ya kulihitaji. Mahali jibu ni hapana, rekebisha tabaka hilo na ujaribu tena na wasifu uliosambazwa badala ya mwenyeji wa jaribio, kwa sababu makubaliano ya mkono kutoka maabara yanathibitisha kidogo kuliko muunganisho uliokamilika kutoka kwa mteja halisi.

Weka rekodi fupi kwa kila WAN, ikiwa na anwani, bandari, kiolesura cha kumaliza, jina la cheti, njia ya kurudi na kanuni ya tafsiri, na uikague tena kila mzunguko, kifaa cha NAT au toleo la mteja linapobadilika. Njia za akiba zisizotumika huoza kimyakimya: hakuna kinachotoa tahadhari kuhusu kiingilio ambacho hakuna anayetumia hadi siku ambayo kila mtu anakitumainia.