Windows Yönlendirme Tablolarını ve Varsayılan Ağ Geçitlerini Anlama


11

Not: Bu benim ev bilgisayar laboratuvarım, bir işletme / üretim ortamı değil. Kırmak ve tekrar düzeltmek için çok mutluyum, bu yüzden herhangi bir öneri bekliyoruz!

ÖZET

Bu kısa özeti ekledim çünkü bu soru oldukça uzun sürüyor. Yönlendirme tabloları, IP yapılandırmaları vb. Hakkında daha fazla ayrıntı istiyorsanız, aşağıya bakın.

Bilgisayarda birkaç NIC'im var. Bir NIC 172.16.200.1 / 24'tür. 172.16.200.2'ye (ağda bulunan bir ana bilgisayar) ping atmaya çalıştığımda bir yanıt alıyorum. Çok uzak çok iyi.

172.16.200.5'e (veya var olmayan başka bir ana bilgisayara) bağlanmaya çalıştığımda, bilgisayar varsayılan rotama geri dönecek (varsayılan ağ geçidim 192.168.0.1 aracılığıyla 0.0.0.0) - bu daha sonra tarafından gönderilecek daha sonra ISS'ler ağımdaki bir yönlendirme döngüsünde kaybolacağı ev yönlendiricim. Gerekirse aşağıda çok daha fazla ayrıntı verilmiştir, ancak tahminimce buna zaten cevap verebilecek bir guru var ...

Sorum şu:

Bu ağdaki bir ana bilgisayardan yanıt alınmadığında bilgisayarımın özel bir ağ için varsayılan ağ geçidine düşmesini nasıl durdurabilirim ? Bu özel ağların zaten daha düşük metriklere sahip açık yolları var.

Bunu birkaç makinede test ettim (Server 2008 R2, Windows 7, Hyper-V Server 2012 R2, Windows Server 2012) ve hepsi aynı şekilde davranıyor. Bunun Windows makineleri için 'normal davranış' olduğunu kabul etmeye başlıyorum, ancak durdurulabileceğini merak ediyorum.

Windows VM'lerimle aynı yapılandırmaya sahip bir Ubuntu VM oluşturdum - Ubuntu VM, Windows VM'lerin yaptığı gibi varsayılan rotaya geri dönmüyor. Ubuntu VM ve Windows 8.1 VM için yönlendirme tablolarını ve sonuçlarını bu yazının altına ekledim.

DAHA FAZLA DETAY

Bu konuda kapsamlı arama yaptım ve gördüğüm en yakın soru burada: Yönlendirme döngüsü: TTL geçiş süresi doldu , ancak maalesef sorunun nasıl durdurulacağı veya bilgisayardaki davranışın nasıl değiştirileceği konusunda cevap vermiyor . Yanıt, yönlendirmenin düzeltilmesini önerir. Yönlendiricimi özel IP adresleri için hedeflenen her şeyi bırakacak şekilde değiştirebilirim (veya ev arkadaşlarımın IP'lerine iletebilirim, ancak bu bilgisayarımın davranışını değiştirmez). (Ayrıca /server/49765/how-does-ipv4-subnetting-work adresinde bulunan orijinal yanıtta referans olan harika alt ağ kılavuzunu da okudum )

İç bağdaştırıcılarını (kısa bir süre için) kullanmayı denedikten sonra bilgisayarlarımın neden özel IP adreslerine internet üzerinden bağlanmaya çalışacağını anlamakta sorun yaşıyorum - örneğin, bildiğim bir ana bilgisayara ping göndermede ağımda yok…

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),

Ama var olan bir ev sahibine ping atmak işe yarar ...

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

Tamam, 172.16.200.1 gelen cevap bilgisayarım hiçbir yanıt alındı söylüyor ... ama sonra, neden gelmez bile benim internet bağlantısı üzerinden bağlanmaya çalışırsanız? 4 NIC'im var ve bunlardan birinde 172.16.200.0 / 24 ağındayım…

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 . . . . . . . . . :

Bu noktada, yönlendirme tablosuna bakmak mantıklı olurdu…

===========================================================================
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

