몇 가지 이상한 점이 있습니다.
내 가상 머신:
centos7
상호 작용:
enp0s3: 192.168.10.110/24
lo:0 10.0.3.110/24 (ip alias)
노선:
default via 10.0.3.2 dev lo
192.168.10.0/24 dev enp0s3
enp0s3 is plugged in 10.0.3.0/24
ip_forward를 활성화했습니다(net.ipv4.ip_forward = 1).
내 질문:
ping 10.0.3.2
효과적이지만 왜?
tcpdump
패킷을 얻을 수 없지만 enp0s3
패킷을 얻을 수 있습니다 lo
.
기본 경로는 입니다 lo
. 왜 ping 10.0.3.2
작동합니까? 왜 패킷을 받을 수 없나요 enp0s3
?
답변1
루프백 인터페이스는 가상 인터페이스입니다. 루프백 인터페이스의 유일한 목적은 전송된 패킷을 반환하는 것입니다. 즉, 루프백 인터페이스에 보내는 모든 내용이 해당 인터페이스에서 수신됩니다. 루프백 인터페이스에 기본 경로를 설정하는 것은 별 의미가 없습니다. 왜냐하면 패킷을 보낼 수 있는 유일한 장소는 인터페이스 출력에서 입력 루프까지의 가상 라인이기 때문입니다. 루프백 인터페이스의 이러한 동작을 변경할 수 있는 것은 아무것도 없습니다. 이것이 바로 루프백 인터페이스의 목적입니다.
10.0.3.2에 대해 ping을 실행하면 일부 외부 장치가 아닌 루프백 인터페이스 자체에서 응답이 옵니다. 예를 들어 루프백 인터페이스에 주소를 추가하는 경우
sudo ip addr add 10.0.3.1/24 dev lo
10.0.3.0/24
경로가 추가되었습니다. 너는 이것을 볼 수 있다
ip route show table local
그것은 마치
local 10.0.3.0/24 dev lo proto kernel scope host src 10.0.3.1
나타나야 합니다. 이 라우팅 테이블 항목은 와 사이의 모든 주소로 전송된 패킷이 인터페이스를 통해 전송되고 10.0.3.1
해당 인터페이스에서 즉시 반환됨을 나타냅니다.10.0.3.254
lo
편집: 아래 의견에 대한 설명입니다.
10.0.3.2를 ping하면 다음과 같은 일이 발생합니다. 커널은 대상 주소가 10.0.3.2인 배달용 IP 패킷을 받습니다. 전달될 다른 패킷과 마찬가지로 커널은 라우팅 테이블을 참조합니다. 이 경우 일치하는 항목은 입니다. 이는 패킷이 local 10.0.3.0/24 dev lo proto kernel scope host src 10.0.3.1
소스 주소 10.0.3.1의 인터페이스를 통해 전송되어야 함을 나타냅니다.lo
lo
이제 패킷이 인터페이스 로 전송되었으므로 루프백 인터페이스는 일반적으로 수행하는 작업을 수행합니다. 즉, 패킷을 전송 대기열에서 꺼내어 수신 대기열에 넣습니다. 커널의 관점에서 보면 이제 소켓에서 수신 대기하는 서버 프로세스에 사용할 수 있는 수신 패킷이 있습니다. (ping의 경우 커널이 내부적으로 이를 처리합니다.) 이제 대상 주소가 10.0.3.2인 "원격" ICMP 패킷을 수신합니다. 이는 틀림없이 로컬 주소 중 하나가 아니지만 링 백으로 전달됩니다. 그래도 인터페이스에.
다음으로 커널은 ping에 대한 응답을 보냅니다. 즉, 역방향 주소가 있는 ICMP 응답 패킷입니다. 소스 주소는 10.0.3.2이고 대상 주소는 10.0.3.1입니다. 이는 루프백 인터페이스를 통해 ping 프로그램으로 다시 전달되어 10.0.3.2에서 응답을 받았음을 나타냅니다.
답변2
다른 질문에 대답하려면 "왜 enp0s3에서 패킷을 얻을 수 없습니까?"
LAN 192.168.10.0/24를 가리킵니다.
따라서 LAN에 패키지 배달 요청에 응답하는 서버가 없으면 해당 경로를 통해 쓸모없는 정보를 얻게 됩니다.