NO_PROPOSAL_CHOSEN på L2TP? Scan gatewayen først

En L2TP/IPsec-klient, der fejler før brugernavnsprompten, har aldrig aftalt fase 1. Scan gatewayens forslagssæt i stedet for at indsætte cifferstrenge.

Brugernavnsprompten vises aldrig, og klienten rapporterer NO_PROPOSAL_CHOSEN. Legitimationsoplysninger og den foruddelte nøgle er irrelevante på det tidspunkt, fordi de to ender ikke har aftalt, hvordan fase 1 skal beskyttes. De fleste reagerer ved at indsætte en cifferstreng, de fandt online. En scanning af gatewayen besvarer det samme spørgsmål med bevis og tager omtrent lige så lang tid.

Hvad meddelelsen udelukker

Afvisningen sker i hovedtilstand, før nogen L2TP- eller PPP-udveksling, så tunnelen og brugerdatabasen er ikke blevet konsulteret. Fase 1 forhandler kryptering, integritet og en Diffie-Hellman-gruppe. Fase 2 forhandler ESP-forslaget til data. En fejl i fase 1 kan ikke rettes ved at ændre en PFS-indstilling i fase 2, og en fuldført IKE-association beviser ikke, at ESP-forslaget passer.

Notér backend, før du redigerer syntaksen: ipsec --version. libreswan og strongSwan accepterer forskellige stavemåder af forslaget til de samme algoritmer.

Læs derefter afvisningen i kontekst med journalctl --no-hostname _COMM=nm-l2tp-service _COMM=ipsec _COMM=pluto _COMM=charon _COMM=kl2tpd _COMM=xl2tpd _COMM=pppd.

Scan gatewayen for dens transform-sæt

En scanner spørger gatewayen direkte, hvilke transforms den vil forhandle. Stop først den lokale IPsec-tjeneste, så sonden ikke konkurrerer med din egen klient, og læs derefter SA-linjerne. Behandl listen som bevis om modparten, ikke som en menu, der skal slås helt til.

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

Ældre enheder tilbyder ofte 3DES, SHA1 og MODP1024, fordi det var standardvalgene, da produktet blev sendt, og ingen genovervejede dem. Gem den rå scanningsudskrift, fordi den er den eneste registrering af, hvad modparten tilbød den dag. Hvis det er den stærkeste overlapning, der findes, er den rigtige eskalering til gatewayens ejer, ikke til en klientkonfiguration, der igen aktiverer svag kryptografi for alle.

Tilpas overlapningen uden at slå sikkerheden fra

Indtast kun de transforms, der optræder både i scanningen og i din politik. Eksemplet nedenfor afspejler en gateway, der tilbyder 3DES, SHA1 og MODP1024 i fase 1. Bemærk forbeholdet om backend: libreswan 4.x kompilerer ikke modp1024-gruppen, så dette gælder strongSwan eller et libreswan-build med DH2-understøttelse. Verificer versionen, før du konkluderer, at klienten er i stykker.

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

Et udråbstegn til sidst fastlåser et enkelt forslag. Brug det til at isolere en test, og fjern det derefter, så gatewayen senere kan forhandle noget stærkere.

Kontroller daemon og port, før du prøver igen

NetworkManager-l2tp starter sin egen xl2tpd-instans. Hvis systemtjenesten allerede ejer UDP 1701, falder klienten tilbage til en efemær kildeport, hvilket RFC 3193 tillader, og nogle servere dropper i stilhed. Kontroller socket-ejeren før næste forsøg.

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

Forældede genererede hemmeligheder er en anden stille årsag. Filer under /etc/ipsec.d/ opkaldt efter en gammel forbindelse kan overleve den profil, der skabte dem, så fjern dem, som intet henviser til, og prøv igen.

Kontroller til sidst, hvor rådet kom fra. En ipsec.conf skrevet til IKEv1 XAuth beskriver en anden VPN-type, og dens forslag er ikke den eneste linje, der vil være forkert i en L2TP-profil. Notér det transform-sæt, du indtastede, ved siden af profilen, så den næste person ikke gentager sonden.

Relaterede artikler