İlk olarak 0.0.0.0 rotasının metriğinin suçlu olduğunu düşündüm - başlangıçta 6 idi, bu yüzden davranışı değiştirmeyen 410'a değiştirmeyi denedim. (Bu arada, daha önce bu makinedeki yönlendirme tablosuyla hiç uğraşmadım). Daha sonra aynı ağlardan 3'ünde (172.16.1.0, 172.16.100.0 ve 172.16.200.0) sahip olduğum bir Hyper-V 2012 R2 makinesiyle karşılaştırdım ve Hyper-V makinesinin de 0.0 için 6 metriğine sahip olduğunu fark ettim. .0.0 rota, yani bunun normal ve doğru olduğunu tahmin ediyorum…

Daha sonra aşağıdaki gibi kalıcı bir rota olarak 172.16.200.0'ı değiştirmeyi denedim, ancak yine de işe yaramadı.

===========================================================================
Persistent Routes:
  Network Address          Netmask  Gateway Address  Metric
       172.16.200.0  255.255.255.0       172.16.1.1       1
===========================================================================

Ayrıca metriği artırmaya çalıştım (daha düşük olduğunu biliyorum, ama sadece enase, ha?)… Tabii ki, şans yok.

Ağ Bağlantıları Penceresinde "Gelişmiş Ayarlar" da 192.168.0.117 bağdaştırıcısının Bağdaştırıcılar ve Bağlamalar sırasının en düşük olduğunu doğruladım ...

Yani, kafamı biraz vurduktan sonra, güdük oldum. Açıkçası 0.0.0.0 rotasını silmek onu durdurur, ama tabii ki internetimi de durduracaktır…

172.16.200.0'da bir ana bilgisayara ulaşmaya çalıştığında makinemin varsayılan ağ geçidim 192.168.0.1'den geçmeye çalışmasını nasıl engelleyebilirim…

http://technet.microsoft.com/en-us/library/cc779122%28v=ws.10%29.aspx ("IP Yönlendirme tablosu: TCP / IP"), "Varsayılan yol genellikle bir Yerel alt ağdaki bir yönlendiricinin varsayılan ağ geçidi adresiyle eşleşen IP veri birimi (bununla eşleşen veya açık yerel yol bulunmayan). " Bu rota ile ne kadar daha açık olabilirim!

