Nabigo ang L2TP/IPsec: ihiwalay ang IPsec, pagpapatotoo ng tunnel o PPP login

Tatlong bagay ang nagpapatunay sa loob ng isang koneksyon ng L2TP/IPsec, at isa lamang sa kanila ang may kinalaman sa taong tumatawag. Pinatutunayan ng IPsec ang mga dulo ng tunnel, maaaring muling patunayan ng koneksyon sa kontrol ng L2TP ang mga kapares gamit ang sarili nitong lihim, at pagkatapos ay pinatutunayan ng PPP ang account ng gumagamit sa loob ng sesyon. Ang kabiguan sa alinmang yugto ay mukhang pangkalahatang error sa pag-login sa diyalogo ng kliyente at mukhang lubos na iba sa log ng server. Daanan ang mga yugto nang sunod-sunod at huminto sa unang nabigo, dahil ang bawat yugto sa ilalim ng hindi pa nasubok ay hindi rin nasubok.

Tatlong yugto ng pagpapatotoo, tatlong magkaibang pagkakakilanlan

Pinatutunayan ng IPsec kung kanino ang mga dulo, gamit ang isang paunang ibinahaging susi o isang sertipiko. Ang pagkakakilanlang iyon ay pag-aari ng mga makina o gateway, hindi kailanman ng taong nasa keyboard. Kapag hindi magkasundo ang mga kapares sa yugtong ito, walang packet ng L2TP na ipinagpapalitan.

Maaaring magdagdag ang koneksyon sa kontrol ng L2TP ng pangalawa at hiwalay na palitan ng hamon-sagot, na pinapatakbo ng isang ibinahaging lihim na dapat taglayin ng dalawang dulo.

Ginagawang opsyonal ng RFC 2661 ang pagpapatotoo ng koneksyon sa kontrol, na nagpapaliwanag kung bakit ang parehong pagkakamali ay nagdudulot ng magkaibang sintomas sa dalawang server. Ang deployment na hindi kailanman nag-configure ng lihim ng tunnel ay lumalaktaw sa yugto nang buo; ang nag-configure nito sa isang panig lamang ay nabigo bago pa man ialok ang PPP. Pagkatapos ay pinatotohanan ng PPP ang gumagamit gamit ang PAP, CHAP o MSCHAPv2 at ibinibigay ang pangalan sa isang imbakan ng account na maaaring lokal, sa chap-secrets o sa RADIUS. Ang maling password sa puntong iyon ay nag-iiwan pa rin sa iyo ng gumaganang tunnel at nabigong sesyon.

Basahin ang punto ng paghinto bago i-edit ang isang configuration

Magsimula sa ipsec --version upang malaman kung ang output ng status ay ng strongSwan o ng Libreswan. Pagkatapos ay basahin ang log ng server, hindi ang diyalogo ng kliyente, dahil itinatala ng server kung aling yugto ang tumanggi.

Isang linya ang karaniwang nagtatapos ng ticket: ang reklamo tungkol sa IKE o mga panukala ay unang yugto, ang mensahe tungkol sa koneksyon sa kontrol ay ikalawang yugto, at ang pagtanggi ng paraan ng PPP o account ay ikatlong yugto. Kopyahin ang linyang iyon sa ticket kasama ang timestamp. Ang paghula mula sa panig ng kliyente ay nagsasayang ng nag-iisang ebidensya na mayroon ka na.

Ilayo ang materyal ng susi at mga password sa paste na iyon; ang pangalan ng yugto ang nagtuturo ng trabaho, at ang tumagas na paunang ibinahaging susi ay muling nagbubukas ng ticket na may mas masamang kahihinatnan.

Unang yugto: may asosasyon ba ang IPsec?

Patakbuhin ang ipsec statusall sa strongSwan o ipsec whack --status sa Libreswan at maghanap ng naitatag na child association na may mga counter na hindi zero. Ipinapakita ng ip xfrm state ang pananaw ng kernel sa dalawa. Ang naka-install na pares ng SA na tumataas ang mga counter ay nangangahulugang tapos na ang unang yugto at maaari kang magpatuloy.

