☰

목적지에 도달하기 위해 세 번째 서버를 사용할 수 있나요?

tag-icon • tag-icon linux networking
목적지에 도달하기 위해 세 번째 서버를 사용할 수 있나요?

대상 서버가 있는데 현재 넷마스크가 255.0.0.0으로 잘못 구성되어 있습니다. 올바른 넷마스크는 255.255.255.128입니다. 내 소스 서버도 /25 네트워크이므로 둘 다 동일한 서브넷 마스크를 갖지만 둘 다 서로 다른 두 개의 VLAN에 속합니다.

내 질문은 다음과 같습니다.

다른 VLAN 및 IP 범위(예: 157)에 속하는 다른 서버를 통해 대상 서버에 성공적으로 연결할 수 있습니다...그러나 10.10.126에서 대상 서버에 연결할 수 없습니다.. 대상 서버에서 경로 추적을 수행할 때 서버가 원본 IP가 자체 로컬 서브넷에 속하는지 로컬로 확인하는 것을 발견했습니다. 넷마스크가 잘못 구성된 경우 157.* 서버의 SSH 연결을 허용하는 이유는 무엇입니까? 어떻게 이루어 집니까?

현재 잘못된 구성:

Destination server: 10.10.127.*  netmask 255.0.0.0

현재 올바른 구성:

Source server:      10.10.126.*  Mask:255.255.255.128

시험용 tcpdump:

[root@Destination_server ~]# tcpdump -vvv -i eno16780032 host 10.10.126.*
tcpdump: listening on eno16780032, link-type EN10MB (Ethernet), capture size 65535 bytes
21:36:28.403812 IP (tos 0x0, ttl 64, id 48314, offset 0, flags [DF], proto TCP (6), length 60)
    10.10.126.*.60692 > Destination_server.ssh: Flags [S], cksum 0x3c87 (correct), seq 379301407, win 29200, options [mss 1380,sackOK,TS val 495338
91 ecr 0,nop,wscale 7], length 0
21:36:28.403928 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.10.126.* tell Destination_server, length 28
21:36:29.400303 IP (tos 0x0, ttl 64, id 48315, offset 0, flags [DF], proto TCP (6), length 60)
    10.10.126.*.60692 > Destination_server.ssh: Flags [S], cksum 0x3b8d (correct), seq 379301407, win 29200, options [mss 1380,sackOK,TS val 495341
41 ecr 0,nop,wscale 7], length 0
21:36:29.406300 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.10.126.* tell Destination_server, length 28
21:36:30.408295 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.10.126.* tell Destination_server, length 28
21:36:31.405136 IP (tos 0x0, ttl 64, id 48316, offset 0, flags [DF], proto TCP (6), length 60)
    10.10.126.*.60692 > Destination_server.ssh: Flags [S], cksum 0x3998 (correct), seq 379301407, win 29200, options [mss 1380,sackOK,TS val 495346 42 ecr 0,nop,wscale 7], length 0
21:36:35.412611 IP (tos 0x0, ttl 64, id 48317, offset 0, flags [DF], proto TCP (6), length 60)
    10.10.126.*.60692 > Destination_server.ssh: Flags [S], cksum 0x35ae (correct), seq 379301407, win 29200, options [mss 1380,sackOK,TS val 495356 44 ecr 0,nop,wscale 7], length 0
21:36:35.412738 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.10.126.* tell Destination_server, length 28
21:36:36.414276 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.10.126.* tell Destination_server, length 28
21:36:37.416282 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.10.126.* tell Destination_server, length 28
21:36:43.428318 IP (tos 0x0, ttl 64, id 48318, offset 0, flags [DF], proto TCP (6), length 60)
    10.10.126.*.60692 > Destination_server.ssh: Flags [S], cksum 0x2dda (correct), seq 379301407, win 29200, options [mss 1380,sackOK,TS val 495376 48 ecr 0,nop,wscale 7], length 0
21:36:43.428457 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.10.126.* tell Destination_server, length 28
21:36:44.430268 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.10.126.* tell Destination_server, length 28
21:36:45.432280 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.10.126.* tell Destination_server, length 28

답변1

목적지에 도달하기 위해 세 번째 서버를 사용할 수 있나요?

이론에 의하면.

세 번째 서버는 실패한 서버와 동일한 서브넷에 있어야 합니다.

기본적으로 "실제" 서브넷이 /25(255.255.255.128)이고 실패한 서버 IP가 10.10.127.10인 ​​경우 10.10.127.0에서 10.10.127.125 사이의 누구에게나 연결할 수 있습니다. 이러한 주소는 결함이 있는 서버와 동일한 네트워크에 있습니다.

왜

기본적으로 고려해야 할 두 가지 시나리오가 있습니다. 서버에 IP, 넷마스크 및 게이트웨이가 있다고 가정합니다. DNS 확인이 생략되었습니다. 단순화하다...

서브넷 내

네트워크의 호스트에 액세스하려고 하면 시스템을 떠나는 첫 번째 패킷은 ARP가 되며 "who-has my-ip-address" 메시지를 브로드캐스트합니다.

이에 대한 응답으로 피어의 하드웨어 주소가 반환된 "is-at 00:11:22:..." 메시지를 받을 수 있습니다. 그러면 메시지가 호스트에서 원격 장치로 직접 전송됩니다.

첫 번째 사용 사례는 동일한 LAN(또는 VLAN) 내의 통신에만 적용됩니다.

원격 서브넷

일반적으로 일부 원격 서비스에 액세스하려고 시도합니다. 대상의 IP 주소가 로컬 네트워크에 속하지 않는 경우 원본 서버는 해당 트래픽을 기본 게이트웨이로 전달합니다.

마찬가지로 게이트웨이 하드웨어 주소를 확인하기 위한 일부 ARP 확인 시도를 볼 수 있습니다(기본 게이트웨이임에도 불구하고 하드웨어 주소가 이미 ARP 캐시에 있을 수 있음).

거기에서 우리의 대상은 라우터에 연결된 특정 서브넷에 속하고 서브넷 내의 상황으로 돌아갑니다. 그렇지 않으면 라우터가 트래픽을 게이트웨이로 전달합니다.

157.2.3.5에 액세스할 수 있는 이유는 무엇입니까?

157.2.3.5가 10/8의 일부가 아니라는 점을 고려하면 해당 연결은 평소와 같이 게이트웨이를 통과하게 됩니다.

/25 대신 /8로 서버를 구성하면 기본적으로 해당 서버와 /25 부분 대신 이 /8에 포함된 모든 항목 간의 통신이 끊어집니다. 결함이 있는 서버는 이러한 네트워크가 로컬 네트워크라고 잘못 생각하기 때문에 ARP 확인을 시도하지만 아무런 응답도 얻지 못합니다.

리모컨이 10.10.127.0/25 또는 10/8 이외의 주소에 속해 있으면 연결 문제가 발생하지 않습니다.

관련 정보