Buradaki cevap, Windows kalıcı yol ağ geçidi kullanılamıyor, bu nedenle varsayılan yol , bunun normal bir davranış olduğunu gösteriyor - kalıcı bir rota eklendiğinde, mümkünse bu yolu kullanmaya çalışacak, ancak başarısız olduğunda varsayılan yola geri dönecektir. Elbette bu, güvenlik sorunlarından (internete sızan özel bilgiler veya en azından İSS'lerinizin özel ağları ...) bahsetmemek için oldukça ciddi trafik sorunları oluşturabilir.

Bazı ek bilgiler: Bu sunucu genellikle NPS / RRAS çalıştırır - devre dışı bırakmak ve hatta kaldırmak hiçbir şey yapmadı. Buna ek olarak, yepyeni bir 2008 R2 VM oluşturdum, ona doğrudan 192.168.0.0 ağında, diğeri 172.16.200.0 ağında iki NIC verdim ve aynı şeyi yaptım… Umarım söyleyebilirim ki bunun için biraz zaman harcadı.

Ev yönlendiricimi 172.16.XX öğelerinin tümünü kendi bilgisayarıma iletecek şekilde ayarladım, ancak bu geçici bir çözüm…

Eksik olduğum bir şey var mı? Belli bir şey olabilir mi? İmkansızı mı soruyorum?

[GÜNCELLEME # 1 VE # 2]

Yönlendiricimdeki her yapılandırma bitini kazdım ve herhangi bir proxy ARP isteğini işlemiyor gibi görünmüyor - görebildiğim herhangi bir ayar bile yok.

ARP isteklerinin yönlendirici tarafından yanıtlanıp yanıtlanmadığını sınamak için MS Network Monitor 3.4'ü kullandım ve yanıtlanmadı. Var olmayan bir ana bilgisayara ping atmaya çalıştığımda ARP isteğinin gönderildiğini görebiliyorum ve herhangi bir ARP yanıtı almıyorum. Var olan bir ana bilgisayara ping atmak doğal olarak bana ARP yanıtı verir. Bu noktada yönlendiricimin proxy ARP isteklerini işlemediğini varsaymak güvenli mi?

Yönlendiricideki yönlendirme tablosu aşağıdaki gibidir:

 > 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

Aşağıdaki girişleri geçici bir durdurma boşluğu ölçüsü olarak ekledim - zayıf "kayıp" paketlerimin ISS'ime gitmesini engelliyor:

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

[UPDATE # 3 - Ubuntu ve Win8.1 VM'ler yönlendirme tabloları eklendi]

Tamam, bu yüzden yepyeni bir Ubuntu VM ve yepyeni bir Windows 8.1 VM oluşturdum. Ubuntu VM, 0.0.0.0 rotasına geri dönmeye çalışmaz, ancak Windows 8.1 yapar. Eski ping-a-non-ex-host'u denedim ve 172.16.1.1 yönlendiricideki trafiği izledim. Windows 8.1 VM'den ICMP isteklerini alır ve iletir, ancak Ubuntu VM'den hiçbir ICMP trafiği görmez.

Ubuntu VM tablosu aşağıdadır:

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 tablosu aşağıdadır:

===========================================================================
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

1. Yönlendiriciniz / güvenlik duvarınız dahili adres alanlarınız için proxy ARP yapıyor mu? 2. Yönlendiriciniz / güvenlik duvarınızdaki yönlendirme tablosu neye benziyor?
joeqwerty

1
RFC 1918 uzay paketlerinin dışarı çıkmasını durdurmak istiyorsanız, 10/8, 172.16 / 12 ve 192.168 / 16 numaralı null rotayı (veya LAN'ınıza geri yönlendirin) yeterlidir. Özel düzenlemeler olmadığında, bu paketler ağınıza yine de girmemeli / ağdan çıkmamalıdır. Her ne kadar bu en iyi yaklaşım olduğundan emin değilim (bazı başka şeyleri kırabilir).
CVn

Hangi Windows sürümlerinden bahsettiğinizi ve bu yayının genel tonunu göz önünde bulundurarak, kurumsal bir ortamda olduğunuzu tahmin ediyorum, bu durumda moderatörlerin dikkatini çekmek ve Sunucu Hatası'na geçiş talebinde bulunmak için bu yayını işaretlemeyi düşünebilirsiniz .
CVn

Merhaba Michael, cevap için teşekkürler. Bilgisayarıma (192.168.0.117) geri dönmek için yönlendiricime 10/8, 172.16 / 12 ve 192.168 / 16 rotaları ekledim, böylece internet üzerinden gönderilmiyorlar. Bu her yönlendiricinin yapılandırması gereken bir şey mi merak ediyorum? Ayrıca, bunun bir şirket veya iş ortamı değil, benim ev laboratuvarım olduğunu açıklığa kavuşturmalıyım. Sadece okumak için kullanıyorum.
Gund

Yanıtlar:


2

Vista'dan beri varsayılan rotaya geri dönme normal davranıştır, bu konuyu aşağıdaki makalede okuyabilirsiniz: Çok Homed Windows Bilgisayarda kaynak IP adresi seçimi .

Paketleri düşürmek yerine farklı alt ağ kullanarak geri gönderen yanlış yapılandırılmış yönlendiriciden kaynaklanan döngü sorunu.


Link sadece cevaplar bağlantı koparsa işe yaramaz hale gelir. Lütfen hala kaynağı aktarırken sorunun nasıl çözüleceğini açıklayın.
Raystafarian

Üzgünüz, bazı detaylar eklendi.
mtm

1
Merhaba, geç cevap için üzgünüm, ama bu bağlantı MTM için çok teşekkürler! Neden bu özel davranışı gördüğümü anlatıyor ve bana bunu değiştirerek araştırma yapmak için iyi bir başlangıç ​​noktası verdi.
Gund
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.