다음 토폴로지를 고려하십시오.
host B에서 로 ICMP(ping) 패킷을 보내고 있습니다 10.0.1.1. 그들은 목표를 달성했고 목표는 응답되었습니다 reply. 연결이 잘 작동하고 있습니다.
실행할 때 켜십시오.host A
tcpdump -i eth1 icmp: 패킷이 보이지 않습니다tcpdump -i eth2 icmp: 패킷을 봤어
eth1인터페이스로 전송하려는 패킷이 실제로 해당 인터페이스에 도착했는지 확인하는 방법이 있습니까 ?
어느 날 커널이 eth2수준(패킷이 도착하는 첫 번째 인터페이스)에서 응답을 처리한다는 내용을 읽었던 것을 어렴풋이 기억합니다. 이는 모니터링이 eth1아무것도 산출하지 못하는 이유를 설명합니다.
이 특정 사례를 확인해야 하는 이유는 다음과 같습니다. 패킷이 호스트의 인터페이스(가는 중 첫 번째 인터페이스)에 도착하지만 예상 인터페이스에 도착하지 않는 것 같은 상황이 있습니다(실제 애플리케이션은 그렇지 않습니다). 시작). 이러한 테스트를 통해 방화벽/전달이 정상인지, 문제가 다른 곳에 있는지(응용 프로그램 구성, 응용 프로그램의 버그 등) 확인할 수 있습니다.
답변1
Linux에서는 수신 패킷이 로컬 컴퓨터에서 처리되어야 하는지 여부를 확인하여 라우팅됩니다. 필요한 경우 먼저 "올바른 인터페이스"를 통해 라우팅하지 않고 직접 처리하십시오. IP 주소는 단지 시스템의 별칭일 뿐이며 패킷이 어떤 인터페이스에 도착하는지는 중요하지 않습니다.
로컬에서 이 작업을 수행하는 경우에도 동일한 일이 발생합니다 telnet 10.0.1.1. 로컬 시스템에서 자체 시스템으로의 모든 패킷을 처리하는 것으로 보이지는 않습니다 eth1.lo
그러나 아웃바운드 패킷의 경우 주소가 속한 인터페이스가 다릅니다. 커널은 먼저 패킷을 라우팅하는 방법을 결정한 다음 해당 경로를 기반으로 패킷에 가장 적합한 소스 IP를 선택합니다.
를 사용하여 "모든 패킷"을 확인해야 하는 경우 tcpdump그렇게 할 수 있습니다 tcpdump -i any icmp. 인터페이스는 표시되지 않지만 모든 패킷(예: 10.0.1.1.
답변2
당신이 말하는 주제는 약하다/강하다호스트 모델Linux는 기본적으로 약한 것을 사용합니다.
eth1 인터페이스용 패킷이 해당 인터페이스에 도착했는지 확인하는 방법이 있습니까?
방화벽이 그러한 제한을 가하는 것을 허용한다고 말하고 싶습니다.
패킷이 호스트의 인터페이스(첫 번째 패킷)에 도착했지만 예상한 인터페이스에 도착하지 않는 것 같은(실제 응용 프로그램이 시작되지 않는) 상황에 직면했습니다. 이러한 테스트를 통해 방화벽/전달이 정상인지, 문제가 다른 곳에 있는지(응용 프로그램 구성, 응용 프로그램의 버그 등) 확인할 수 있습니다.
이전 예에서 ICMP를 언급했습니다. 실제 연결을 확인하기 위해 이것을 사용하는 데 문제가 있습니까?
또한 이 시점에서는 제공을 위해 루프백 인터페이스를 사용하는 관행에 매우 가깝습니다. 이는 주로 동적 라우팅과 함께 사용되지만 주요 아이디어는 매우 간단합니다. 요청이 어떤 인터페이스에서 오는지는 중요하지 않습니다. 단지 방법을 찾았고 응답을 보낼 수도 있다는 것이 중요합니다. 루프백 인터페이스는 수동으로 지시하지 않는 한 종료되지 않습니다. "실제" 인터페이스 OTOH는 링크 손실 등으로 인해 상태를 변경할 수 있습니다.