Ubuntu 22.04의 L2TP 시간 초과: xl2tpd 터널 버그

데스크톱에는 연결이 진행 중으로 표시되고 IPsec은 성공을 보고하지만 PPP 인터페이스는 끝내 나타나지 않습니다. syslog에서는 같은 터널 번호가 반복되다가 결국 시도가 UDP 1701에서 시간 초과됩니다. 미리 공유한 키나 서버 구성을 편집하기 전에 알아둘 형태는 이것입니다 — Ubuntu 22.04에서는 보통 xl2tpd의 패키징 회귀이며 서버는 내내 정상이었습니다.

반복되는 syslog 두 줄이 말해 주는 것

실패하는 세션은 일정한 간격으로 두 줄을 출력합니다 — 데몬이 들어오는 제어 메시지에 해당하는 터널을 찾지 못한 뒤, 넘겨받은 호출 및 터널 식별자를 쏟아 내는 것입니다. 나중에 재시도 카운터가 한계에 도달하면 연결은 포트 1701 시간 초과로 닫힙니다. 주소와 식별자는 부수적이며 형태가 중요합니다. IKE는 완료되었고 L2TP 제어 트래픽도 도착했지만, 데몬은 이미 만든 터널과 그것을 연결하지 못했습니다.

따라서 결함은 L2TP 제어와 PPP 사이에 있습니다. 비밀 키, PPP 옵션, 원격 서브넷에 관해서는 아직 아무것도 시험되지 않았습니다.

IPsec이 정말 성공했는지 확인하십시오

두 가지 확인이 이 문제를 자격 증명 문제와 구분하며, 둘 다 패키지를 바꾸기 전에 해야 합니다.

ipsec status
journalctl -u strongswan --since "5 min ago" | grep -i "shared key"

상태 출력은 연결과 그 상태를 나열하며, 터널이 수립되었다면 첫 단계와 두 번째 단계가 완료된 것입니다. 공유 키가 없다는 로그 줄은 오직 비밀 키만 가리키므로, 멈추고 먼저 그것을 고치십시오. IPsec이 수립되었는데도 L2TP 시간 초과가 계속 나타난다면 데몬이 남은 용의자입니다. 하루 종일의 재시도 대신 한 번의 시도에서 나온 정확한 줄을 보관하십시오.

xl2tpd 빌드를 확인하십시오, 릴리스 이름이 아니라

Ubuntu의 jammy 빌드인 xl2tpd 1.3.16은 링크 시점 최적화를 켰고, 이것이 서버의 SCCRP 응답에 있는 터널 식별자 파싱을 깨뜨렸습니다. 그러면 데몬은 자기가 만든 터널의 제어 패킷을 버립니다. 배포판 이름보다 버전 문자열이 더 중요합니다.

dpkg -l xl2tpd
apt policy xl2tpd
apt-mark showhold

수정된 패키지는 1.3.16-1ubuntu0.1이므로 그 접미사가 없는 빌드는 수정 이전입니다. 정책 출력은 업그레이드가 어떤 후보를 설치할지 보여 주고, 보류 목록은 수정이 왜 도착하지 않았는지 설명합니다. 패키지가 있는 곳에서는 파일을 손으로 편집하는 대신 업그레이드하고 정상 프로필로 다시 연결하십시오. 옛 빌드가 설치된 동안에는 모듈을 다시 빌드하거나 비밀 키를 바꾸지 마십시오.

변경 후 PPP를 확인하십시오

성공한 업그레이드는 깨졌던 계층에서 증명됩니다. 아이콘이 바뀌었는지가 아니라 PPP가 올라왔는지 확인하십시오.

ip -4 addr show ppp0
ip route | grep ppp

인터페이스 목록에는 로컬 주소와 피어 주소가 보여야 하고, 라우팅 테이블에는 터널의 프리픽스가 있어야 합니다. syslog에는 터널이 수락되었고 pppd가 두 주소를 보고한다는 내용이 터널 없음 줄을 반복하지 않고 나타나야 합니다. PPP가 올라왔는데도 트래픽이 실패한다면 L2TP 단계는 이미 할 일을 마쳤으므로 다음으로 라우팅이나 MTU를 보십시오. 동작하는 패키지 버전을 머신 메모에 기록해 두어 나중의 재설치가 깨진 빌드를 되살리지 않게 하십시오.

수정된 패키지를 구할 수 없는 곳에서는 문서화된 대안이 1.3.16 또는 1.3.17의 로컬 소스 빌드, kl2tpd로의 전환, 고정된 다운그레이드입니다. 각각은 기록해 둘 만한 유지 관리 비용을 동반합니다.