Hatua ipi ya VPN ilishindikana: IPsec, udhibiti wa L2TP au uthibitishaji wa PPP

Ulibadilisha nenosiri na hakuna kilichosogea, kwa sababu hitilafu haikuwa kamwe ndani ya PPP. L2TP/IPsec huripoti hitilafu moja ya muunganisho kwa makabidhiano matano tofauti kabisa, na kila kabidhiano lina urekebishaji wake. Fanya kazi kinyume: pata hatua ya mwisho iliyofanikiwa na ubadilishe tu kile kinachofuata. Mpangilio hapa chini pia huamua ushahidi gani unakusanya kwanza.

Jibu maswali manne kwa mpangilio

Lazimisha jaribio jipya, kwa sababu baadhi ya wateja huendelea kuonyesha hitilafu ya awali hadi wasifu utenganishwe na kuunganishwa tena. Kisha jibu hili: je, kulikuwa na muungano wa usalama wa IPsec, je, miunganisho ya udhibiti ya L2TP na simu zilionekana, PPP ilifika uamuzi wa uthibitishaji, na IPCP ilimpa mteja anwani? Hapana ya kwanza ni hatua unayoirekebisha. Kila kitu baada yake hakijajaribiwa, kwa hivyo jina la mtumiaji lililokataliwa halithibitishi chochote wakati muungano haukuwahi kuwepo.

Sawazisha saa za pande zote mbili kabla ya kulinganisha. Jaribio la kurudia lililosafisha IPsec na kushindwa kwenye PPP linaonekana kama hitilafu moja wakati mteja anaonyesha ujumbe wa mwisho pekee na kumbukumbu ya seva bado inashikilia jaribio la awali. Soma kwa muhuri wa muda, si kwa mstari wenye sauti kubwa.

Unapokuwa na picha ya skrini ya mtumiaji pekee, tegemea mgawanyiko wa bei nafuu: ufunguo ulioshirikiwa mapema usio sahihi na xl2tpd isiyojibu kamwe huzalisha maandishi yale yale kwenye kidirisha cha Windows, lakini kimoja kinahitaji siri iliyobadilishwa pande zote mbili na kingine kinahitaji daemon iliyoanzishwa au sheria ya firewall kwenye seva yenyewe. Kifaa cha kati hakiwezi kudondosha 1701 ya ndani baada ya IPsec ya hali ya usafirishaji kuifunga, kwa hivyo usitafute kichujio cha njia ambacho hakipo.

Kila tabaka linamiliki nini kwa kweli

IPsec hulinda pakiti kati ya washirika wawili; L2TP hubeba kikao cha PPP ndani ya njia hiyo iliyolindwa, ndiyo sababu RFC 3193 hubainisha hali ya usafirishaji badala ya handaki yake yenyewe. Lebo ya mteja inasema L2TP, kwa hivyo handaki na kuingia vinaonekana kama utaratibu mmoja. Sivyo: muunganisho wa udhibiti wa L2TP huthibitisha ncha za handaki pale utekelezaji unapoiwezesha, na PPP huthibitisha mtumiaji kwa tofauti kwa CHAP, PAP au MS-CHAPv2 kwa mujibu wa sera ya seva.

Mgawanyiko huo unaeleza siri mbili ambazo watu huendelea kuzichanganya. Ufunguo ulioshirikiwa mapema huthibitisha washirika wa IPsec. Jina la mtumiaji na nenosiri humtambulisha mtumiaji kwa PPP. Kuandika tena siri iliyoshirikiwa ya Windows kwenye wasifu unaothibitisha kwa vyeti hakubadilishi chochote kwenye hatua inayoshindwa, na kuhariri nenosiri la PPP hakuwezi kutoa chaneli iliyolindwa inayokosekana. Kujizuia huko huko kunahusu ukaguzi wa utambulisho: usizime utambulisho wa mshirika au uthibitishaji wa cheti ili kupata handaki, kwa sababu wakati huo kinachounganishwa ni njia, si mshirika.

