참고 : 이것은 내 가정용 컴퓨터 실이며 비즈니스 / 생산 환경이 아닙니다. 나는 그것을 깨고 다시 고쳐서 기쁘다. 그래서 어떤 제안이라도 환영한다!
요약
이 질문이 점점 길어지기 때문에이 간단한 요약을 추가했습니다. 라우팅 테이블, IP 구성 등에 대한 자세한 내용은 아래를 참조하십시오.
컴퓨터에 몇 개의 NIC가 있습니다. 하나의 NIC는 172.16.200.1 / 24입니다. 172.16.200.2 (네트워크에 존재하는 호스트)를 ping하려고하면 응답이 나타납니다. 여태까지는 그런대로 잘됐다.
172.16.200.5 (또는 존재하지 않는 다른 호스트)에 연결하려고하면 컴퓨터가 기본 경로 (기본 게이트웨이 192.168.0.1을 통해 0.0.0.0)로 돌아갑니다. ISP 네트워크의 라우팅 루프에서 손실되는 홈 라우터. 필요한 경우 훨씬 더 자세한 내용이 아래에 나와 있지만 이미 답변을 구할 수있는 전문가가 있다고 생각합니다 ...
내 질문은 :
해당 네트워크의 호스트에서 응답이 없을 때 개인 네트워크의 기본 게이트웨이로 컴퓨터가 폴백 하는 것을 중지하는 방법 이러한 개인 네트워크에는 이미 메트릭이 낮은 명시적인 경로가 있습니다.
몇 대의 컴퓨터 (Server 2008 R2, Windows 7, Hyper-V Server 2012 R2, Windows Server 2012)에서이 테스트를 수행했으며 모두 동일한 방식으로 작동합니다. 나는 이것이 Windows 컴퓨터에서 '정상적인 행동'이라는 것을 받아들이 기 시작했지만 그것이 멈출 수 있는지 궁금합니다.
Windows VM과 동일한 구성으로 Ubuntu VM을 만들었습니다. Ubuntu VM은 Windows VM처럼 기본 경로로 대체되지 않습니다. 이 게시물 맨 아래에 Ubuntu VM 및 Windows 8.1 VM에 대한 라우팅 테이블 및 결과를 추가했습니다.
추가 세부 사항
이 주제에 대한 광범위한 검색을 수행했으며 내가 본 가장 가까운 질문은 다음과 같습니다. 라우팅 루프 : TTL이 전송 중에 만료 되었지만 불행히도 문제 를 중지 하거나 컴퓨터의 동작을 변경하는 방법에 대한 답변은 없습니다 . 정답은 라우팅 수정을 제안합니다. 개인 IP 주소로 향하는 모든 것을 삭제하도록 내 라우터를 변경할 수 있지만 (또는 내 동창 인의 IP, hehehe로 전달) 컴퓨터의 동작을 변경하지는 않습니다. (또한 https://serverfault.com/questions/49765/how-does-ipv4-subnetting-work 에서 찾을 수있는 원래 답변에서 참조 된 훌륭한 서브넷 가이드를 읽었습니다. )
내부 어댑터를 사용하여 (짧은 기간 동안) 시도한 후 실패한 경우 컴퓨터가 인터넷을 통해 개인 IP 주소에 연결을 시도하는 이유를 이해하는 데 어려움을 겪고 있습니다. 네트워크에 없습니다…
Pinging 172.16.200.32 with 32 bytes of data:
Reply from 172.16.200.1: Destination host unreachable.
Reply from 203.29.XXX.YY: TTL expired in transit.
Reply from 203.29.XXX.YY: TTL expired in transit.
Reply from 203.29.XXX.YY: TTL expired in transit.
Ping statistics for 172.16.200.32:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
그러나 존재하는 호스트를 핑 (ping)하면 작동합니다.
Pinging 172.16.200.2 with 32 bytes of data:
Reply from 172.16.200.2: bytes=32 time<1ms TTL=128
Reply from 172.16.200.2: bytes=32 time<1ms TTL=128
Reply from 172.16.200.2: bytes=32 time<1ms TTL=128
Reply from 172.16.200.2: bytes=32 time<1ms TTL=128
Ping statistics for 172.16.200.2:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
좋아, 그럼 172.16.200.1의 응답 내 컴퓨터는 응답이 수신되지 않았다 말하고있다 ...하지만, 왜 않습니다 심지어 내 인터넷 연결을 통해 연결을 시도? NIC 4 개가 있고 그 중 하나의 172.16.200.0 / 24 네트워크에 있습니다.
Ethernet adapter HyperV External (built in):
Connection-specific DNS Suffix . :
Link-local IPv6 Address . . . . . : fe80::582c:97
IPv4 Address. . . . . . . . . . . : 172.16.1.1
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :
Ethernet adapter Expansion-2 (middle) HomeNetwork:
Connection-specific DNS Suffix . : Home
IPv4 Address. . . . . . . . . . . : 192.168.0.117
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.0.1
Ethernet adapter Expansion-3 (bottom) iSCSI-1 :
Connection-specific DNS Suffix . :
IPv4 Address. . . . . . . . . . . : 172.16.100.1
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :
Ethernet adapter Expansion-1 (top) iSCSI-2:
Connection-specific DNS Suffix . :
IPv4 Address. . . . . . . . . . . : 172.16.200.1
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :
따라서이 시점에서 라우팅 테이블을 살펴 보는 것이 좋습니다.
===========================================================================
Interface List
16...64 70 02 00 1f 03 ......Gigabit PCI Express Network Adapter #2
15...64 70 02 00 40 48 ......Gigabit PCI Express Network Adapter
23...00 24 1d 1d f8 35 ......TST Onboard
17...64 70 02 00 32 c1 ......Gigabit PCI Express Network Adapter #3
1...........................Software Loopback Interface 1
28...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
26...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2
13...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
27...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #3
29...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #4
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.117 410
127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
172.16.1.0 255.255.255.0 On-link 172.16.1.1 266
172.16.1.1 255.255.255.255 On-link 172.16.1.1 261
172.16.1.255 255.255.255.255 On-link 172.16.1.1 261
172.16.100.0 255.255.255.0 On-link 172.16.100.1 266
172.16.100.1 255.255.255.255 On-link 172.16.100.1 266
172.16.100.255 255.255.255.255 On-link 172.16.100.1 266
172.16.200.0 255.255.255.0 On-link 172.16.200.1 266
172.16.200.1 255.255.255.255 On-link 172.16.200.1 266
172.16.200.255 255.255.255.255 On-link 172.16.200.1 266
192.168.0.0 255.255.255.0 On-link 192.168.0.117 266
192.168.0.117 255.255.255.255 On-link 192.168.0.117 266
192.168.0.255 255.255.255.255 On-link 192.168.0.117 266
224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
224.0.0.0 240.0.0.0 On-link 192.168.0.117 266
224.0.0.0 240.0.0.0 On-link 172.16.100.1 266
224.0.0.0 240.0.0.0 On-link 172.16.200.1 266
224.0.0.0 240.0.0.0 On-link 172.16.1.1 261
255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
255.255.255.255 255.255.255.255 On-link 192.168.0.117 266
255.255.255.255 255.255.255.255 On-link 172.16.100.1 266
255.255.255.255 255.255.255.255 On-link 172.16.200.1 266
255.255.255.255 255.255.255.255 On-link 172.16.1.1 261
===========================================================================
Persistent Routes:
None
처음 0.0.0.0 경로의 메트릭이 범인이라고 생각했습니다. 원래 6 개 였으므로 동작을 변경하지 않은 410으로 변경하려고했습니다. (이전에, 나는이 기계의 라우팅 테이블을 엉망으로 만들지 않았습니다). 그런 다음 동일한 네트워크 중 3 개 (172.16.1.0, 172.16.100.0 및 172.16.200.0)에있는 Hyper-V 2012 R2 시스템과 비교 한 결과 Hyper-V 시스템의 0.0에 대한 메트릭도 6으로 나타났습니다. .0.0 경로, 그래서 이것은 정상적이고 정확한 것 같아요 ...
그런 다음 172.16.200.0을 아래와 같이 지속적인 경로로 변경하려고 시도했지만 여전히 작동하지 않습니다.
===========================================================================
Persistent Routes:
Network Address Netmask Gateway Address Metric
172.16.200.0 255.255.255.0 172.16.1.1 1
===========================================================================
나는 또한 메트릭을 높이려고 노력했다 (낮은 것이 더 바람직하다는 것을 알고 있지만, 어쩌면?). 물론, 운이 없다.
네트워크 연결 창의 "고급 설정"에서 192.168.0.117 어댑터가 어댑터 및 바인딩 순서에서 가장 낮은 것을 확인했습니다…
그래서 머리를 약간 두드리고 난 후에 나는 충격을 받았습니다. 분명히 0.0.0.0 경로를 삭제하면 경로가 중지되지만 물론 인터넷도 중지됩니다.
172.16.200.0에서 호스트에 도달하려고 할 때 내 컴퓨터가 기본 게이트웨이 192.168.0.1을 통과하지 못하도록하려면 어떻게해야합니까?
http://technet.microsoft.com/en-us/library/cc779122%28v=ws.10%29.aspx("IP 라우팅 테이블 : TCP / IP ")는"기본 경로는 일반적으로 로컬 서브넷의 라우터에 대한 기본 게이트웨이 주소와 일치하거나 명시적인 로컬 경로가없는 IP 데이터 그램 " 그 길을 얼마나 더 명백하게 얻을 수 있습니까!
여기에 해답 사용 윈도우 지속적인 경로 게이트웨이를 사용할 수 있도록 기본 경로는 영구 경로를 추가 할 때, 가능하면 그 경로를 사용하려고하지만, 그 실패시 다시 기본 경로에 가을 -이 정상적인 동작이 제안합니다. 보안 문제 (인터넷으로 유출되는 개인 정보 또는 적어도 ISP의 개인 네트워크…)는 말할 것도없이 상당히 심각한 트래픽 문제가 발생할 수 있습니다.
몇 가지 추가 정보 :이 서버는 일반적으로 NPS / RRAS를 실행하여 서버를 비활성화하고 제거해도 아무 작업도 수행하지 않습니다. 또한 새로운 2008 R2 VM을 생성하고 하나는 192.168.0.0 네트워크에 직접, 다른 하나는 172.16.200.0 네트워크에 2 개의 NIC를 제공했으며 동일한 작업을 수행했습니다… 이것에 약간의 시간을 보냈습니다.
172.16.XX 항목을 모두 내 컴퓨터로 다시 전달하도록 홈 라우터를 설정했지만 해결 방법입니다.
누락 된 것이 있습니까? 아마도 뭔가 분명한가? 불가능을 묻고 있습니까?
[업데이트 # 1과 # 2]
라우터의 모든 구성 비트를 파헤 쳤으며 프록시 ARP 요청을 처리하지 않는 것 같습니다. 아마도 볼 수있는 설정이 없습니다.
라우터에서 ARP 요청에 응답하는지 여부를 테스트하기 위해 MS Network Monitor 3.4를 사용했습니다. 존재하지 않는 호스트를 ping하려고 할 때 ARP 요청이 전송되는 것을 볼 수 있으며 ARP 응답을받지 못했습니다. 존재하는 호스트를 ping하면 자연스럽게 ARP 응답이 제공됩니다. 이 시점에서 라우터가 프록시 ARP 요청을 처리하지 않는다고 가정하는 것이 안전합니까?
라우터의 라우팅 테이블은 다음과 같습니다.
> route show
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.20.21.36 * 255.255.255.255 UH 0 0 0 ppp0
192.168.0.0 * 255.255.255.0 U 0 0 0 br0
default * 0.0.0.0 U 0 0 0 ppp0
아래의 항목을 임시 스톱 갭 측정으로 추가했습니다. 불충분 한 "잃어버린"패킷이 ISP로 이동하지 못하게합니다.
172.16.1.0 192.168.0.117 255.255.255.0 UG 1 0 0 br0
172.16.100.0 192.168.0.117 255.255.255.0 UG 1 0 0 br0
172.16.200.0 192.168.0.117 255.255.255.0 UG 1 0 0 br0
[업데이트 # 3-우분투 및 Win8.1 VM 라우팅 테이블 추가]
이제 새로운 Ubuntu VM과 새로운 Windows 8.1 VM을 만들었습니다. 우분투 VM은 0.0.0.0 경로로 폴백하려고 시도하지 않지만 Windows 8.1은 그 경로로 돌아갑니다. 나는 존재하지 않는 오래된 ping 호스트를 시도하고 172.16.1.1 라우터의 트래픽을 보았습니다. Windows 8.1 VM에서 ICMP 요청을 수신하여 전달하지만 Ubuntu VM에서 ICMP 트래픽을 볼 수는 없습니다.
Ubuntu VM 테이블은 다음과 같습니다.
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface MSS Window irtt
0.0.0.0 172.16.1.1 0.0.0.0 UG 0 0 0 eth0 0 0 0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth1 0 0 0
172.16.1.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0 0 0 0
172.16.200.0 0.0.0.0 255.255.255.0 U 1 0 0 eth1 0 0 0
Windows 8.1 테이블은 다음과 같습니다.
===========================================================================
Interface List
9...00 15 5d 01 4c 1c ......Microsoft Hyper-V Network Adapter #2
3...00 15 5d 01 4c 08 ......Microsoft Hyper-V Network Adapter
1...........................Software Loopback Interface 1
4...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
13...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 172.16.1.1 172.16.1.101 5
127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
172.16.1.0 255.255.255.0 On-link 172.16.1.101 261
172.16.1.101 255.255.255.255 On-link 172.16.1.101 261
172.16.1.255 255.255.255.255 On-link 172.16.1.101 261
172.16.200.0 255.255.255.0 On-link 172.16.200.1 261
172.16.200.1 255.255.255.255 On-link 172.16.200.1 261
172.16.200.255 255.255.255.255 On-link 172.16.200.1 261
224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
224.0.0.0 240.0.0.0 On-link 172.16.1.101 261
224.0.0.0 240.0.0.0 On-link 172.16.200.1 261
255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
255.255.255.255 255.255.255.255 On-link 172.16.1.101 261
255.255.255.255 255.255.255.255 On-link 172.16.200.1 261
===========================================================================
Persistent Routes:
None