Walang laman ang debug log ng L2TP? Malamang nasa journal ang error

Sinisimulan mo ang L2TP helper na may debugging, tumitingin sa terminal, at humihinto ito nang walang anumang kapaki-pakinabang sa screen. Hindi ito sira na debug flag. Ang koneksyon ng NetworkManager L2TP ay apat na prosesong nagtutulungan, at ilan lamang sa kanila ang nagsusulat sa terminal na pinapanood mo. Ang natitirang ebidensya ay nasa journal, isang filter ang layo.

Apat na proseso, dalawang destinasyon ng log

Nagsisimula ang koneksyon sa IPsec, na libreswan o strongSwan depende sa pag-install. Pagkatapos ay pinapatakbo ng L2TP daemon, ayon sa kaugalian xl2tpd at sa ilang build kl2tpd, ang tunnel. Sa huli, pinangangasiwaan ng pppd ang authentication at addressing sa loob nito.

Kinokoordina ng helper service ang mga bahaging iyon at nagpi-print ng sariling progreso. Karaniwang nag-uulat ang IPsec daemon at pppd sa pamamagitan ng system journal, kaya nagpapakita ang terminal ng koneksyong nabibigo habang ang dahilan ay nasa file na hindi mo binuksan.

Ipinapaliwanag din ng paghahating iyon kung bakit magkamukha ang PSK error at password error mula sa desktop: pareho silang gumagawa ng pangkalahatang paghinto, at ang yugtong nabigo ay makikita lamang sa output ng bawat proseso. Iyon ang buong dahilan kung bakit mahalaga ang journal dito. Isang pangkalahatang mensahe sa desktop, apat na posibleng may-akda sa likod nito.

Mangolekta ng isang pagtatangka, pagkatapos ay basahin ang pagkakasunod-sunod

Ipatupad muli nang isang beses, gamit ang kilalang profile at kilalang oras, pagkatapos ay basahin ang makitid na window sa halip na ang buong boot. Ang paulit-ulit na pagtatangka habang binabago ang mga setting ay ginagawang halo ang log na hindi maipaliwanag.

Pinipili ng mga command na ito ang mga kalahok na proseso para sa kasalukuyang boot, at sulit na kumpirmahin ang path ng plugin sa iyong distribution:

journalctl -b --no-hostname _COMM=nm-l2tp-service _COMM=pluto _COMM=charon _COMM=xl2tpd _COMM=pppd
rpm -ql NetworkManager-l2tp 2>/dev/null | grep nm-l2tp-service

Pinipili ng mga paulit-ulit na field sa isang invocation ang unyon ng mga prosesong iyon, na nagpapanatili ng pagkakasunod-sunod sa pagkakasunod-sunod ng oras. Sa sistemang nakabatay sa Debian ang katumbas na query ay dpkg -L; ang punto ay hanapin kung saan talaga nakatira ang helper bago subukang patakbuhin ito nang manu-mano.

Tatlong kundisyon ang nagpapasya sa susunod na hakbang

Basahin ang unang yugtong nabigo, pagkatapos ay pumili ayon doon. Kung nag-uulat ang IPsec ng kabiguan sa proposal o sa peer authentication, hindi kailanman nabuo ang tunnel, at hindi makakatulong ang pagpapalit ng PPP password.

Kung nabuo ang tunnel at tinanggihan ng pppd ang pag-login, maayos na ang shared secret at ang problema sa credentials ay isang antas sa itaas. Kung nag-negosasyon ang pppd ng address at mamaya lumitaw ang kabiguan, gumagana ang dalawa at ang natitirang problema ay routing, DNS o ang sariling patakaran ng server.

Saklaw ng tatlong sangay na iyon ang halos lahat ng pangkalahatang paghinto, at napagpapasyahan ang mga ito ng kung aling proseso ang nag-log ng huling error, hindi ng kung aling mensahe ng error ang pinaka-nakakabahala.

Sulit din na kumpirmahin kung aling IPsec backend ang naka-install bago hawakan ang isang setting ng debugging. Ang opsyon sa pag-log na isinulat para sa strongSwan ay walang ginagawa kapag tumatakbo ang libreswan, at patuloy na mabibigo ang koneksyon sa parehong lugar habang ine-edit mo ang file na walang binabasa.

Nag-iiwan ng mga file ang debug mode

Ang orihinal na workflow ng debugging ay manu-manong nagpapatakbo ng serbisyo na may debug flag, at ang mode na iyon ay maaaring mag-iwan ng mga nabuong runtime configuration file sa lugar kapag nagtapos ang koneksyon.

Naglalaman ang mga file na iyon ng materyal sa authentication: ang pre-shared key, credentials o pareho. Ang nabuong configuration na kinopya sa chat window ay pagbubunyag ng credentials, hindi sipi ng log. Alisin ang mga linyang lihim bago magbahagi ng anuman, at tanggalin ang direktoryo kapag natapos ang pagsisiyasat. Ituring ang mga ito na lihim, kunin ang partikular na mga linyang kailangan mo para sa ulat, at tanggalin ang mga ito pagkatapos sa halip na i-paste ang direktoryo sa isang ticket.

Ang manu-manong instance ay kailangan ding iugnay sa normal. Ang pagsisimula ng debug copy habang pagmamay-ari na ng serbisyo ang plugin ay gumagawa ng dalawang may-ari at isang log na humahalo sa dalawa, na mas malala kaysa sa walang anumang debug output.

Pagkatapos ay ibalik ang normal na helper

Kapag natapos ang pagsisiyasat, ihinto ang manu-manong instance, alisin ang mga napanatiling runtime file at muling kumonekta sa normal na landas upang makita ng susunod na tao ang configuration na tumutugma sa katotohanan.

Pagkatapos ay i-verify ang resulta sa layer na nabigo, hindi sa icon ng desktop:

journalctl -b -u NetworkManager --since -10min | tail -30
ip -4 addr show ppp0
ip -4 route get 10.20.4.10

Ang sesyong nagpapatunay, tumatanggap ng address at nagru-ruta patungo sa nilalayong destinasyon ang resultang dini-debug mo. Ang tahimik na terminal sa panahon ng bigong pagtatangka ay nagsasabi lamang sa iyo kung saan hindi naisulat ang output.