Uthibitishaji pia si mwisho wa PPP. Baada ya mtumiaji kukubaliwa, IPCP hujadili anwani ya mteja na chaguo za DNS na WINS ambazo seva iko tayari kutoa. Mteja anaweza kupita CHAP au MS-CHAPv2 na bado kuishia bila anwani, jambo ambalo ni hitilafu ndani ya PPP na si tatizo la uelekezaji. L2TP tupu bila IPsec inabaki halali na bila ulinzi, kwa hivyo muunganisho uliofanikiwa hauthibitishi kamwe kwamba trafiki imelindwa; kagua kile seva inacholazimisha, si lebo ya mteja.

Amua kutokana na hatua ya kwanza inayokosekana

Soma jedwali kwa kipengele cha kwanza kinachokosekana, kushoto kwenda kulia. Safu ya kulia ni kazi pekee inayostahili wakati huo; kila kitu kushoto kwake tayari kimethibitishwa, na kuijaribu tena huteketeza dirisha la usumbufu bila kuongeza taarifa.

Safu tatu zinastahili onyo. Safu ya 1701 ni mahali ambapo wateja wa Windows nyuma ya NAT mara nyingi hutua: muungano hukamilika, kisha hakuna kinachofika, na sababu ni ufungashaji si nenosiri baya. Safu ya IPCP ndiyo inayosomwa vibaya kama tatizo la njia, kwa sababu Windows hufunga anwani inayokosekana kwenye hitilafu 720 na aikoni ya trei husema tu kwamba muunganisho umeshindwa; hitilafu hiyo iko baada ya uthibitishaji na kabla ya uelekezaji. Safu ya mwisho si hitilafu ya IPsec hata kidogo, ingawa aikoni inasema imetenganishwa.

Amri zinazotenganisha tabaka

Kwenye seva ya Linux inayoendesha strongSwan, swanctl --list-sas huorodhesha miungano iliyoanzishwa pamoja na utambulisho wa mshirika, na ipsec statusall hushughulikia wenyeji wa zamani wa strongSwan na libreswan. Chini yake ip xfrm state huonyesha miungano halisi ya kernel, wakati ss -lunp | grep 1701 huthibitisha mahali xl2tpd imefungwa. Endesha xl2tpd -D mbele ili kuona miunganisho ya udhibiti na simu, na washa utatuzi wa pppd ndani ya /etc/ppp/options.xl2tpd ili kuona mbinu inayotolewa na jibu.

Kumbukumbu zinapoonyesha uthibitishaji uliofanikiwa, swali linalofuata ni kama IPCP ilikamilika. Kagua kama ip range katika sehemu ya [lns default] ya /etc/xl2tpd/xl2tpd.conf bado ina anwani huru, na kama /etc/ppp/options.xl2tpd kwa kweli hubeba ms-dns na ms-wins ikiwa mteja anazitarajia. Bwawa lililoisha na chaguo la DNS linalokosekana huonekana tofauti kwenye waya: la kwanza humwacha mteja bila anwani na akiwa na 720, la pili hutoa anwani lakini hakuna kutatuzi, kwa hivyo majina hushindwa wakati ping kwa anwani mbichi inafanya kazi. Hakuna hata moja linalorekebishwa kwa kuandika nenosiri tena.

Kwenye mteja, programu jalizi ya L2TP ya NetworkManager huandika mazungumzo ya pppd kwenye jarida, kwa hivyo journalctl -u NetworkManager -b kwa kawaida hutenganisha handaki juu, uthibitishaji umekataliwa na hakuna handaki kabisa. Kwenye Windows, Get-VpnConnection huripoti mipangilio halisi ya uthibitishaji wa wasifu, na matukio ya RasClient chini ya Application kwenye Event Viewer hutaja sehemu inayoshindwa. Kidirisha kinapokuwa kisisisi mno, washa netsh ras set tracing * enable.

