dlaczego ping nie działa?


0

Konfiguracja sieci wygląda jak na zdjęciu:

ustawienia sieci

  • port ethernetowy maszyny m1 et0 łączy się z portem ethernetowym maszyny m2 za pomocą przewodu krzyżowego.

  • maszyna m1 i m2 są w tej samej sieci: 1.1.1.0/24

  • M1 eth0 ma adres 1.1.1.1/24, a te wpisy zostały wprowadzone do tabeli routingu:

    # ip route add 2.2.2.0/24 via 1.1.1.4 //route to m3
    # ip route add 3.3.3.0/24 via 1.1.1.3 //route to m4
    
  • Maszyna M2 ma 3 karty Ethernet i działa jako router do maszyny m3 i maszyny m4, które znajdują się w sieci odpowiednio 2.2.2.0/24 i 3.3.3.0/24.

  • M2 ma net.ipv4.ip_forward = 1 w sysctl.conf

  • M2 eth0 ma adres 1.1.1.2/24, eth1 ma 1.1.1.4/24, eth2 ma 1.1.1.3/24. Są to polecenia wykonywane na m2, aby umożliwić routing w celu komunikacji wszystkich sieci

    # ip route add 2.2.2.0/24 via 1.1.1.4 //route to m3
    # ip route add 3.3.3.0/24 via 1.1.1.3 //route to m4
    
  • M3 eth0 ma adres 2.2.2.1/24, a te wpisy zostały wprowadzone do tabeli routingu:

    # ip route add 1.1.1.0/24 via 2.2.2.1 //route to m2 && m1
    # ip route add 3.3.3.0/24 via 2.2.2.1 //route to m4
    
  • M4 eth0 ma adres 3.3.3.1/24i wpisy te zostały wprowadzone do tabeli routingu

    # ip route add 2.2.2.0/24 via 3.3.3.1 //route to m3
    # ip route add 1.1.1.0/24 via 3.3.3.1 //route to m2 && m1
    

Pierwszym problemem jest

  • Mogę pingować M1, M3 i M4 z M2.
  • Mogę pingować M2 z M3 i M4
  • Ping NIE działa od M3 do M4 lub od M4 do M3.
  • Ping NIE działa również z M1 na M3 lub M4.
  • Ping NIE działa również z M3 / M4 na M1.

co robię źle?

Odpowiedzi:


0

M1 nie ma trasy do adresu 1.1.1.4 (lub .3), ponieważ jest to bezpośrednie połączenie z .2.

Jeśli spojrzysz na tablicę routingu na M1, będzie ona wyglądać mniej więcej tak

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
1.1.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

I tak uważa, że ​​powinno być w stanie połączyć się bezpośrednio z adresami 1.1.1.3 | 4 za pomocą przełącznika lub koncentratora.

Umieść łącze między M1 i M2 w innej podsieci i użyj adresu M2 jako domyślnej bramy dla M1 i zadziała.

Taka sama sytuacja występuje w przypadku połączeń z M3 / 4 do innych, muszą wiedzieć, którą trasę wybrać lub muszą wiedzieć ich routery domyślne.


0

Myślę, że twoim pierwszym problemem jest to, że oczekujesz tras z wieloma przeskokami - nie będą. Na przykład użyłeś tych poleceń na M1 i wydaje się, że oczekujesz, że wybiorą określone interfejsy wychodzące na M2:

# ip route add 2.2.2.0/24 via 1.1.1.4 //route to m3
# ip route add 3.3.3.0/24 via 1.1.1.3 //route to m4

To się nie stanie. Oba wpisy trasy będą przekazywać pakiet tylko na adres MAC M2 (ponieważ jest to host, który odpowiada na zapytania ARP dla obu adresów nexthop), ale M2 samodzielnie decyduje, gdzie dalej przekazywać te pakiety.

Tak więc trasy dodane do M1 powinny właśnie użyć adresu M2 skierowanego w stronę M1, tj via 1.1.1.2.


Drugi problem polega na tym, że M2 ma trzy interfejsy należące do tej samej sieci (1.1.1.0/24).

Zamiast tego, ponieważ M2 jest routerem i należy do wszystkich trzech sieciach naraz, powinny mieć adresy z tych sieciach: To znaczy, że 2.2.2.x/24na eth1 i 3.3.3.x/24na eth2.

(Dzięki temu nie trzeba nawet dodawać żadnych tras do M2 - wystarczyłyby trasy w lokalnej podsieci).


Trzecim problemem jest to, że trasy na M3 i M4 nie określają bramy, przez którą będą wysyłane pakiety. Mają tylko własny adres hosta , ale nie wskazują w żaden sposób, że pakiety „do M1” muszą faktycznie przechodzić przez M2.

Ponieważ trasy nie określają prawidłowej bramy / narzędzia Nexthop, są one traktowane jako trasy w lokalnej podsieci; innymi słowy, mówisz M3 / M4, że miejsce docelowe (M1) jest dostępne w lokalnej sieci Ethernet, nawet jeśli nie jest. Kiedy więc pingujesz M1 z M3 / M4, próbują rozwiązać adres IP M1 za pomocą ARP (co oczywiście się nie udaje).

(Pamiętaj, że Ethernet zawsze działa z przełączanym medium, a nie z punktu do punktu, więc M2 będzie odbierać tylko te pakiety, które zostały specjalnie wysłane na adres MAC (lub rozgłoszenie) M2. Innymi słowy, M2 musi być określony jako brama dla trasy do M1.)

Jeśli naprawiłeś już adresy IP M2 zgodnie z częścią II, trasy na M3 / M4 powinny wyglądać następująco:

(On M3)
# ip addr add 2.2.2.1/24 dev eth0
# ip route add 1.1.1.0/24 via 2.2.2.x  // <via M2's eth1 address>
# ip route add 3.3.3.0/24 via 2.2.2.x  // <via M2's eth1 address>

(On M4)
# ip addr add 3.3.3.1/24 dev eth0
# ip route add 1.1.1.0/24 via 3.3.3.x  // <via M2's eth2 address>
# ip route add 2.2.2.0/24 via 3.3.3.x  // <via M2's eth2 address>
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.