☰

문맥

tag-icon • tag-icon vlan linux-networking ping gateway arp
문맥

문맥

2개의 서버가 있습니다:

server1 - eth0 10.129.76.16 eth0.2 192.168.0.103

server2 - eth0 10.129.79.1 eth0.2 192.168.62.101

192.xxx 주소는 동일한 VLAN(vlan2)에 연결되어 서로 볼 수 있습니다. 10.xxx 주소는 서로 볼 수 없는 다른 VLAN에 연결되어 있습니다.

David Swartz의 요청에 따라 서버 1의 라우팅 테이블은 다음과 같습니다.

~$ sudo route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.129.76.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.0.0     0.0.0.0         255.255.192.0   U     0      0        0 eth0.2
0.0.0.0         192.168.61.254  0.0.0.0         UG    100    0        0 eth0.2

서버 2의 라우팅 테이블은 다음과 같습니다.

~$ sudo route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         <public IP gw>  0.0.0.0         UG    100    0        0 eth0.11
10.129.79.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
<public IP>     0.0.0.0         255.255.255.128 U     0      0        0 eth0.11
192.168.0.0     0.0.0.0         255.255.192.0   U     0      0        0 eth0.2

문제:

서버 1에서 서버 2로 ping을 실행하면 패킷이 도착하지 않는 것 같고 그 반대의 경우도 마찬가지입니다. 경로(route -n)를 확인하면 기본 gw가 두 서버 모두에서 eth0.2를 사용하는 것을 볼 수 있습니다. 하지만 arping을 사용하면 단방향(서버 2에서 서버 1로)으로 응답을 받지만 그 반대의 경우에는 응답이 없습니다.

arping 192.168.62.101
ARPING 192.168.62.101 from 10.129.76.16 eth0
^CSent 2 probes (2 broadcast(s))
Received 0 response(s)

보시다시피 192.xxx 대신 10.xxx 주소를 사용합니다. 그리고 앞서 말했듯이 10.xxx 주소는 다른 서버에서 연결할 수 없습니다.

arping에서 eth0.2를 사용하도록 강제하면 작동합니다.

두 서버 중 어느 서버에서든 다른 서버를 핑하는 데 아무런 문제가 없습니다.

나는 arp 테이블에서 이것을 보았습니다.

~# arp -n | grep 192.168.0.103
192.168.0.103                    (incomplete)                              eth0

그리고

~# arp -n | grep 192.168.62.101

질문

아주 당연합니다... 이 서버들이 서로 다시 볼 수 있게 하려면 어떻게 해야 합니까?

내가 묶은 것들

arptable에서 적절한 항목을 지우고 (불완전)을 제거하려고 시도했지만 가장 큰 문제는 서버 1에서 서버 2로의 패킷에 eth0.2 대신 eth0이 사용된다는 것입니다.

라우팅 테이블에 대한 David Swartz의 언급으로 인해 호스트를 정의하는 경로를 추가했습니다. 나는 추가했다

192.168.0.103   0.0.0.0         255.255.255.255 UH    0      0        0 eth0.2

그리고

192.168.62.101  0.0.0.0         255.255.255.255 UH    0      0        0 eth0.2

해당 서버에 연결했지만 문제가 해결되지 않았으므로 라우팅에 문제가 없는 것으로 추정됩니다.

내 추측

문제는 다음에 있는 것 같아요.

~$ arp -n | grep 192.168.0.103
192.168.0.103                    (incomplete)                              eth0

하지만 이 항목을 제거할 수는 없습니다. (arp -d 192.168.0.103은 효과가 없습니다)

읽어주셔서 감사하고 답변해주셔서 더욱 감사드립니다!

답변1

다음은 일부 내용입니다.

arpping은 로컬 라우팅 테이블을 존중하지 않습니다.

== mbrownnyc [gateway/web/freenode] has joined ##networking
[10:14] <mbrownnyc> mAniAk-_-: any idea why, if his routing table reflects the proper interface to route 192.168.0.0/18 packets, why when he `arping 192.168.62.101` the kernel would think to make the source address that of the other interface?
[10:14] <mbrownnyc> it's very very weird to me
[10:16] <mbrownnyc> tafelpoot: unless arping has a bug in the code or something?
[10:17] <mbrownnyc> can you use another piece of software? like hping?
[10:17] <catphish> mbrownnyc: arping doesn't respect the routing table
[10:17] <catphish> you have to specify the interface manually
[10:17] <mbrownnyc> catphish: voila!
[10:18] <catphish> no idea why, it's just never been a feature of it, it seems to use the first ethernet interface unless you tell it otherwise
[10:19] <mbrownnyc> catphish: interesting catphish that's the whole "problem" here, the testing mechanism, I guess

icmp를 사용하여 테스트합니다.

[10:25] <catphish> mbrownnyc: that guy is testing with arping which makes no sense since arping doesn't use the routing table
[10:26] <catphish> it should be ping
[10:26] <catphish> and if ping fails, arping with an interface specified
[10:26] <mAniAk-_-> GG
[10:26] <catphish> oh, it does work when forcing arping to use the right address
[10:27] <catphish> so im not sure what the problem might be
[10:27] <mAniAk-_-> ARPING 192.168.62.101 from 10.129.76.16 eth0
[10:27] <mAniAk-_-> not eth0.2
[10:28] <catphish> indeed
[10:28] <catphish> because the interface wasn't specified
[10:28] <catphish> apparantly it works when the interface is specified
[10:28] <catphish> so i don't see the problem

네 VLAN은 괜찮아?

[10:29] <catphish> it's also possible the the vlan config is messed up, i don't like mixing native and tagged vlans like that
[10:29] <mAniAk-_-> yeah i thought so too

답변2

어떤 커널을 사용하고 있는지, 어떤 버전을 사용하고 있는지 언급하지 않았으며 arping둘 중 하나에 버그가 있을 가능성이 있습니다. 하위 인터페이스를 지정할 때 성공적으로 지정할 수 있다는 사실은 arping모든 레이어 2 네트워킹이 올바르게 작동하고 있음을 나타냅니다.

server1에서 사용하여 ip route get 192.168.62.101커널이 트래픽을 어떻게 보낼지 직접 물어보세요. 게시한 라우팅 테이블에 따르면 eth0.2를 통해 전송하는 것은 분명히 올바른 동작이며, ip route get다른 답변이 반환되면 커널 버그일 수 있습니다. 정답을 반환하면 arping책임이 있지만 그럴 것 같지 않습니다.

항목 (incomplete)을 제거할 필요는 없습니다. 이는 커널이 해당 IP를 ARP하려고 시도했음을 알려 ARP 응답이 유효한 것으로 간주되고 그렇지 않은 것으로 간주되도록 하는 자리 표시자입니다.ARP 포이즌 공격, 그러나 답변을 얻지 못했습니다. 시간이 초과됩니다.

관련 정보