L2TP NO_PROPOSAL_CHOSEN: cila fazë dështoi në të vërtetë?

NO_PROPOSAL_CHOSEN arrin përpara se të ekzaminohet çdo emër përdoruesi PPP, që është një fakt i dobishëm dhe njëkohësisht arsyeja pse mesazhi çon në gabim. Ai raporton se njëra palë refuzoi një propozim; nuk raporton cili parametër nuk përputhej dhe nuk thotë asgjë për atë nëse refuzimi ndodhi gjatë ndërtimit të asociimit IKE apo më vonë, gjatë negociimit të mbrojtjes së trafikut. Pas këtyre dy mundësive qëndrojnë dy korrigjime të ndryshme, dhe vetëm njëra prej tyre përfshin kutinë e PFS që njerëzit i drejtohen së pari.

Një mesazh, dy grupe propozimesh

Rregullimi IKEv1 L2TP/IPsec ka dy negocime me radhë. Faza 1 ndërton asociimin e sigurisë IKE nga një algoritëm kriptimi, një algoritëm integriteti dhe një grup Diffie-Hellman. Më pas faza 2 negocion se si mbrohet trafiku, dhe kërkesa për PFS i përket pikërisht asaj bisede të dytë.

Meqenëse fazat janë të njëpasnjëshme, vendi i dështimit ju tregon cilën listë të krahasoni. Këtu qëndron e gjithë vlera diagnostike e mesazhit, dhe ia vlen ta nxirrni përpara se të prekni ndonjë cilësim.

Pse një kuti PFS nuk mund të rregullojë fazën 1

Çaktivizimi i PFS ndryshon një veti të fazës 2. Nëse palët nuk ranë kurrë dakord për fazën 1, biseda ESP nuk ndodh fare, prandaj kutia nuk ka asnjë efekt në refuzim, dhe për këtë arsye ndryshimi i saj prodhon të njëjtin gabim me një vulë tjetër kohe.

Gabimi i kundërt është po aq i shpeshtë. Një asociim IKE i suksesshëm nuk provon që propozimi ESP është i pranueshëm dhe sigurisht nuk provon që grupi i fazës 2 përputhet. Trajtoni një tunel administrimi të vendosur si provë vetëm për fazën 1. Njerëzit e lexojnë rreshtin e gjelbër si «tuneli është lart» dhe pastaj kalojnë një orë në fazën e gabuar, sepse asgjë nuk u tha se negocimi i dytë nuk kishte filluar.

Lexoni regjistrin përpara se të zgjidhni algoritmet

Mblidhni mesazhet menjëherë përpara refuzimit nga backend-i që trajton vërtet lidhjen dhe korrelojini me të njëjtin përpjekje. Pa atë korrelacion po lexoni historikun e një lidhjeje tjetër dhe po nxirrni përfundime prej tij.

journalctl -b -u NetworkManager --since "10 min ago"
ipsec statusall          # strongSwan
ipsec whack --status     # Libreswan

Nga ato rreshta, përgjigjuni dy pyetjeve: a u vendos një asociim i fazës 1, dhe cili shkëmbim dështoi. Këto dy përgjigje e ngushtojnë kërkimin në një listë të vetme atributesh. Një njoftim i zhveshur pa kontekst përreth nuk mund ta bëjë këtë, sado joshëse të jetë të provoni një propozim nga një temë forumi. Kopjimi i një vargu që funksionon nga një makinë me një backend tjetër zakonisht zëvendëson një refuzim me një tjetër, pak më vonë.

Sintaksa e backend-it nuk udhëton

Shënoni versionin e NetworkManager-l2tp dhe versionin e backend-it IPsec përpara se të krahasoni çdo gjë. Libreswan dhe strongSwan nuk ndajnë sintaksë propozimesh as grupe algoritmesh identike, prandaj një varg që funksionon në njërin është gabim sintakse në tjetrin. Backend-i i instaluar mund të refuzojë gjithashtu IKEv1 sipas politikës, dhe atëherë asnjë propozim nuk do të pranohet kurrë.

README i projektit dokumenton ato dallime midis backend-eve dhe i mban të ndara fushat e fazës 1 dhe fazës 2. Lexojeni si dokumentacion i strukturës, jo si ftesë për të aktivizuar çdo shifër historike dhe një grup të dobët, sepse një lidhje që ka sukses vetëm kështu nuk është lidhja që ju kërkuan të ndërtoni.

Bini dakord për suiten, pastaj verifikoni fazat

Pyetni operatorin e gateway-it cilat suita IKE dhe ESP mbështeten dhe janë miratuar, pastaj krahasojeni atë përgjigje me propozimet efektive të klientit dhe jo me skedarin e tij të konfigurimit. Nëse mosmarrëveshja ka të bëjë posaçërisht me PFS të fazës 2, vendosni një grup të mbështetur ose një politikë pa PFS të miratuar shprehimisht. Mos e nxirrni politikën nga emri i gabimit.

Kur e vetmja mbivendosje kërkon kriptografi që organizata nuk e pranon më, vendimi i përket gateway-it ose një migrimi protokolli. Zgjerimi i vargut të klientit derisa diçka të negociojë është një mënyrë për të dorëzuar një dobësi të njohur me një shenjë të gjelbër pranë.

Pasi të korrigjoni mospërputhjen e vërtetë, konfirmoni vendosjen e IPsec përpara se të hetoni L2TP dhe PPP, dhe trajtoni çdo refuzim të mëvonshëm vërtetimi si pjesë e fazës tjetër. Më pas provoni rinovimin në procesin e testimit të miratuar, sepse vendosja e asociimit të parë nuk thotë asgjë për pjesën tjetër të jetës së tij.