동일 비용 경로가 VPN 장애를 알아보기 어렵게 만드는 이유

한 사용자가 내부 애플리케이션은 한 머신에서는 되고 다른 머신에서는 실패한다고 보고하지만, 게이트웨이에서 실행한 ping은 두 경우 모두 성공합니다. 같은 비용의 터널이 여러 개라면 이는 모순이 아닙니다. 각 흐름은 각자의 다음 홉에 배치되므로, 당신의 점검과 사용자 세션은 단순히 다른 경로를 쓰고 있을 수 있습니다. 아래의 절차는 무엇이든 바꾸기 전에 그 선택을 재현합니다.

한 번의 ping, 여러 가능한 경로

경로에 같은 비용의 다음 홉이 둘 이상 있으면 라우터는 패킷마다 하나를 골라야 합니다. 대부분의 구현은 패킷의 필드, 보통 출발지와 목적지 주소에 프로토콜과 포트를 더한 값을 해시하므로 응답이 같은 경로에 머뭅니다. 애플리케이션이 다르면, 같은 애플리케이션의 연결이 달라도 서로 다른 해시가 만들어집니다.

게이트웨이에서 한 진단이 그렇게 적게 증명하는 이유입니다. 게이트웨이 자체의 점검에는 자기 주소와 포트가 있고 따라서 자기 해시가 있습니다. 건강한 터널에 떨어지는 동안 사용자는 계속 망가진 터널에 떨어질 수 있습니다.

플랫폼이 다음 홉을 고르는 방법

추측하지 말고 그 선택을 재현하십시오. 실패하는 세션과 같은 출발지와 목적지에 커널이 어느 경로를 쓸지 물어보십시오. 그 조회에는 단순한 목적지 조회가 무시하는 필드도 포함됩니다. 동작하는 클라이언트에서도 실행하고 두 답을 비교하십시오:

ip route get 10.20.5.7 from 10.20.0.14

최신 iproute2 릴리스는 프로토콜과 목적지 포트도 받아들이며, 해시가 이를 포함할 때 중요합니다. 그 출력을 동작하는 클라이언트의 같은 조회와 비교하면, 그 차이가 당신에게 없던 증거입니다.

라우팅 테이블이 아니라 실패하는 흐름을 따라가십시오

라우팅 테이블은 두 터널을 모두 나열하고 정의상 올바르게 보입니다. 문제는 선택된 뒤에 각 터널이 패킷을 어떻게 처리하느냐입니다. 둘 다 같은 보호 프리픽스, 같은 전달 허용, 같은 클라이언트에 도달하는 반환 경로를 갖는지 확인하십시오.

중간의 상태 기반 장비에 주의하십시오. 요청이 한 터널로 나가고 응답이 다른 터널로 돌아오면, 원래 흐름을 한 번도 보지 못한 방화벽이나 NAT가 그것을 버립니다. 두 터널은 각각 트래픽을 올바르게 전달하는데도 연결은 실패합니다.

경로별 MTU도 확인하십시오. 추가 캡슐화가 있는 경로는 사용 가능한 크기를 줄이고, 한 터널에서 성공하는 전송이 다른 터널에서는 더 작은 쪽이 깨지는 바로 그 크기에서 멈춥니다.

한 번에 한 경로씩 비교하십시오

설계가 유지보수를 허용하는 곳에서는 터널 하나를 서비스에서 빼고 사용자의 작업을 반복하십시오. 장애가 사라지면 문제는 당신이 뺀 경로에 속하며, 다음 단계는 라우팅 테이블을 다시 살피는 것이 아니라 그 구성을 이웃과 비교하는 것입니다.

반복된 ping이 아니라 실제 애플리케이션을 비교하십시오. 장애가 특정 다음 홉, 패킷 크기, 재접속 후 전환 중 무엇을 따르는지 기록하십시오. 이 세 패턴은 서로 다른 수리를 가리키기 때문입니다.

마지막으로 경로가 왜 동등하다고 여겨지는지, 장애가 어떻게 그중 하나를 서비스에서 빼야 하는지 적으십시오. 다중 경로는 경로가 정말로 서로 바꿀 수 있을 때만 안전하며, 이는 가정할 것이 아니라 확인할 가치가 있는 설계 진술입니다.