IKE와 ESP는 허용하지만 UDP 1701은 허용하지 않는 방화벽은 자격 증명 문제처럼 보이는 방식으로 L2TP 연결을 끊습니다. 이유는 L2TP가 첫 번째 프로토콜 안에서 움직이는 두 번째 프로토콜이기 때문입니다. IPsec이 교환을 운반하고 인증하며, L2TP는 UDP 1701 위에서 자체 터널을 돌리는데, 로컬 스택은 여전히 이를 전달해야 합니다. 각 헤더가 어디에 나타나는지 알면 어떤 장비에 어떤 규칙이 필요한지 설명됩니다.

두 프로토콜, 두 포트 집합

L2TP/IPsec 연결은 UDP 500에서 IKE를, 변환이 있는 곳에서는 UDP 4500에서 NAT 통과를, 없는 곳에서는 IP 프로토콜 50으로 ESP를 사용합니다. L2TP 자체는 UDP 1701의 터널 프로토콜이며 IPsec이 상대를 인증한 뒤 동작합니다. 두 절반은 서로 다르게 실패하고, 이를 보고하는 로그 줄은 서로 다른 구성 요소에서 나옵니다. 앞 절반만 다루는 규칙 집합은 협상까지 진행하고 터널 단계에서 죽는 연결을 만듭니다.

포트 번호는 전송 끝점을 설명하며, ESP는 포트가 아닙니다. 그래서 TCP와 UDP 규칙만 제공하는 방화벽 인터페이스는 완전한 IPsec 정책을 표현할 수 없습니다. 프로토콜 50은 프로토콜로 허용해야 하며, UDP만 언급하는 규칙은 그것과 결코 일치하지 않습니다.

래퍼가 포트를 설명한다

회선에서는 L2TP/IPsec 연결이 보통 500의 IKE와 4500의 캡슐화된 ESP를 보여 줍니다. UDP 1701 헤더는 보호된 페이로드 안에 있으므로 외부 인터페이스에서의 캡처에는 나타나지 않습니다. 로컬 호스트는 그 데이터그램을 L2TP 데몬에 여전히 전달해야 하고, 전달은 캡슐 해제 후에 일어납니다. 따라서 1701 규칙은 중간 장비가 그 포트를 한 번도 보지 못하더라도 엔드포인트 자체의 방화벽에 속합니다.

처리 순서가 혼란의 대부분을 설명합니다. 스택이 호스트 필터보다 먼저 IPsec 정책을 적용하면 캡슐 해제된 L2TP 패킷이 UDP 1701로 일치되고, 순서가 반대라면 규칙 집합이 보는 것은 외부 포트입니다. 두 동작 모두 실제로 존재하므로 같은 규칙 집합이 한 플랫폼에서는 동작하고 다른 플랫폼에서는 실패하는 것처럼 보입니다.

순서대로 경로를 확인한다

먼저 외부 인터페이스에서 캡처하고 IKE와 캡슐화된 ESP가 양방향으로 흐르는지 확인합니다. 그다음 캡슐 해제된 트래픽에 대해 로컬 방화벽 카운터를 확인합니다. 순서가 중요한 이유는 아무것도 보여 주지 않는 캡처는 문제가 호스트 위쪽에 있다는 뜻이기 때문입니다.

sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'
sudo nft list ruleset | grep -i -A2 1701
sudo ss -lunp | grep 1701

캡처는 교환의 앞 절반을 확인하고 상대가 응답하는지 보여 줍니다. 규칙 목록은 1701 규칙이 있는지, 그리고 어떤 폐기 정책에 대해서 어디에 위치하는지 보여 줍니다. 소켓 목록은 L2TP 데몬이 바인딩되어 수신 중임을 확인하며, 시작되지 않은 서비스를 배제합니다. 수신기가 없을 때와 필터링된 포트는 사용자에게 같은 불만을 만들기 때문에 규칙을 바꾸기 전에 세 가지를 모두 읽으십시오.

포트 스캔이 보여 줄 수 없는 것

올바르게 구성된 서버에 대한 UDP 1701의 외부 스캔은 보통 아무것도 보고하지 않으며, 그것이 예상된 결과입니다. 이 포트는 인터넷에 노출되지 않고, IPsec이 상대를 인증한 뒤에만 도달할 수 있습니다. 닫힌 결과를 고장으로 다루면 닫힌 채로 두어야 할 포트를 열게 됩니다. 스캔은 애플리케이션 트래픽을 볼 수 없는 것만큼이나 터널 내부를 볼 수 없습니다.

대신 실제 클라이언트로 시험하고 어느 단계까지 가는지 읽으십시오. 연결이 협상한 뒤 멈춘다면 L2TP 데몬이나 로컬 필터가 용의자이고, 전혀 협상하지 않는다면 외부 포트가 원인입니다. 그 하나의 구분이 어떤 규칙을 추가할지에 대한 추측의 대부분을 없애고, 프로토콜 계층화가 그것을 신비가 아니라 예측 가능한 것으로 만듭니다.

관련 글