NO_PROPOSAL_CHOSEN në L2TP? Skanoni së pari portën

Kërkesa për emrin e përdoruesit nuk shfaqet kurrë, dhe klienti raporton NO_PROPOSAL_CHOSEN. Në atë moment kredencialet dhe çelësi i përbashkët paraprak janë të parëndësishme, sepse dy skajet nuk janë marrë vesh se si të mbrohet faza 1. Shumica e njerëzve përgjigjen duke ngjitur një varg shifrimi që e gjetën në internet. Skanimi i portës i përgjigjet të njëjtës pyetje me prova dhe zgjat afërsisht njësoj.

Çfarë përjashton mesazhi

Refuzimi ndodh në modalitetin kryesor, para çdo shkëmbimi L2TP ose PPP, kështu që as tuneli as baza e të dhënave të përdoruesve nuk janë konsultuar. Faza 1 negocion kriptimin, integritetin dhe një grup Diffie-Hellman. Faza 2 negocion propozimin ESP për të dhënat. Një dështim në fazën 1 nuk rregullohet duke ndryshuar një cilësim PFS në fazën 2, dhe një asociacion IKE i përfunduar nuk provon që propozimi ESP përshtatet.

Shënoni backend-in përpara se të ndryshoni sintaksën: ipsec --version. libreswan dhe strongSwan pranojnë drejtshkrime të ndryshme të propozimit për të njëjtat algoritme.

Më pas lexoni refuzimin në kontekst me journalctl --no-hostname _COMM=nm-l2tp-service _COMM=ipsec _COMM=pluto _COMM=charon _COMM=kl2tpd _COMM=xl2tpd _COMM=pppd.

Skanoni portën për grupin e saj të transformimeve

Një skaner e pyet portën drejtpërdrejt se cilat transformime do të negociojë. Ndaloni së pari shërbimin lokal IPsec që sonda të mos konkurrojë me klientin tuaj, pastaj lexoni rreshtat SA. Trajtojeni listën si provë për palën tjetër, jo si meny për t’u aktivizuar e tëra.

sudo ipsec stop
sudo ike-scan --trans=3des-sha1-modp1024 10.10.10.250 | grep SA=

Pajisjet më të vjetra ofrojnë shpesh 3DES, SHA1 dhe MODP1024, sepse këto ishin vlerat e paracaktuara kur produkti u dërgua dhe askush nuk i rishikoi. Ruani daljen e papërpunuar të skanimit, sepse është i vetmi regjistrim i asaj që ofroi pala tjetër atë ditë. Nëse ky është mbivendosja më e fortë e disponueshme, eskualimi i duhur është te pronari i portës, jo te një konfigurim klienti që riaktivizon kriptografinë e dobët për të gjithë.

Përputhni mbivendosjen pa çaktivizuar sigurinë

Vendosni vetëm transformimet që shfaqen si në skanim ashtu edhe në politikën tuaj. Shembulli më poshtë pasqyron një portë që ofron 3DES, SHA1 dhe MODP1024 në fazën 1. Vini re paralajmërimin për backend-in: libreswan 4.x nuk e kompilon grupin modp1024, prandaj kjo vlen për strongSwan ose për një ndërtim libreswan me mbështetje DH2. Verifikoni versionin përpara se të përfundoni se klienti është prishur.

Phase 1: 3des-sha1-modp1024
Phase 2: aes256-sha1,aes128-sha1,3des-sha1

Një pikëçuditje në fund fikson një propozim të vetëm. Përdoreni për të izoluar një test, pastaj hiqeni që porta të mund të negociojë diçka më të fortë më vonë.

Kontrolloni daemon-in dhe portën përpara se të riprovoni

NetworkManager-l2tp nis instancën e vet xl2tpd. Nëse shërbimi i sistemit zotëron tashmë UDP 1701, klienti kalon në një port burimor efemer, të cilin RFC 3193 e lejon dhe disa serverë e hedhin në heshtje. Kontrolloni pronarin e socket-it përpara provës tjetër.

sudo ss -unlp | grep 1701
sudo systemctl stop xl2tpd.service
sudo systemctl disable xl2tpd.service

Sekretet e vjetruara të gjeneruara janë një shkak tjetër i heshtur. Skedarët nën /etc/ipsec.d/ të emërtuar për një lidhje të vjetër mund t’i mbijetojnë profilit që i krijoi, prandaj hiqni ata që asgjë nuk i referon dhe provoni përsëri.

Së fundi, kontrolloni nga ka ardhur këshilla. Një ipsec.conf i shkruar për IKEv1 XAuth përshkruan një lloj tjetër VPN, dhe propozimi i tij nuk është rreshti i vetëm që do të jetë i gabuar në një profil L2TP. Shënoni grupin e transformimeve që keni futur pranë profilit, që personi tjetër të mos e përsëritë sondën.