NO_PROPOSAL_CHOSEN på L2TP? Skann gatewayen fyrst

Ein L2TP/IPsec-klient som feilar før brukarnamnførespurnaden, har aldri vorte samde om fase 1. Skann forslagssettet til gatewayen i staden for å lime inn chifferstrengar.

Brukarnamnførespurnaden viser seg aldri, og klienten rapporterer NO_PROPOSAL_CHOSEN. På det tidspunktet er påloggingsinformasjon og den førehandsdelinga nøkkelen irrelevante, fordi partane ikkje har vorte samde om korleis fase 1 skal vernast. Dei fleste reagerer med å lime inn ein chifferstreng dei fann på nettet. Ein skanning av gatewayen svarar på det same spørsmålet med bevis og tek omtrent like lang tid.

Kva meldinga utelukkar

Avvisinga skjer i hovudmodus, før noka L2TP- eller PPP-utveksling, så tunnelen og brukardatabasen er ikkje vortne spurde. Fase 1 forhandlar om kryptering, integritet og ei Diffie-Hellman-gruppe. Fase 2 forhandlar om ESP-forslaget for data. Ein feil i fase 1 kan ikkje rettast ved å endre ei PFS-innstilling i fase 2, og ein fullført IKE-assosiasjon beviser ikkje at ESP-forslaget passar.

Noter backend før du redigerer syntaksen: ipsec --version. libreswan og strongSwan godtek ulike stavemåtar av forslaget for dei same algoritmane.

Les deretter avvisinga i samanheng med journalctl --no-hostname _COMM=nm-l2tp-service _COMM=ipsec _COMM=pluto _COMM=charon _COMM=kl2tpd _COMM=xl2tpd _COMM=pppd.

Skann gatewayen for transformasjonssettet

Ein skannar spør gatewayen direkte kva transformasjonar han vil forhandle om. Stopp først den lokale IPsec-tenesta slik at sonden ikkje konkurrerer med din eigen klient, og les deretter SA-linjene. Handsame lista som bevis om motparten, ikkje som ei meny som skal slåast på i sin heilskap.

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

Eldre einingar tilbyr ofte 3DES, SHA1 og MODP1024, fordi det var standardverdiane då produktet vart sendt, og ingen har gått gjennom dei på nytt. Ta vare på den rå skanneutskrifta, fordi ho er den einaste registreringa av kva motparten baud den dagen. Viss det er den sterkaste overlappinga som finst, høyrer eskaleringa heime hos eigaren av gatewayen, ikkje hos ein klientkonfigurasjon som slår på svak kryptografi for alle igjen.

Tilpass overlappinga utan å slå av tryggleiken

Skriv berre inn transformasjonane som finst både i skanninga og i policyen din. Dømet nedanfor speglar ein gateway som tilbyr 3DES, SHA1 og MODP1024 i fase 1. Legg merke til atterhaldet om backend: libreswan 4.x kompilerer ikkje modp1024-gruppa, så dette gjeld strongSwan eller ein libreswan-build med DH2-støtte. Stadfest versjonen før du konkluderer med at klienten er øydelagd.

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

Eit utropsteikn til slutt låser eitt enkelt forslag. Bruk det til å isolere ein test, og fjern det deretter slik at gatewayen seinare kan forhandle om noko sterkare.

Kontroller daemonen og porten før du prøver igjen

NetworkManager-l2tp startar sin eigen xl2tpd-instans. Viss systemtenesta allereie eig UDP 1701, fell klienten tilbake til ein efemær kjeldeport, noko RFC 3193 tillèt og somme tenarar droppar i stillheit. Kontroller socket-eigaren før neste forsøk.

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

Utdaterte genererte løyndomar er ei anna stille årsak. Filer under /etc/ipsec.d/ kalla opp etter ei gammal tilkopling kan overleve profilen som oppretta dei, så fjern dei som ingenting viser til, og prøv igjen.

Til slutt, kontroller kvar rådet kom frå. Ein ipsec.conf skriven for IKEv1 XAuth skildrar ein annan VPN-type, og forslaget hans er ikkje den einaste linja som vil vere feil i ein L2TP-profil. Noter transformasjonssettet du skreiv inn, ved sida av profilen, slik at neste person ikkje gjer sonden om att.

Relaterte artiklar