Uwaga: To jest moje domowe laboratorium komputerowe, a nie środowisko biznesowe / produkcyjne. Cieszę się, że mogę go naprawić i naprawić, więc wszelkie sugestie są mile widziane!
STRESZCZENIE
Dodałem to krótkie podsumowanie, ponieważ to pytanie jest dość długie. Jeśli chcesz uzyskać dodatkowe informacje na temat tabel routingu, konfiguracji adresów IP itp., Spójrz poniżej.
Mam kilka kart sieciowych na komputerze. Jedna karta sieciowa to 172.16.200.1 / 24. Kiedy próbuję pingować 172.16.200.2 (host, który istnieje w sieci), otrzymuję odpowiedź. Jak na razie dobrze.
Gdy spróbuję połączyć się z 172.16.200.5 (lub innym hostem, który nie istnieje), komputer wróci do mojej domyślnej trasy (0.0.0.0 przez moją domyślną bramę 192.168.0.1) - zostanie to wysłane przez mój domowy router, gdzie następnie zgubił się w pętli routingu w mojej sieci dostawców usług internetowych. W razie potrzeby podano o wiele więcej szczegółów, ale zgaduję, że istnieje guru, który już może odpowiedzieć na to pytanie ...
Moje pytanie brzmi:
Jak zatrzymać powrót komputera do domyślnej bramy sieci prywatnej, gdy nie ma odpowiedzi od hosta w tej sieci. Te sieci prywatne mają już wyraźne trasy o niższych parametrach.
Przetestowałem to na kilku komputerach (Server 2008 R2, Windows 7, Hyper-V Server 2012 R2, Windows Server 2012) i wszystkie zachowują się w ten sam sposób. Zaczynam rozumieć, że jest to „normalne zachowanie” komputerów z systemem Windows, ale jestem ciekawy, czy można to zatrzymać.
Utworzyłem maszynę Wirtualną Ubuntu z taką samą konfiguracją jak moje maszyny wirtualne z systemem Windows - maszyna wirtualna Ubuntu nie wraca do domyślnej trasy, tak jak robią to maszyny wirtualne z systemem Windows. Dodałem tabele routingu i wyniki dla maszyny Wirtualnej Ubuntu i Windows 8.1 VM na dole tego postu.
DALSZE SZCZEGÓŁY
Przeprowadziłem obszerne poszukiwania na ten temat, a najbliższe pytanie, które widziałem, jest tutaj: Pętla routingu: TTL wygasł w transporcie , ale niestety nie odpowiada, jak zatrzymać problem lub zmienić zachowanie na komputerze. Odpowiedź sugeruje naprawienie routingu. Mogę zmienić router, aby upuszczał wszystko przeznaczone na prywatne adresy IP (lub przekazywał je do adresów IP moich współlokatorów, hehehe), ale to nie zmieni zachowania mojego komputera. (Przeczytałem również świetny przewodnik po podsieciach, który był odniesieniem w oryginalnej odpowiedzi, który można znaleźć na stronie /server/49765/how-does-ipv4-subnetting-work )
Mam problem ze zrozumieniem, dlaczego moje komputery próbują połączyć się z prywatnymi adresami IP przez Internet, gdy próbują użyć swoich wewnętrznych adapterów (przez krótki okres), a następnie nie udają się - na przykład, próbując pingować hosta, który znam nie istnieje w mojej sieci…
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),
Ale pingowanie hosta, który istnieje, działa…
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
OK, więc odpowiedź z 172.16.200.1 brzmi: mój komputer mówi, że nie otrzymano odpowiedzi… ale dlaczego w ogóle próbuje się połączyć przez moje połączenie internetowe? Mam 4 karty sieciowe i jestem w sieci 172.16.200.0 / 24 na jednym z nich…
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 . . . . . . . . . :
W tym momencie warto spojrzeć na tablicę routingu…
===========================================================================
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
Najpierw pomyślałem, że przyczyną jest trasa 0.0.0.0 - pierwotnie była to 6, więc spróbowałem zmienić ją na 410, co nie zmieniło zachowania. (Nawiasem mówiąc, nigdy wcześniej nie zawiodłem w tabeli routingu na tym komputerze). Następnie porównałem go do maszyny Hyper-V 2012 R2, którą posiadam w 3 tych samych sieciach (172.16.1.0, 172.16.100.0 i 172.16.200.0) i zauważyłem, że maszyna Hyper-V ma również metrykę 6 dla 0,0 .0.0, więc zgaduję, że to normalne i poprawne…
Następnie próbowałem zmienić 172.16.200.0 na stałą trasę, jak poniżej, ale nadal nie działało.
===========================================================================
Persistent Routes:
Network Address Netmask Gateway Address Metric
172.16.200.0 255.255.255.0 172.16.1.1 1
===========================================================================
Próbowałem także zwiększyć metrykę (wiem, że niższa jest bardziej preferowana, ale po prostu zwiększ, co?)… Oczywiście, nie mam szczęścia.
W „Ustawieniach zaawansowanych” w oknie Połączenia sieciowe potwierdziłem, że adapter 192.168.0.117 jest najniższy w kolejności Adaptery i powiązania…
Więc po tym, jak trochę uderzyłem się w głowę, jestem zakłopotany. Oczywiście usunięcie trasy 0.0.0.0 zatrzymuje ją, ale oczywiście zatrzyma też mój internet…
Jak do cholery mogę powstrzymać moją maszynę przed próbą przejścia przez moją domyślną bramę 192.168.0.1, gdy próbuje ona dotrzeć do hosta 172.16.200.0…
http://technet.microsoft.com/en-us/library/cc779122%28v=ws.10%29.aspx („Tabela routingu IP: TCP / IP”) wydaje się sugerować, że „Domyślna trasa zwykle przesyła dalej Datagram IP (dla którego nie ma pasującej lub jednoznacznej trasy lokalnej) do domyślnego adresu bramy dla routera w lokalnej podsieci. ” O ile jaśniej mogę uzyskać dzięki tej trasie!
Odpowiedź tutaj Bramka trasy trwałej systemu Windows jest niedostępna, więc domyślna używana trasa sugeruje, że jest to normalne zachowanie - po dodaniu trasy trwałej spróbuje użyć tej trasy, jeśli to możliwe, ale w razie niepowodzenia wróci do trasy domyślnej. Z pewnością może to stwarzać dość poważne problemy z ruchem, nie wspominając o kwestiach bezpieczeństwa (prywatne informacje wyciekują do Internetu, a przynajmniej prywatne sieci twoich dostawców usług internetowych…)
Kilka dodatkowych informacji: na tym serwerze zwykle działa NPS / RRAS - wyłączenie go, a nawet usunięcie nic nie zrobiło. Ponadto utworzyłem zupełnie nową maszynę wirtualną R2 R2 2008, dałem jej dwie karty sieciowe, jedną bezpośrednio w sieci 192.168.0.0, a drugą w sieci 172.16.200.0 i zrobiło to samo… Mam nadzieję, że możesz powiedzieć, że mam spędziłem nad tym trochę czasu.
Ustawiłem router domowy, aby przekazywał wszystkie rzeczy 172.16.XX z powrotem na mój komputer, ale to obejście…
Czy czegoś mi brakuje? Może coś oczywistego? Czy pytam o niemożliwe?
[AKTUALIZACJA # 1 I # 2]
Przekopałem się przez każdy bit konfiguracji na moim routerze i wydaje się, że nie obsługuje żadnych żądań ARP proxy - nie ma nawet żadnych ustawień, które mogę zobaczyć.
Użyłem MS Network Monitor 3.4, aby sprawdzić, czy router odbiera żądania ARP, a nie są. Widzę, że żądanie ARP jest wysyłane, gdy próbuję wysłać polecenie ping do nieistniejącego hosta i nie otrzymuję żadnych odpowiedzi ARP. Pingowanie hosta, który istnieje, naturalnie daje mi odpowiedź ARP. Czy w tej chwili można bezpiecznie założyć, że mój router nie obsługuje żądań ARP proxy?
Tabela routingu na routerze BYŁA w następujący sposób:
> 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
Dodałem te wpisy poniżej jako tymczasowy środek stop-gap - powstrzymuje moje biedne „zagubione” pakiety przed przejściem do mojego dostawcy usług internetowych:
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
[AKTUALIZACJA # 3 - Dodano tabele routingu maszyn wirtualnych Ubuntu i Win8.1]
OK, więc utworzyłem zupełnie nową maszynę Wirtualną Ubuntu i nową maszynę wirtualną Windows 8.1. Ubuntu VM nie próbuje wrócić do swojej trasy 0.0.0.0, ale Windows 8.1 tak. Próbowałem starego hosta ping-a-nieistniejącego i obserwowałem ruch na routerze 172.16.1.1. Odbiera żądania ICMP od maszyny Wirtualnej Windows 8.1 i przekazuje je dalej, ale nigdy nie widzi żadnego ruchu ICMP z maszyny Wirtualnej Ubuntu.
Tabela VM Ubuntu znajduje się poniżej:
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
Tabela Windows 8.1 znajduje się poniżej:
===========================================================================
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
Odpowiedzi:
Powrót do domyślnej trasy po awarii jest normalnym działaniem, ponieważ Vista można przeczytać o tym w następującym artykule: Wybór źródłowego adresu IP na komputerze z systemem Windows z wieloma domami .
Problem z pętlą spowodowany błędnie skonfigurowanym routerem, który wysyła pakiety z powrotem za pomocą innej podsieci, zamiast je upuszczać.
źródło