전송 모드와 터널 모드: 도식이 아니라 패킷으로 결정하라

교과서 도식은 전송 모드를 두 호스트에, 터널 모드를 두 게이트웨이에 짝지어 주며, 그 경험칙은 이를 깨는 첫 배포까지만 유효합니다. 모드는 ESP 패킷이 무엇을 감싸는지를 설명하며, 누가 양 끝인지는 다루지 않습니다. 게이트웨이가 전송 모드로 트래픽을 보호할 수 있고, 호스트 한 쌍이 원하면 터널 모드를 쓸 수도 있습니다. 세 가지 질문이 특정 배포에 무엇이 필요한지 정합니다.

모드는 배치이지 토폴로지가 아니다

전송 모드에서는 ESP 헤더가 IP 헤더 뒤, 다음 계층 페이로드 앞에 오므로 원래 IP 헤더는 바깥에 남아 보입니다. 터널 모드에서는 보호되는 내용이 완전한 IP 패킷이며, 새로운 외부 헤더가 두 IPsec 피어를 지목합니다.

기밀성을 선택하면 터널 모드의 보호 영역에 그 내부 IP 헤더가 포함되므로, 캡처로는 키 없이 실제 종단점을 알 수 없습니다. 외부 헤더는 두 경우 모두 읽을 수 있고, 바로 그것이 문제 해결을 가능하게 합니다.

첫 번째 질문: ESP 안에 정확히 무엇이 있는가

애플리케이션이 만드는 패킷을 보고 어떤 경계가 그것을 보호하는지 물으십시오. 답이 이미 올바른 두 주소 사이의 전송 페이로드라면, 두 번째 헤더를 만들지 않고도 전송 모드가 맞습니다. 보호되는 내용이 자체 주소를 필요로 한다면, 실제 종단점이 트래픽을 나르는 피어와 다르기 때문이며, 그 일은 터널 모드가 합니다. 두 경우 모두 같은 조직에 있으므로 정책 한 문장으로 모든 것을 덮기는 어렵습니다.

그 질문은 캡처와 라우팅 테이블로 답할 수 있습니다. 상자를 클라이언트와 서버로 표시한 그림으로는 답할 수 없습니다. 어느 피어에서든 찍은 캡처는 두 가지 중 무엇을 보고 있는지 몇 초 안에 보여 줍니다.

두 번째 질문: 안에 이미 터널이 있는가

L2TP 이 점을 보여 주는 역사적 반례입니다. 서비스는 L2TP 세션 안에서 PPP를 나르고, IPsec이 그 교환을 보호합니다. 배치는 전송 모드를 지정하며 터널 모드는 선택 사항으로 허용됩니다. 눈에 보이는 결과는 서비스 수준의 터널이고, 그 외부 보호는 전송 모드를 씁니다.

따라서 제품 설명에 터널이라는 단어가 있다고 해서 그 아래 계층의 모드에 대해 말해 주는 것은 없습니다. 어떤 질문이 그것을 정했는지 기록하십시오. 이름에서 추론하는 대신 그 조합의 명세를 읽는 습관이 제품이 무엇을 지원해야 하는지에 대한 논쟁 대부분을 막습니다.

세 번째 질문: 피어가 무엇을 요구하는가

두 피어는 합의해야 하며, 한쪽이 한 모드를 제안하는데 다른 쪽이 두 번째를 요구하는 제안은 조용히 나빠지는 대신 협상 중에 실패합니다. 원격 끝의 소유자에게 정책이 어떤 모드를 지목하는지 묻고, 문서 요약이 아니라 제안을 확인하십시오.

혼합 환경은 흔합니다. 게이트웨이 하나가 레거시 제품을 위한 전송 모드 세션과 사이트 링크를 위한 터널 모드 세션을 종료하며, 모드는 장치별이 아니라 연결별입니다. 기능 이름 대신 연결 목록을 요청하십시오. 이름이 구성보다 빨리 퍼지기 때문입니다.

존재하는 연결 읽기

검토를 위해 피어, 모드, 선택자, 다음 계층 프로토콜을 나열하고, 결과를 감싸는 캡슐화가 있으면 덧붙이십시오. 주소 변환은 자체 외부 관점을 더할 뿐 모드가 아니며, 변환된 흐름도 여전히 둘 중 하나입니다. 목록은 연결을 의도가 아니라 설치된 모습으로 보여 주는 유일한 산출물입니다.

라우팅과 권한 질문으로 마무리하십시오. 올바른 패킷 배치는 어떤 서브넷이 허용되는지, 응답 경로가 있는지를 알려 주지 않습니다. 그것들은 정책과 라우팅 테이블에 살며, 어느 것도 모드에 대한 논증을 바꾸지 않습니다.