Kumokonekta ang L2TP pero nabibigo ang PPP negotiation: aling yugto?

Naitatayo ang IPsec tunnel, nagpapakita ang kliyente ng protektadong peer, at pagkatapos ay namamatay ang koneksyon bago pa may makarating sa pribadong subnet. Ang puwang na iyon ay ang PPP na ginagawa ang sarili nitong trabaho: ang mga opsyon ng link, pagpapatotoo ng user at pagtatalaga ng address ay nangyayari pagkatapos na umiiral ang naka-encrypt na tunnel. Walang anuman sa matagumpay na pagpapalitan ng unang yugto ang nagbibigay ng password o panloob na address. Basahin ang mga yugto nang sunud-sunod at karaniwang ipinapangalan ng pagkabigo ang sarili nito.

Ang tunnel ay ang unang patong lamang

L2TP nagdadala ng PPP frames sa loob ng tunnel na protektado ng IPsec, ibig sabihin, dalawang magkahiwalay na negosasyon ang dapat magtagumpay bago ma-route ang isang packet. Ang panlabas ay nagpapatunay na magkasundo ang dalawang dulo sa mga key at pagkakakilanlan. Ang panloob ay nagpapasya sa mga parameter ng link, kung napapatotohanan ang user at kung anong address ang natatanggap ng kliyente.

Ang pagkabigo sa loob ng PPP ay mukhang sirang tunnel sa bawat kliyenteng nagpapakita ng isang status light lamang. Kung ituturing itong problema ng tunnel, hahantong ito sa muling paggawa ng mga key, pag-restart ng mga serbisyo at sa huli sa pagpapalit ng shared secret na hindi kailanman nagkamali. Ang kapaki-pakinabang na pagkakaiba ay mura: kung natapos ang pagpapalitan sa peer at lumipat ang kliyente sa hiling ng username o sa yugto ng pagpapatotoo, maayos ang tunnel. Lahat ng sumunod sa puntong iyon ay pag-aari ng PPP.

Basahin ang huling yugtong nagtagumpay

Sundan ang log pasulong at huminto sa unang yugtong hindi natapos. Una ang LCP, pagkatapos ang pagpapatotoo, pagkatapos ang IPCP para sa mga parameter ng IPv4.

sudo journalctl -u xl2tpd -b --no-pager | tail -n 40
sudo journalctl -b --no-pager | grep -i -E 'pppd|lcp|chap|ipcp'
ip -4 address show ppp0

Ang timeout ng LCP ay nangangahulugang hindi kailanman nagkasundo ang dalawang dulo sa mga pangunahing opsyon ng link, na hindi maling password kundi hindi tugmang profile o naka-block na panloob na protocol. Ang tahasang pagtanggi sa pagpapatotoo ay ang kabaligtaran: umangat ang link at tinanggihan ng isang panig ang mga kredensyal. Ang timeout ng IPCP pagkatapos ng matagumpay na pagpapatotoo ay tumutukoy sa mga pool ng address o patakaran ng server. Bawat isa sa kanila ay may ibang may-ari at ibang pag-aayos, kaya mas mahalaga ang yugto kaysa sa huling teksto ng error.

Itago ang sipi ng log kasama ang pangalan ng yugto sa ticket. Ang nakadikit na buntot na walang hangganan ng yugto ay nag-aanyaya sa susunod na mambabasa na manghula, at ang manghula dito ay kumakain ng isang oras.

Pagkakasundo ng kliyente at server

Dapat tanggapin ng dalawang dulo ang parehong paraan ng pagpapatotoo, at ang naka-save na profile ay maaaring humiling ng isang itiniwalag ng server noong nakaraang quarter. Itinatago rin ng mga pinamamahalaang deployment ang panig ng server, kung saan ang dahilan ng pagtanggi ay karaniwang naitala sa user at hindi sa device.

Paganahin ang isang suportadong paraan sa halip na bawat lumang opsyon, dahil ang kliyenteng nag-aalok ng limang paraan ay nagtatakip kung alin ang nabigo. Hilingin sa administrator ang patakaran sa panig ng server at ang eksaktong pagtanggi, na hindi nangangailangan na may maglathala ng password. Ang lumang paraang ginagana para iligtas ang isang kliyente ay may tendensiyang kumalat sa bawat profile na kumokopya ng file.

Beripikahin ang address, hindi ang pag-login

Ang natapos na pag-login ay hindi magagamit na session. Pinag-uusapan ng IPCP ang panloob na address, at ang naubos na pool o patakarang tumatanggi sa kliyente ay maaari pa ring mag-iwan ng konektadong tunnel na walang maaaring i-route.

ip -4 address show ppp0
ip route get 10.52.9.1
ping -c 2 10.52.9.1

Suriin muna ang panloob na address, pagkatapos ang ruta at resolver para sa resource na talagang kailangan mo. Ang panloob na address ay hindi ang pampublikong labasan na iniuulat ng isang website, at ang pagkalito sa dalawa ay nagpapadala ng mga tao sa paghahanap ng tagas na wala naman. Subukan ang pribadong resource sa address bago sa pangalan, upang ang pagkabigo ng DNS ay hindi mapagkamalang pagkabigo ng routing.

Isulat ang yugto, paraan at address sa isang tala at lagyan ito ng petsa. Kung mabibigo muli ang parehong account sa loob ng isang buwan, ang talang iyon ang pagkakaiba ng limang minutong pagsusuri at bagong imbestigasyon. Ang mga pagkabigo sa iba't ibang yugto ay iba't ibang insidente, kahit isang dialog lamang ang ipinapakita ng kliyente.