NO_PROPOSAL_CHOSEN by L2TP? Skearje earst de gateway

In L2TP/IPsec-klant dy’t mislearret foar de brûkersnamme-promp, hat nea ôfpraat oer faze 1. Skearje de foarstelsset fan de gateway yn stee fan siferstrengen te plakken.

De brûkersnamme-promp ferskynt nea, en de klant meldt NO_PROPOSAL_CHOSEN. Oanmeldgegevens en de foarôf dielde kaai binne op dat stuit net fan belang, om’t de beide einen net ôfpraat hawwe hoe’t faze 1 beskerme wurde moat. De measte minsken reagearje troch in siferstring te plakken dy’t se online fûnen. In skearing fan de gateway beantwurdet deselde fraach mei bewiis en duorret sawat like lang.

Wat it berjocht útslút

De ôfwizing bart yn haadmodus, foar elke L2TP- of PPP-útwikseling, sadat de tunnel en de brûkersdatabase net rieplachte binne. Faze 1 ûnderhannelet oer fersifering, yntegriteit en in Diffie-Hellman-groep. Faze 2 ûnderhannelet oer it ESP-foarstel foar gegevens. In flater yn faze 1 is net te ferhelpen troch in PFS-ynstelling yn faze 2 te feroarjen, en in foltôge IKE-assosjaasje bewiist net dat it ESP-foarstel past.

Skriuw de backend op foardat jo de syntaks bewurkje: ipsec --version. libreswan en strongSwan akseptearje ferskillende staveringen fan it foarstel foar deselde algoritmen.

Lês dêrnei de ôfwizing yn kontekst mei journalctl --no-hostname _COMM=nm-l2tp-service _COMM=ipsec _COMM=pluto _COMM=charon _COMM=kl2tpd _COMM=xl2tpd _COMM=pppd.

Skearje de gateway om syn transformaasjeset

In skearmasine freget de gateway direkt hokker transformaasjes it ûnderhannelje sil. Stopearje earst de pleatslike IPsec-tsjinst sadat de test net konkurrearret mei jo eigen klant, en lês dan de SA-rigels. Behannelje de list as bewiis oer de tsjinpartij, net as in menu om alles tagelyk oan te setten.

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

Aldere apparaten biede faak 3DES, SHA1 en MODP1024 oan, om’t dat de standertwearden wiene doe’t it produkt ferstjoerd waard en nimmen se wer besjoen hat. Bewarje de rûge skearútfoer, want it is it iennichste ferslach fan wat de tsjinpartij dy dei oanbea. As dat de sterkste beskikbere oerlaping is, is de juste eskalasje nei de eigner fan de gateway, net nei in klantkonfiguraasje dy’t swakke kryptografy foar elkenien wer ynskeakelet.

Meitsje de oerlaping passend sûnder feiligens út te skeakeljen

Fier allinnich de transformaasjes yn dy’t sawol yn de skearing as yn jo belied foarkomme. It foarbyld hjirûnder spegelet in gateway dy’t 3DES, SHA1 en MODP1024 yn faze 1 oanbiedt. Tink oan it backend-foarbehâld: libreswan 4.x kompilearret de modp1024-groep net, dus dit jildt foar strongSwan of in libreswan-bou mei DH2-stipe. Ferifiearje de ferzje foardat jo konkludearje dat de klant stikken is.

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

In útropteken oan ’e ein pinnelet ien foarstel fêst. Brûk it om in test te isolearjen, en ferwiderje it dan sadat de gateway letter eat sterkers ûnderhannelje kin.

Kontrolearje de daemon en de poarte foardat jo it opnij besykje

NetworkManager-l2tp start syn eigen xl2tpd-ynstânsje. As de systeemtsjinst al UDP 1701 hat, falt de klant werom op in efemere boarne-poarte, wat RFC 3193 tastiet en guon servers stil ferningje. Kontrolearje de eigner fan de socket foar de folgjende poging.

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

Ferâldere generearre geheimen binne noch in stille oarsaak. Bestannen ûnder /etc/ipsec.d/ neamd nei in âlde ferbining kinne it profyl oerlibje dat se makke hawwe, dus ferwiderje dejinge dêr’t neat nei ferwiist en besykje it opnij.

Kontrolearje as lêste wêr’t it advys wei kaam. In ipsec.conf skreaun foar IKEv1 XAuth beskriuwt in oar soart VPN, en syn foarstel is net de iennichste rigel dy’t ferkeard wêze sil yn in L2TP-profyl. Skriuw de transformaasjeset dy’t jo ynfierd hawwe njonken it profyl, sadat de folgjende persoan de test net werhellet.

Relatearre artikelen