Regjistri i korrigjimit të L2TP është bosh? Gabimi ndoshta është në journal

Nis ndihmësin e L2TP me korrigjim, shikon terminalin, dhe ai ndalet pa asgjë të dobishme në ekran. Ky nuk është një flamur korrigjimi i prishur. Një lidhje NetworkManager L2TP është katër procese që bashkëpunojnë, dhe vetëm disa prej tyre shkruajnë në terminalin që po shikon. Pjesa tjetër e provave është në journal, një filtër larg.

Katër procese, dy destinacione regjistri

Lidhja fillon me IPsec, i cili është libreswan ose strongSwan sipas instalimit. Pastaj daemoni L2TP, tradicionalisht xl2tpd dhe në disa ndërtime kl2tpd, drejton tunelin. Në fund pppd merret me vërtetimin dhe adresimin brenda tij.

Shërbimi ndihmës koordinon ato pjesë dhe printon përparimin e vet. Daemoni IPsec dhe pppd zakonisht raportojnë përmes journal-it të sistemit, prandaj terminali tregon një lidhje që dështon ndërsa arsyeja qëndron në një skedar që nuk e keni hapur.

Kjo ndarje shpjegon gjithashtu pse një gabim PSK dhe një gabim fjalëkalimi duken njësoj nga desktopi: të dy prodhojnë një shkëputje gjenerike, dhe faza që dështoi shihet vetëm në daljen e çdo procesi. Kjo është e gjithë arsyeja pse journal-i ka rëndësi këtu. Një mesazh gjenerik në desktop, katër autorë të mundshëm pas tij.

Mblidhni një provë, pastaj lexoni rendin

Riprodhojeni një herë, me një profil të njohur dhe një kohë të njohur, pastaj lexoni një dritare të ngushtë në vend të gjithë nisjes. Përsëritja e provave ndërsa ndryshoni cilësimet e kthen regjistrin në një përzierje që nuk mund të interpretohet.

Këto komanda zgjedhin proceset pjesëmarrëse për nisjen aktuale, dhe rruga e shtojcës ia vlen të konfirmohet në shpërndarjen tuaj:

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

Fushat e përsëritura në një thirrje zgjedhin bashkimin e atyre proceseve, gjë që ruan sekuencën në rend kohor. Në një sistem të bazuar në Debian pyetja ekuivalente është dpkg -L; çështja është të gjesh se ku jeton vërtet ndihmësi përpara se të provosh ta ekzekutosh me dorë.

Tre kushte vendosin hapin tjetër

Lexoni fazën e parë që dështon, pastaj zgjidhni në përputhje. Nëse IPsec raporton një dështim të propozimit ose të vërtetimit të palës tjetër, tuneli nuk u formua kurrë, dhe ndryshimi i fjalëkalimit PPP nuk mund të ndihmojë.

Nëse tuneli u formua dhe pppd refuzoi hyrjen, sekreti i përbashkët ishte tashmë në rregull dhe problemi i kredencialeve është një shtresë më lart. Nëse pppd negocioi një adresë dhe dështimi shfaqet më vonë, të dyja punojnë dhe problemi i mbetur është rrugëzimi, DNS ose politika e vetë serverit.

Këto tre degë mbulojnë pothuajse çdo shkëputje gjenerike, dhe ato vendosen nga procesi që regjistroi gabimin e fundit, jo nga mesazhi i gabimit që duket më alarmues.

Ia vlen të konfirmohet edhe cili backend IPsec është instaluar përpara se të prekni një cilësim korrigjimi. Një opsion regjistrimi i shkruar për strongSwan nuk bën asgjë kur libreswan është në punë, dhe lidhja do të vazhdojë të dështojë në të njëjtin vend ndërsa redaktoni një skedar që askush nuk e lexon.

Modaliteti i korrigjimit lë skedarë

Rrjedha origjinale e korrigjimit ekzekuton shërbimin me dorë me një flamur korrigjimi, dhe ai modalitet mund të lërë skedarët e konfigurimit të kohës së ekzekutimit të gjeneruar në vend kur lidhja përfundon.

Ata skedarë përmbajnë material vërtetimi: çelësin e ndarë paraprakisht, kredencialet ose të dyja. Një konfigurim i gjeneruar i kopjuar në një dritare bisede është një zbulim kredencialesh, jo një fragment regjistri. Hiqni rreshtat sekretë përpara se të shpërndani ndonjë gjë, dhe fshini drejtorinë kur përfundon hetimi. Trajtojini si sekrete, nxirrni rreshtat e saktë që ju nevojiten për një raport dhe fshijini ato më pas, në vend që të ngjitni një drejtori në një biletë.

Shembulli manual duhet të koordinohet gjithashtu me atë normal. Nisja e një kopjeje korrigjimi ndërsa shërbimi tashmë zotëron shtojcën prodhon dy pronarë dhe një regjistër që i përzien të dy, gjë që është më keq se sa asnjë dalje korrigjimi.

Më pas rikthejeni ndihmësin normal

Kur përfundon hetimi, ndaloni shembullin manual, hiqni skedarët e kohës së ekzekutimit të ruajtur dhe rilidheni përmes rrugës normale, në mënyrë që personi tjetër të shohë një konfigurim që përputhet me realitetin.

Pastaj verifikoni rezultatin në shtresën që dështoi, jo te ikona e desktopit:

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

Një sesion që vërteton, merr një adresë dhe rrugëzohet drejt destinacionit të synuar është rezultati që po korrigjonit. Një terminal i qetë gjatë një prove të dështuar ju thotë vetëm ku dalja nuk u shkrua.