L2TP 치명적 신호 15: NO_PROPOSAL_CHOSEN과 사라진 modp1024

연결이 멈추고 클라이언트가 종료되며 화면의 마지막 줄은 death_handler: Fatal signal 15 received입니다. 그 줄은 중단을 알릴 뿐 원인은 아닙니다. IPsec 로그의 한 줄 위에는 거의 항상 NO_PROPOSAL_CHOSEN이 있고, 이 두 줄은 교환의 2단계를 가리킵니다. 여기서 양쪽은 암호화와 해시 선택을 비교하고 공통점이 없으면 멈춥니다. 그 단계에서는 자격 증명이 아직 전송되지 않았으므로 비밀번호를 다시 입력해도 결과는 바뀌지 않습니다.

Linux 클라이언트에서 이 교집합을 비우는 것은 보통 두 가지입니다. 로컬 데몬이 프로필이 요구하는 Diffie-Hellman 그룹을 더 이상 구현하지 않거나, 프로필이 1단계 제안을 2단계 필드에 담고 있을 수 있습니다. 둘 다 로그에 흔적을 남기며 어느 쪽도 계정 문제가 아닙니다.

두 메시지가 실제로 말하는 것

IKE는 여러 단계로 협상합니다. 1단계는 보호된 채널을 만들고 자체 알고리즘을 고릅니다. 2단계, 즉 자식 SA는 별도의 집합으로 트래픽을 나릅니다. NO_PROPOSAL_CHOSEN는 제시된 조합 중 어느 것도 받아들일 수 없을 때 응답자가 돌려보내는 알림이며, INFORMATIONAL 교환 안에서 [ HASH N(NO_PROP) ] 형태로 나타납니다.

신호 15는 다른 사건입니다. 무언가가 로컬 프로세스에 중지를 지시했고 핸들러가 그것을 기록했습니다. 두 줄이 함께 나타나면 순서는 인과적이며 거절이 먼저, 종료가 나중입니다.

자격 증명을 건드리기 전에 협상을 읽으세요

데몬이 기록하는 곳에서 로그 수준을 높인 다음 출력을 보면서 다시 연결하세요. NetworkManager 호스트에서는 L2TP 플러그인이 그 수준을 백엔드로 넘기고, 메시지는 배포판에 따라 journal이나 전통적인 syslog 파일에 남습니다. 둘 중 어느 것이든 교환을 보여줍니다: journalctl -f -u NetworkManager | grep -Ei 'pluto|charon|no_prop|proposal' 또는 tail -f /var/log/syslog | grep -Ei 'pluto|charon|ike'.

pluto를 언급하는 줄은 libreswan에서, charon은 strongSwan에서 나오며 둘 다 같은 상태를 다른 말로 설명합니다. 찾아볼 가치가 있는 형태는 빠진 그룹을 지목하는 것입니다. 예를 들어 algorithm 'modp1024' is not supported 같은 것으로, 모호한 실패를 구체적인 실패로 바꿉니다.

modp1024는 어디로 갔나

Diffie-Hellman 그룹 2는 너무 약해서 여러 배포판이 3.30부터 libreswan에 컴파일하는 것을 중단했습니다. 그러면 몇 년 전에 작성했거나 aes128-sha1-modp1024만 나열하는 게이트웨이 안내서에서 가져온 프로필이 로컬 데몬에 전혀 수행할 수 없는 것을 요구합니다. 최신 NetworkManager-l2tp 빌드는 그 결과를 더 가능하게 만듭니다. 1.2.16부터는 집합을 Windows 10과 iOS 스타일 제안으로 바꾸고 libreswan이 감지되면 modp1024를 버립니다. 상대편은 대개 무죄이며 여전히 설정한 그룹을 그대로 제공합니다.

이 비대칭성이 실패를 무작위처럼 느끼게 합니다. 오래된 클라이언트는 연결되고 업데이트된 노트북의 같은 프로필은 연결되지 않으며 서버 구성은 움직인 적이 없습니다. 손상은 버전 차이가 만듭니다.

영향 범위가 다른 두 가지 수리

값싼 수리는 알고리즘을 하드코딩하지 않는 것입니다. 편집기에서 두 제안 필드를 비우고 플러그인이 상대편이 받아들이는 집합을 고르게 하세요. 게이트웨이가 현대적 그룹을 지원한다면 추가 작업 없이 협상이 끝납니다.

두 번째 수리는 strongSwan을 설치해 오래된 게이트웨이를 계속 쓸 수 있게 합니다. 그 패키지는 대부분의 배포판에서 여전히 그룹 2를 구현합니다. 이는 데몬 교체이므로 비용이 있습니다. 제거하기 전에 호스트의 다른 터널이 libreswan 구성에 의존하는지 확인하고, Fedora에서는 NetworkManager와 strongSwan 플러그인 사이에 SELinux 거부가 생길 것을 예상하세요. 그 거부는 IKE 추적이 아니라 감사 로그에 나타나므로 설치가 성공한 직후에도 터널이 고장 난 것처럼 보일 수 있습니다. 제대로 되는 순서는 먼저 dnf install strongswan, 그다음 rpm -e libreswan입니다.

일치하는 제안 문자열과 그 주변의 함정

필드를 손으로 채워야 할 때 1단계와 2단계는 다른 값을 가집니다. Meraki 스타일 상대에 대해 작동하는 것으로 알려진 조합은 1단계에 aes128-sha1-modp1024을, 그 뒤에 3des-sha1-modp1024을 두고 둘 다 집합을 엄격하게 만드는 느낌표로 닫으므로 그 제안만 전송됩니다.

그다음 2단계는 같은 엄격 표시를 붙이고 Diffie-Hellman 접미사 없이 aes128-sha1와 3des-sha1로 좁혀집니다. -modp1024을 담은 2단계 줄은 잘못된 필드에 있는 1단계 값이며 응답자는 재시도마다 그것을 거부합니다. 그 줄을 두 번째 프로필에 복사하면 두 번째 프로필도 같은 방식으로 실패하며, 이렇게 오타 하나가 함대 전체의 사고가 됩니다.

다른 결함도 제안 불일치가 아닌데 같은 팝업을 씁니다. KDE에서는 플러그인이 설치되어 있어도 L2TP 유형이 목록에 나오면서 모든 연결이 즉시 죽습니다. 연결 편집기와 런타임 도우미가 별도 패키지로 제공되기 때문입니다. 화면이 없는 호스트는 작동하는 데스크톱의 프로필을 재사용할 수 있습니다. /etc/NetworkManager/system-connections/에서 복사하고 모드를 600으로 설정한 다음 nmcli con reload을 실행하세요. nmcli con up id work-l2tp로 올리세요. 맨 형태는 UUID를 요구하기 때문입니다. 오래된 ifname 항목은 제거하세요. 그렇지 않으면 나머지가 모두 맞아도 관리자는 Could not find source connection라고 응답합니다.

미리 공유한 키는 평문으로 또는 0s 뒤에 base64로 저장할 수 있습니다. 두 형태 모두 작동하지만 값은 끝에 함께 복사한 공백을 포함해 게이트웨이와 바이트 단위로 일치해야 합니다.