L2TP NO_PROPOSAL_CHOSEN: 실제로 어느 단계가 실패했는가?
알림은 제안이 거부되었다고만 말하고 어느 것인지는 말하지 않습니다. 백엔드 로그에서 단계를 확인한 다음 게이트웨이를 운영하는 사람과 스위트를 비교하십시오.
NO_PROPOSAL_CHOSEN은 PPP 사용자 이름이 검사되기 전에 도착하며, 이는 유용한 사실이자 이 메시지가 오해를 부르는 이유이기도 합니다. 한쪽이 제안을 거부했다는 것만 알리고 어느 매개변수가 어긋났는지는 알리지 않으며, 거부가 IKE 연결을 만드는 중에 일어났는지 아니면 나중에 트래픽 보호를 협상하는 중에 일어났는지도 말하지 않습니다. 이 두 가능성 뒤에는 서로 다른 두 가지 수정이 있고, 사람들이 가장 먼저 손대는 PFS 체크박스가 관련된 것은 그중 하나뿐입니다.
하나의 메시지, 두 개의 제안 집합
IKEv1 L2TP/IPsec 구성에는 두 번의 협상이 차례로 있습니다. 단계 1은 암호화 알고리즘, 무결성 알고리즘, Diffie-Hellman 그룹으로 IKE 보안 연결을 만듭니다. 이어서 단계 2가 트래픽을 어떻게 보호할지 협상하며, PFS 요구 사항은 그 두 번째 대화에 속합니다.
| 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 |
단계가 순차적이므로 실패한 위치가 어느 목록을 비교해야 하는지 알려줍니다. 메시지의 진단적 가치는 전부 거기에 있으므로 설정을 건드리기 전에 뽑아 두는 것이 좋습니다.
PFS 체크박스가 단계 1을 고칠 수 없는 이유
PFS를 끄는 것은 단계 2의 속성을 바꿉니다. 양쪽이 단계 1에 합의한 적이 없다면 ESP 대화는 아예 일어나지 않으므로 체크박스는 거부에 전혀 영향을 주지 않으며, 그래서 이를 바꾸면 같은 오류가 다른 타임스탬프로 나타납니다.
반대 방향의 실수도 흔합니다. IKE 연결이 성공했다고 해서 ESP 제안이 받아들여질 수 있다는 증거가 되지 않으며, 단계 2의 그룹이 일치한다는 증거는 더더욱 아닙니다. 설정된 관리 터널은 단계 1에 대한 증거로만 취급하십시오. 사람들은 초록색 줄을 «터널이 살아 있다»로 읽고, 두 번째 협상이 시작되지 않았다는 말을 아무도 해 주지 않았기 때문에 잘못된 단계에서 한 시간을 보냅니다.
알고리즘을 고르기 전에 로그를 읽으십시오
거부 직전의 메시지를 연결을 실제로 처리하는 백엔드에서 모으고 같은 시도와 연결하십시오. 그 연결이 없으면 다른 연결의 이력을 읽으면서 결론을 끌어내는 셈입니다.
journalctl -b -u NetworkManager --since "10 min ago"
ipsec statusall # strongSwan
ipsec whack --status # Libreswan그 줄에서 단계 1 연결이 성립했는지, 어느 교환이 실패했는지 두 가지 질문에 답하십시오. 이 두 답이 검색을 하나의 속성 목록으로 좁힙니다. 주변 맥락이 없는 빈약한 알림으로는 그것이 불가능하며, 포럼 스레드에서 제안을 시험해 보는 것이 아무리 유혹적이어도 마찬가지입니다. 다른 백엔드를 쓰는 기계에서 동작하는 문자열을 복사하면 보통 하나의 거부가 또 다른 거부로 바뀔 뿐이며, 조금 더 늦게 나타납니다.
백엔드 구문은 이동하지 않습니다
무엇이든 비교하기 전에 NetworkManager-l2tp 버전과 IPsec 백엔드 버전을 기록하십시오. Libreswan과 strongSwan은 제안 구문도, 동일한 알고리즘 집합도 공유하지 않으므로 한쪽에서 동작하는 문자열은 다른 쪽에서 구문 오류입니다. 설치된 백엔드가 정책상 IKEv1을 거부할 수도 있으며, 그러면 어떤 제안도 결코 받아들여지지 않습니다.
프로젝트의 README는 이런 백엔드 차이를 문서화하고 단계 1과 단계 2의 필드를 분리해 둡니다. 그렇게 해야만 성공하는 연결은 요청받은 연결이 아니므로, 그것을 구조에 대한 문서로 읽고 모든 역사적 암호와 약한 그룹을 켜라는 초대로 읽지 마십시오.
스위트에 합의한 다음 단계를 검증하십시오
게이트웨이 운영자에게 어떤 IKE와 ESP 스위트가 지원되고 승인되었는지 물은 다음, 그 답을 클라이언트의 설정 파일이 아니라 실제 제안과 비교하십시오. 불일치가 특히 단계 2의 PFS에 관한 것이라면 지원되는 그룹이나 명시적으로 승인된 PFS 없는 정책으로 정하십시오. 오류 이름에서 정책을 추론하지 마십시오.
유일한 겹침이 조직이 더는 받아들이지 않는 암호 기술을 요구한다면 결정은 게이트웨이나 프로토콜 이전에 속합니다. 무언가가 협상할 때까지 클라이언트 문자열을 넓히는 것은 알려진 약점을 옆에 초록 체크를 달아 출하하는 방법입니다.
실제 불일치를 고친 뒤에는 L2TP와 PPP를 조사하기 전에 IPsec 성립을 확인하고, 이후의 인증 거부는 다음 단계에 속하는 것으로 취급하십시오. 그런 다음 첫 연결의 성립은 남은 수명에 대해 아무것도 말해 주지 않으므로, 승인된 테스트 절차에서 갱신을 시험하십시오.