L2TP NO_PROPOSAL_CHOSEN: quina fase ha fallat realment?
La notificació diu que s'ha rebutjat una proposta, no quina. Llegeix el registre del backend per saber la fase i després compara els conjunts amb qui gestiona la passarel·la.
NO_PROPOSAL_CHOSEN arriba abans que s'examini cap nom d'usuari PPP, cosa que és un fet útil i també la raó per la qual el missatge enganya. Informa que un costat ha rebutjat una proposta; no informa quin paràmetre no coincideix i no diu res sobre si el rebuig va passar mentre es construïa l'associació IKE o més tard, mentre es negociava la protecció del trànsit. Darrere d'aquestes dues possibilitats hi ha dues correccions diferents, i només una implica la casella PFS a què la gent acudeix primer.
Un sol missatge, dos conjunts de propostes
La disposició IKEv1 L2TP/IPsec té dues negociacions en seqüència. La fase 1 construeix l'associació de seguretat IKE a partir d'un algorisme de xifratge, un algorisme d'integritat i un grup Diffie-Hellman. La fase 2 negocia després com es protegeix el trànsit, i el requisit de PFS pertany a aquesta segona conversa.
| Phase | What is agreed | What a rejection here means |
|---|---|---|
| Phase 1 | Encryption, integrity, DH group for the IKE SA | No management tunnel exists, so nothing later can run |
| Phase 2 | ESP transforms plus the PFS group policy | The IKE SA negotiates, then child negotiation fails |
Com que les fases són seqüencials, la posició de la fallada et diu quina llista has de comparar. Aquest és tot el valor de diagnòstic del missatge, i val la pena extreure'l abans de tocar cap paràmetre.
Per què una casella PFS no pot reparar la fase 1
Desactivar PFS canvia una propietat de la fase 2. Si les parts mai no s'han posat d'acord sobre la fase 1, la conversa ESP no té lloc mai, així que la casella no té cap efecte sobre el rebuig, i per això canviar-la produeix el mateix error amb una marca de temps diferent.
L'error invers és igual de comú. Una associació IKE correcta no demostra que la proposta ESP sigui acceptable i, sens dubte, no demostra que el grup de la fase 2 coincideixi. Tracta un túnel de gestió establert com a evidència només sobre la fase 1. La gent llegeix la línia verda com «el túnel funciona» i després passa una hora a la fase equivocada perquè res no els ha dit que la segona negociació no havia començat.
Llegeix el registre abans de triar algorismes
Recull els missatges immediatament anteriors al rebuig del backend que realment atén la connexió i correlaciona'ls amb el mateix intent. Sense aquesta correlació estàs llegint l'historial d'una altra connexió i en treus conclusions.
journalctl -b -u NetworkManager --since "10 min ago"
ipsec statusall # strongSwan
ipsec whack --status # LibreswanA partir d'aquestes línies, respon dues preguntes: s'ha establert una associació de fase 1 i quin intercanvi ha fallat. Aquestes dues respostes estrenyen la cerca a una sola llista d'atributs. Una notificació nua sense context al voltant no pot fer-ho, per temptador que sigui provar una proposta d'un fil de fòrum. Copiar una cadena que funciona d'una màquina amb un altre backend sol substituir un rebuig per un altre, una mica més tard.
La sintaxi del backend no viatja
Anota la versió de NetworkManager-l2tp i la versió del backend IPsec abans de comparar res. Libreswan i strongSwan no comparteixen sintaxi de propostes ni conjunts d'algorismes idèntics, així que una cadena que funciona en un és un error de sintaxi en l'altre. El backend instal·lat també pot refusar IKEv1 per política, i aleshores cap proposta no serà mai acceptada.
El README del projecte documenta aquestes diferències entre backends i manté separats els camps de fase 1 i fase 2. Llegeix-lo com a documentació de l'estructura, no com una invitació a habilitar tots els xifratges històrics i un grup feble, perquè una connexió que només té èxit fent això no és la connexió que et van demanar construir.
Poseu-vos d'acord en el conjunt i després verifiqueu les etapes
Pregunta a l'operador de la passarel·la quins conjunts IKE i ESP estan suportats i aprovats, i després compara aquesta resposta amb les propostes efectives del client i no amb el seu fitxer de configuració. Si el desacord és específicament sobre PFS de fase 2, decidiu un grup suportat o una política sense PFS aprovada explícitament. No inferiu la política del nom de l'error.
Quan l'únic solapament requereix criptografia que l'organització ja no accepta, la decisió pertany a la passarel·la o a una migració de protocol. Ampliar la cadena del client fins que alguna cosa negociï és una manera de lliurar una debilitat coneguda amb una marca verda al costat.
Després de corregir la discrepància real, confirma l'establiment d'IPsec abans d'investigar L2TP i PPP, i tracta qualsevol rebuig d'autenticació posterior com a pertanyent a l'etapa següent. Després prova la renovació en el procés de proves aprovat, perquè establir la primera associació no diu res sobre la resta de la seva vida.