Linux EHOSTUNREACH와 OpenVPN: 어느 다음 홉이 실패했는가?

EHOSTUNREACH는 원격 실패만큼이나 자주 로컬 결정입니다. 커널은 경로가 목적지에 도달할 수 없다고 말하기 때문에, Ethernet 다음 홉이 응답한 적이 없기 때문에, 또는 경로 더 멀리에서 ICMP host-unreachable 보고가 도착했기 때문에 패킷을 거부할 수 있습니다. 각 출처는 서로 다른 테이블이나 캐시에 살고, 각각 다른 곳에서 고칩니다. 암호나 터널 재설치를 건드리기 전에 선택된 경로와 다음 홉의 상태를 읽으십시오.

클라이언트가 실제로 사용하는 주소와 네임스페이스를 선택하십시오

오류를 일으킨 목적지와 네트워크 네임스페이스를 고정하는 것부터 시작하십시오. VPN 클라이언트는 자체 네임스페이스에서 실행될 수 있으며, 기본 네임스페이스에서의 조회는 다른 정책 규칙을 가진 다른 라우팅 테이블을 참조합니다.

조회는 실패하는 애플리케이션과 동일한 소스, 마크 및 테이블 컨텍스트를 사용해야 합니다. 그렇지 않으면 아무도 묻지 않은 질문에 답할 수 있습니다. 예시 IPv4 피어의 경우 읽기 전용 검사는 다음과 같습니다:

ip -4 route get 198.51.100.25
ip -4 neigh show 198.51.100.1
ip -4 route show table all | grep -w unreachable

관리 셸의 결과는 그 셸이 무엇을 할지 증명할 뿐입니다. 클라이언트가 방화벽 마크를 설정하거나 VRF에 바인딩하면 일치하는 마크로 또는 VRF 내부에서 조회를 반복하고 선택된 경로와 다음 홉을 비교하십시오. 먼저 확인할 주소는 프로필의 피어 주소이지 사용자가 지목한 클러스터나 서비스가 아닙니다.

명시적 도달 불가 경로는 패킷을 로컬에서 거부합니다

unreachable 유형의 경로는 의도된 로컬 응답입니다. 커널에 패킷을 버리고 EHOSTUNREACH를 송신자에게 돌려주라고 말하므로 오류가 즉시, 그리고 머신을 떠나는 트래픽 없이 나타납니다. 누군가 또는 어떤 자동화가 그 경로를 일부러 거기에 놓았습니다.

경로 유형은 서로 바꿀 수 없습니다. blackhole은 송신자에게 오류 없이 패킷을 버리고, prohibit는 EACCES를 반환하며, unreachable은 EHOSTUNREACH를 반환합니다. 따라서 재연결 중 싱크 경로를 설치하는 VPN 도우미는 터널이 올라오면 사라지는 host-unreachable 오류의 폭주를 만들 수 있는 반면, blackhole 경로는 대신 조용한 시간 초과를 만들었을 것입니다.

원격 끝을 탓하기 전에 모든 테이블에서 유형을 찾으십시오. 테이블을 선택하는 규칙은 그 안의 경로만큼 중요하며, 메인 테이블에 추가된 경로는 정책 규칙이 트래픽을 다른 곳으로 보내는 클라이언트에 도움이 되지 않습니다.

죽은 이웃은 Ethernet에서 같은 오류를 만듭니다

선택된 경로가 온링크 게이트웨이를 사용하면 전달에 확인된 링크 계층 주소가 필요합니다. 커널은 ARP 또는 IPv6 이웃 요청을 보내고, 응답이 없으면 패킷을 프레임할 수 없습니다. 그러면 경로 자체가 유효해도 전송이 EHOSTUNREACH로 실패합니다.

이웃 테이블은 단계를 지명합니다. INCOMPLETE는 확인이 아직 진행 중, FAILED는 마지막 시도가 응답을 받지 못함, REACHABLE 또는 STALE은 커널에 사용 가능한 주소가 있음을 뜻합니다. VPN 게이트웨이의 FAILED 항목은 로컬 전달 문제이지 터널 먼 쪽에 대한 증거가 아닙니다.

실제 다음 홉의 항목을 읽으십시오. 원격 인터넷 주소의 항목이 아닙니다. 원격 주소는 보통 라우터를 통해 도달하므로 자체 ARP 레코드가 없습니다. 그것을 요구하는 것은 존재할 리 없던 항목을 찾게 만드는 범주 오류입니다.

원격 보고와 비동기 UDP 오류

EHOSTUNREACH는 외부에서도 올 수 있습니다. 패킷을 전달할 수 없는 라우터가 ICMP host unreachable을 보낼 수 있으며, 커널은 그 보고를 흐름을 소유한 소켓에 전달합니다. 그 경우 경로와 이웃은 정상이고 실패는 로컬 네트워크 너머의 홉에 속합니다.

UDP는 원인 귀속을 어렵게 합니다. 이후 send 또는 receive 호출이 반환한 오류가 이전 데이터그램을 가리킬 수 있으므로 실패한 호출의 주소와 시각이 보고를 촉발한 패킷과 일치하지 않을 수 있습니다. 연결된 UDP 소켓은 오류를 한 번 받고, 연결되지 않은 소켓은 전혀 보지 못할 수 있습니다.

그래서 시각은 증거의 일부입니다. 오류가 언제 나타났는지, 소켓이 어떤 피어 주소를 사용했는지, 터널이 방금 재연결되었는지 기록하십시오. 경로 변경 직후의 폭주는 로컬 테이블을 가리키고, 안정된 흐름의 몇 분 후 단발 오류는 경로 보고를 가리킵니다.

암호를 바꾸기 전에 계층을 분리하십시오

세 가지 질문이 오류를 분류합니다. 커널이 목적지를 거부하는 경로를 선택했는가? 유효한 경로를 선택했지만 다음 홉을 확인하지 못했는가? 아니면 로컬 네트워크 너머에서 보고가 도착했는가? 세 번째 경우만 터널의 먼 끝을 관련시킬 수 있으며, 그때도 암호화는 관련시키지 않습니다.

인증과 협상 문제는 전송이 피어에 도달한 뒤 자체 오류로 나타납니다. 암호를 바꾸거나 클라이언트를 재설치해도 로컬 unreachable 경로를 고칠 수 없으며, 실제 원인에 필요한 경로와 이웃 증거를 파괴합니다.

첫 변경 전에 목적지, 네임스페이스, 선택된 테이블, 다음 홉, 이웃 상태, 오류 시각을 기록하십시오. 수정 후 같은 조회를 다시 실행하십시오. 이제 터널을 가리키는 경로와 이제 확인되는 이웃 항목은 무관한 주소에 대한 성공적인 ping보다 강한 증거입니다.