프로토콜 47 대 TCP 포트 47: 두 개의 헤더, 두 개의 규칙

호텔 네트워크와 회의장 방화벽에는 맞춤 허용 칸이 흔히 있고, 누군가 PPTP가 동작하기를 기대하며 그 칸에 47을 입력합니다. 규칙은 만들어지지만 터널은 여전히 실패하고, 다음 시도에서는 다른 번호를 사용합니다. 문제는 패킷 자체에 있습니다: IPv4에는 IP 헤더 다음에 무엇이 오는지 지정하는 프로토콜 필드가 있는 반면, TCP와 UDP의 포트 필드는 그 헤더 중 하나의 내부에 있을 때만 존재합니다. 이 둘은 같은 허용의 다른 표기가 아닙니다.

IPv4 헤더는 다음 프로토콜을 지정한다

프로토콜 필드는 IPv4 헤더의 한 바이트이며 페이로드를 설명하는 번호를 담습니다: TCP는 6, UDP는 17, GRE는 47, ESP는 50입니다. 패킷을 필터링하는 모든 것은 더 안쪽 헤더가 유형의 확인 후에야 의미를 가지므로 더 깊이 보기 전에 이 값을 읽습니다. 대화 도중 포트를 바꿔도 이 필드는 움직이지 않습니다.

따라서 프로토콜 47에 대해 작성한 규칙은 IP 계층을 설명합니다. 결정에 포트는 전혀 참여하지 않습니다.

포트는 TCP와 UDP 내부에만 존재한다

포트는 TCP와 UDP 헤더 내부의 십육 비트 식별자이며, 그 역할은 하나의 주소를 공유하는 대화를 구분하는 것입니다. GRE 헤더는 프로토콜 유형 값, 흔히 EtherType을 나르고, 다중화를 위한 선택적 키를 함께 가집니다. 그래서 포트 47이라는 표현은 GRE 패킷이 일치할 수 있는 무엇도 가리키지 않습니다.

방화벽 화면은 이 중 얼마나 보여 주는지가 다릅니다. 어떤 것은 프로토콜 번호를 받고, 어떤 것은 이름 목록을 제공하며, 몇몇은 포트가 있는 TCP나 UDP만 받습니다.

PPTP는 두 계층을 동시에 사용한다

PPTP가 가장 분명한 예인 이유는 작업을 의도적으로 두 계층에 나누기 때문입니다. 제어 연결은 포트 1723으로 가는 TCP 세션이고, 데이터 경로는 GRE, 즉 프로토콜 47이며 어디에도 포트가 관여하지 않습니다. 1723만 허용하는 방화벽은 협상을 시작하게 한 뒤 페이로드를 버립니다. 터널은 연결에 실패하는 대신 인증 후 멈춘 것처럼 보이며, 그래서 증상이 흔히 비밀번호 문제로 보고됩니다.

규칙을 작성할 때 두 행을 따로 읽고, 각각을 공급업체의 구문과 대조하십시오. 한 행은 포트가 필요하고 다른 행은 프로토콜 번호가 필요하며, 단일 항목이 둘을 모두 덮지는 못합니다.

포트 포워딩 페이지가 GRE를 표현할 수 없는 이유

TCP와 UDP만 받는 포워딩 양식은 그 이름이 무엇이든 GRE를 설명할 수 없습니다. 주소 변환은 GRE에 포트가 없어 변환 측이 대신 호출 식별자를 따라가야 하므로 두 번째 어려움을 더합니다. 일부 가정용 라우터에는 이를 처리하는 도우미가 있지만, 많은 제품에는 없고 TCP 허용 항목을 더 추가해도 그 동작은 생기지 않습니다.

현대적인 터널이 실제 요구라면 변환 측이 알아서 맞히기를 기대하지 말고 TCP나 UDP를 의도적으로 사용하는 설계를 택하십시오.

캡슐화가 필터가 보는 것을 결정한다

캡슐화는 바깥 패킷을 바꾸며, 규칙이 일치하는 대상은 바로 그 바깥 패킷입니다. 기본 ESP는 프로토콜 50이지만, NAT 통과는 ESP를 UDP 4500 안에 감싸서 주소 변환을 견디게 합니다. UDP 4500을 허용하는 필터는 프로토콜 50을 결코 보지 못하고, 프로토콜 50용으로 작성한 필터는 감싼 형태와 결코 일치하지 않습니다.

클라이언트와 게이트웨이가 어떤 캡슐화에 합의했는지 묻고, 그 바깥 형태에 대해서만 규칙을 작성하십시오.

누군가 검증할 수 있게 규칙을 작성한다

모든 규칙을 주소 패밀리, 바깥 프로토콜, 있으면 전송 포트, 방향, 양 끝점으로 표현하십시오. 검토자는 그 문장을 패킷 캡처와 비교해 판단에 이를 수 있습니다. 47을 열라는 지시는 누구도 검증할 수 없고, 그래서 절차서에 수년간 남습니다.

그것을 증명하는 시험을 추가하십시오: 바깥 인터페이스에서 캡처하면서 연결하고, 추적에 실제로 나타나는 바깥 프로토콜과 포트를 확인하십시오.