1.2.3.4두 개의 네트워크 인터페이스 A 와1.2.3.99B 가 있습니다 . (존재하다ifconfig)nc -l 1.2.3.99 20101 -vB 인터페이스를 모니터링하기 위해 달렸습니다 .nc -v 1.2.3.99 20101 -s 1.2.3.4 -4인터페이스를 사용하고 싶어서 달렸습니다A.
연결은 되어있는데 확인해보니 이나 에서 오는 패킷 wireshark은 없고 ,만 ...ABlo
연결된 IP와 인터페이스를 사용하지 않는 이유는 무엇입니까? 관련 인터페이스를 강제로 사용하려면 어떻게 해야 합니까?
편집하다:
Patrick의 조언을 따른 후:
ip route add local 1.2.3.99 dev B table main
ip route del local 1.2.3.99 dev B table local
ip route add 1.2.3.99 dev B table local
실행했지만 nc -l 1.2.3.99 20101TCP 서버를 생성할 때 오류가 발생합니다.Ncat: bind to 1.2.3.99:20101: Cannot assign requested address. QUITTING.
17:10:38 alexis:~ $ ip route list table local
1.2.3.99 dev B scope link
...
17:10:40 alexis:~ $ ip route list table main
default via 10.133.0.1 dev eth0
local 1.2.3.99 dev B scope host
...
답변1
특정 IP 주소를 사용하도록 애플리케이션에 지시하면 애플리케이션은IP 주소 사용, 인터페이스보다는. 일부 앱에서는 특정 인터페이스를 사용할 수 있지만 이는 별도의 작업입니다(SO_BINDTODEVICE).
애플리케이션은 인터페이스가 아닌 IP 주소에 바인딩되므로 커널은 원하는 인터페이스를 자유롭게 사용할 수 있습니다. 사용할 인터페이스를 결정하기 위해 라우팅 테이블을 사용합니다(예, 여러 개가 있습니다).
어떤 인터페이스/경로 트래픽이 걸릴지 빠르게 결정하는 방법을 원한다면 ip route get 1.2.3.99 from 1.2.3.4다음과 같은 결과를 출력하는 를 사용할 수 있습니다.
# ip route get 1.2.3.99 from 1.2.3.4
local 1.2.3.99 from 1.2.3.4 dev lo
cache <local>
이는 커널이 lo인터페이스를 통해 트래픽을 전송한다는 것을 나타냅니다.
이유를 이해하기 위해 다음 명령부터 시작해 보겠습니다 ip rule.
# ip rule
0: from all lookup local
32766: from all lookup main
32767: from all lookup default
여기에는 커널이 트래픽 경로를 찾는 데 사용할 모든 라우팅 테이블이 표시됩니다. 맨 위에서 시작하여 첫 번째 일치에서 중지됩니다. from all규칙이 모든 소스 주소와 일치함을 나타냅니다 . 그러니 먼저 표를 확인해 보세요 local. 그러면 우리는 이 테이블을 볼 수 있습니다:
# ip route show table local
broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1
local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1
broadcast 1.2.3.0 dev eth0 proto kernel scope link src 1.2.3.4
local 1.2.3.4 dev eth0 proto kernel scope host src 1.2.3.4
broadcast 1.2.3.255 dev eth0 proto kernel scope link src 1.2.3.4
local 1.2.3.99 dev eth1 proto kernel scope host src 1.2.3.99
(귀하의 모습은 다를 수 있습니다)
그런 다음 목적지가 두 번째 필드와 일치하는지 확인하여 목적지 주소(1.2.3.99)와 일치하는 경로가 있는지 확인합니다. 위 출력에서 마지막 출력이 일치합니다. 이 줄에서 첫 번째 필드는 local이며 그 man ip-route의미는 다음과 같습니다.
로컬 - 대상이 이 호스트에 할당됩니다. 패킷은 루프백되어 로컬로 전달됩니다.
이는 트래픽이 해당 인터페이스를 통해 흐른다는 것을 의미합니다 lo.
A/ 인터페이스 를 사용하는 방법에는 B두 가지 옵션이 있습니다.
1) 애플리케이션은 인터페이스를 지정할 수 있는 매개변수를 제공해야 합니다. netcat에는 다양한 종류가 있지만 내 시스템 버전에는 그러한 옵션이 없습니다. 그러나 그것은 사실입니다. ( netcat의 불일치와 이식성은 악몽이기 때문에 socat개인적으로 netcat을 사용하는 것이 좋습니다 . 또한 더 강력합니다).socat
2) local이전 경로와 일치하는 비 경로를 만듭니다 local.
ip route add local 1.2.3.99 dev B table main
ip route del local 1.2.3.99 dev B table local
ip route add 1.2.3.99 dev B table local
이 규칙 중 처음 2개는 local경로를 테이블로 이동합니다 main. 커널이 해당 주소에 대한 트래픽을 허용하려면 main호스트에 어딘가에 경로가 있어야 하므로 경로를 먼저 테이블에 추가해야 합니다 . local경로를 2개의 테이블에 넣으세요. 그런 다음 지정되지 않은 테이블에 새 경로를 local추가 하면 local트래픽이 해당 인터페이스를 통과하지 못하게 됩니다 lo.
답변2
debian과 opensd 에서는 netcat-openbsd사용할 라우팅 테이블을 선택할 수 있습니다.
옵션은 입니다 -V.
일상적인 경우에는 netcat이것이 불가능하다고 생각합니다.
socat를 사용하면 호출 시 선언되는 특정 인터페이스를 사용할 수 있습니다.
답변3
네트워크 인터페이스는 자신이 아닌 회선상의 다른 노드로 패킷을 보내도록 설계되었기 때문에 로컬 주소에 대한 액세스는 항상 루프백 인터페이스를 사용합니다.
답변4
간단한 대답
Linux 커널에는 두 개의 패킷 대기열이 있습니다. 하나는 패킷 전송용이고 다른 하나는 패킷 수신용입니다.
커널이 결정합니다(라우팅 테이블과 대상 주소를 기반으로 어떤 NIC 패킷이 물리적으로 도착할지).
그러나 커널이 대상 IP 주소가 소스 IP와 동일한 호스트에 있다는 것을 발견하면 이 패킷을 하나의 NIC에서 물리적으로 보내고 다른 NIC에서 받는 것은 의미가 없습니다. 이는 과잉이며 시간과 자원의 낭비입니다. 따라서 커널은 전송 대기열에서 패킷을 넣거나 제거하고 이를 수신 대기열에 넣습니다. 이 모든 일은 의사 네트워크 카드를 사용하는 커널에서 발생합니다. 루프백상호 작용 lo.
간단한 도식으로, 패킷 수신을 위한 또 다른 대기열이 있다고 가정해 보겠습니다.
