ICMP 리디렉트와 VPN 경로: 실제로 달라지는 것

터널을 지나야 할 흐름이 다른 다음 홉을 선택하고, 누군가 캡처에서 ICMP 리디렉트를 발견합니다. 그것은 진단이 아니라 가설입니다. 리디렉트는 더 나은 다음 홉에 대한 라우터의 제안이며, 호스트가 그것을 따르는지는 플랫폼과 인터페이스, 주소 체계에 따라 달라지는 설정에 좌우됩니다.

리디렉트는 라우터가 보내는 제안일 뿐입니다

IPv4 ICMP 리디렉트는 자체 메시지 유형과 좁은 조건을 가집니다: 라우터가 패킷을 들어온 인터페이스로 그대로 내보내고, 같은 링크에서 목적지에 더 가까운 다음 홉을 알고 있을 때입니다. 이어서 라우터는 송신자에게 그 홉을 직접 쓰라고 알립니다. 메시지에는 새 게이트웨이가 명시되고, 송신자가 흐름과 맞출 수 있도록 원래 패킷의 일부도 포함됩니다. 이것은 로컬 토폴로지에 관한 예의 메시지이며, 송신자가 제안된 게이트웨이와 같은 링크에 있다고 가정합니다.

송신자는 그것을 무시할 자유가 있습니다. 프로토콜은 호스트가 테이블을 바꾸도록 요구하지 않으며, 캡처된 리디렉트는 라우터가 하나를 보냈다는 사실만 증명합니다.

리디렉트 조사가 어긋나는 지점은 대개 이 구분입니다.

IPv4와 IPv6는 그것을 다르게 전달합니다

IPv6에는 ICMPv4가 아니라 이웃 탐색 안에 유사한 메커니즘이 있고, 메시지 형식과 검증 규칙도 다릅니다. 개념은 비슷하지만 패킷은 별개입니다. ICMP 유형 5용으로 작성한 캡처 필터는 IPv6 네트워크에서 아무것도 보여 주지 않으며, 이것이 리디렉트가 없었다는 증거로 잘못 읽히기도 합니다.

정책 설정도 따로이므로, 호스트가 IPv4 리디렉트는 받아들이고 IPv6는 무시하거나 그 반대일 수 있습니다.

해당 흐름이 둘 중 어느 쪽을 쓸 수 있다면 두 체계를 모두 확인해야 합니다.

수용 여부는 호스트 정책이지 네트워크 사실이 아닙니다

Linux에서는 리디렉트 수용이 인터페이스별로 그리고 전역으로 제어되며, 기본값은 호스트 역할과 라우터 역할에서 다릅니다. 리디렉트를 받아들이는 터널 인터페이스는, 지점 간 터널 안에 같은 링크의 대체 다음 홉이라는 의미 있는 것이 없으므로 이상한 설계입니다. 그래서 이 설정은 가정하지 말고 읽어 볼 가치가 있습니다.

보안 리디렉트 설정은 어떤 게이트웨이를 믿을 수 있는지 한층 더 제한합니다.

호스트를 조이고 있다면 검토할 설정이 바로 이것들이며, 같은 네트워크의 두 머신이 다르게 동작하는 이유도 여기에 있습니다. 디버깅 요령이 아니라 정책으로 바꾸십시오.

리디렉트로 설명할 수 없는 것

구체적 경로, 정책 라우팅 규칙, 로컬 인터페이스는 리디렉트가 전혀 없어도 예상 밖의 경로 대부분을 설명합니다. 더 구체적인 프리픽스, 출발지 주소와 일치하는 규칙, 또는 다른 테이블의 두 번째 기본 경로 는 모두 기대한 경로를 덮어씁니다. 결정적이고 눈에 보이므로 이것들을 먼저 확인하십시오.

네트워크를 바꾼 클라이언트는 로컬 게이트웨이가 다르므로 오래된 캡처도 함정입니다.

이전 연결에서 나온 오래된 리디렉트는 현재 경로에 대해 아무것도 설명하지 않으므로, 지금 제어 트래픽을 어느 인터페이스가 받는지 기록해 두십시오.

터널을 탓하기 전에 경로를 확인하십시오

커널에 목적지에 어떤 경로를 쓸지 물어보십시오, 그다음 그것을 의도한 테이블과 비교하십시오. 답이 테이블과 맞으면 리디렉트는 아무것도 바꾸지 않았고 조사는 다른 곳으로 가야 합니다. 맞지 않으면 터널이 문제라고 단정하기 전에 캐시된 리디렉트, 정책 규칙, 두 번째 테이블을 찾아보십시오. 경로 조회가 유일한 근거이며, 나머지는 그것이 어떻게 그렇게 되었는지에 관한 이야기입니다.

리디렉트 때문에 보호된 경로가 조용히 보호되지 않는 경로가 되어서는 안 되며, 그래서 수용 정책은 설계 검토에 들어가야 합니다. RFC 792 정의 는 IPv4 메시지가 무엇을 말할 수 있는지에 대한 기준으로 남아 있습니다.

경로 조회 결과와 캡처 시각을 함께 적어 두면 다음 사람이 당신의 결론을 재현할 수 있습니다.