Ang ganap na kawalan ng asosasyon ay tumuturo sa address ng kapares, sa hanay ng mga panukala o sa paunang ibinahaging susi, at kung minsan sa isang device na nagsusulat muli ng UDP 500 habang inihuhulog ang UDP 4500. Ang asosasyong naitatag at pagkatapos ay nawala pagkalipas ng ilang segundo ay karaniwang hindi tugma sa tagal ng buhay sa pagitan ng dalawang dulo at hindi problema sa kredensyal. Tingnan kung pareho ang nakalista na mga panukala sa encryption at hash sa magkabilang panig bago mag-type muli ng anuman. Kung hindi, walang susi ang gagana kailanman.

Huminto habang kulang ang asosasyon. Ang pag-edit ng mga opsyon ng PPP sa puntong iyon ay walang binabago at itinatago ang tunay na depekto sa susunod na tao.

Ikalawang yugto: nagpatotoo ba ang koneksyon sa kontrol ng L2TP?

Kapag nakaupo na ang IPsec, bantayan ang daemon ng L2TP para sa koneksyon sa kontrol na umaabot sa naitatag na estado, dahil hindi makapagsimula ang PPP bago iyon. Ang pagtanggi sa koneksyon sa kontrol ay nangangahulugang magkaiba ang lihim ng tunnel sa mga dulo, o hinihingi ng isang dulo ang lihim na hindi kailanman ipinapadala ng isa. Madalas magpakita ang mga kliyente ng isang field na may label na shared secret, at karaniwang pag-aari ito ng IPsec at hindi ng L2TP. Ang pagpuno nito ay hindi nag-configure ng lihim ng tunnel, at ang paglilinis nito ay hindi ito hindi pinapagana.

Kung wala sa dalawang panig ang nag-configure ng lihim ng tunnel, laktawan ang yugtong ito at ituring ang kabiguan ng koneksyon sa kontrol bilang problema sa maabot. Kumpirmahin na umaabot ang UDP 1701 sa daemon at nagkakasundo ang dalawang dulo sa parehong encapsulation. Ang tuntunin ng firewall na isinulat para sa isa sa dalawang kundisyong iyon ay karaniwang dahilan ng koneksyong kalahating bumubukas.

Tanging ang sesyong nagsisimulang makipagnegosasyon sa PPP ang tunay na nakalampas sa yugto ng tunnel.

Ikatlong yugto: tinatanggihan ba ng PPP ang account?

Iba ang hitsura ng kabiguan ng PPP sa labas: naitatag ang tunnel, nagsisimula ang sesyon, at itinatala ng daemon ang kabiguan ng paraan ng pagpapatotoo o pagtanggi ng account. Basahin ang paraang pinangalanan sa mensaheng iyon. Nabibigo ang PAP at CHAP sa magkaibang dahilan, at ang server na tumatanggi sa isa ay tatanggihan ang kliyenteng nag-aalok lamang niyon.

Sa isang server ng Linux, siyasatin ang file ng mga opsyon na ibinibigay ng daemon sa PPP, karaniwang /etc/ppp/options.xl2tpd, at kumpirmahin kung aling mga paraan ang tinatanggap at saan nareresolba ang mga account. Ang pangalang umiiral sa RADIUS ngunit wala sa lokal na file ng mga lihim ay nabibigo nang malinis at mukhang maling password. Pagkatapos ay tingnan kung ang kliyente ay nag-aalok ng paraang tinatanggap ng server, hindi ng mas malakas na tinatanggihan ng server na makipagnegosasyon. Ang pagpapalit ng paunang ibinahaging susi upang ayusin ang yugtong ito ay nagsasayang ng isang hapon at walang binabago.

Kapag sa wakas ay bumangon ang sesyon, pagtatalaga ng address, DNS at mga ruta ay hindi pa nasusuri, at ang bawat isa ay tahimik na nabibigo sa sarili nitong paraan. Panatilihing hiwalay ang tatlong patong sa iyong mga tala: ang tamang susi na may maling account ay laging nabibigo, at ang pag-aayos ng isang patong ay hindi kailanman nag-aayos ng isa pa.