Unasaji unahitaji tahadhari moja. Kwa IPsec ya hali ya usafirishaji, UDP 1701 ya ndani imesimbwa, kwa hivyo unasaji kwenye kiolesura cha nje huonyesha ESP, au UDP 4500 chini ya NAT-T, na hakuna L2TP kabisa. Kukosekana kwa 1701 kwenye unasaji kunatarajiwa na si uthibitisho wa bandari iliyozuiwa; angalia kama vihesabu vya ESP au 4500 vinasogea.

NAT, MTU na njia: mahali stack inakupotosha

NAT huvunja dhana kabla kitu chochote hakijathibitishwa. ESP ni itifaki yake ya IP, kwa hivyo kifaa kinachotafsiri hukitupa isipokuwa washirika wafunge ndani; UDP 4500 ndiyo inayotoa hilo. Kwenye seva ya Windows inayosimama yenyewe nyuma ya rauta ya nyumbani au lango la NAT la wingu, hatua ya IPsec hushindwa kwa hitilafu 789 hadi AssumeUDPEncapsulationContextOnSendRule iwekwe kuwa 2 chini ya ufunguo wa PolicyAgent na mashine ianzishwe upya, na hitilafu inabaki isiyotofautishwa na bandari iliyofungwa. Wateja nyuma ya NAT ni rahisi: kukiwa na anwani ya umma kwenye seva, NAT-T kwenye UDP 4500 huwabeba na thamani hiyo haihusiki.

PPP ikiwa juu, MTU yenye shimo jeusi huiga handaki lililokufa: pakiti ndogo hupita, kupeana mikono kwa TLS au upakiaji wa ukurasa huning'inia, na mteja anaweza bado kuonyesha ameunganishwa. Punguza MTU ya kiolesura au banwa MSS kwenye lango kabla ya kulaumu seva. Uelekezaji wa handaki lililogawanyika ni mdanganyifu mwingine; subneti inayosukumwa kwa kifuniko kibaya huiacha handaki likiwa zuri na programu moja isifikike. Jina la mwenyeji la kibinafsi huongeza hatua yake: ikiwa swali linatoka kupitia kitatuzi cha ndani, jina linashindwa kutafsiriwa kabla ya njia yoyote kujaribiwa.

Orodha ya ukaguzi kabla ya kugusa vitambulisho

Fanyia kazi orodha kwa mpangilio na usimame kwenye kipengele cha kwanza kinachoshindwa. Kila hatua ni nafuu, na kila moja huondoa tabaka zima la marekebisho.

1. Thibitisha kuwa muungano upo pande zote mbili, ukilinganishwa kwa utambulisho wa mshirika na si lebo ya kimeunganishwa.
2. Thibitisha kuwa UDP 1701 inafika xl2tpd; muungano bila simu ndiyo hitilafu yako.
3. Soma uamuzi wa PPP na, ikiwa ulithibitisha, matokeo ya IPCP, kabla ya kudhani nenosiri si sahihi.
4. Sasa tu andika tena vitambulisho katika umbizo ambalo seva inatarajia, kwa sababu kiambishi cha kikoa hubadilisha akaunti.
5. Ikishindwa bado, nasa pande zote mbili kwa mihuri ya muda iliyooanishwa na linganisha hatua kwa hatua.

Kusimama kwenye hatua ya pili kunamaanisha tatizo la njia au ufungashaji, na hakuna uhariri wa nenosiri utakaolisogeza. Kusimama kwenye hatua ya tatu kunamaanisha kumbukumbu tayari inataja mbinu au bwawa la anwani la kurekebishwa. Vyovyote vile, badiliko linalofuata ni lile unaloweza kuhalalisha, na unaacha kuzunguka mipangilio ambayo haikuhusika kamwe.