Warum habe ich Verbindungsprobleme in zwei Subnetzen?

492
c.jordan

Ich versuche, das Heimnetzwerk meines Nachbarn drahtlos mit meinem zu verbinden. Wir verfügen jeweils über eigene Internetdienste und Subnetze, die wir erhalten möchten, aber trotzdem auf Dienste zwischen unseren Subnetzen zugreifen können. Zu diesem Zweck habe ich zwei Ubiquiti NanoStation-M2-M2s erworben und in einer Testkonfiguration eingerichtet, wie im Diagramm dargestellt:

netzwerkdiagramm

Ich habe einen M2 an einen LAN-Port an meinem drahtlosen ASUS-Router angeschlossen. Der M2 hat den Wireless-Modus als "Zugangspunkt" und der Netzwerkmodus als "Router" konfiguriert. Der LAN0-Schnittstelle ist 192.168.5.50/24 zugewiesen (Gateway 192.168.5.1, DNS 192.168.5.1) und wlan0 ist 192.168.3.1/24 zugewiesen. Es hat eine statische Route, 192.168.2.0 über 192.168.3.2. Ab diesem Zeitpunkt kann ich zwei vorhandene Hosts in meinem Netzwerk, 192.168.5.10 und 192.168.5.13, erfolgreich pingen.

Bei dem anderen M2, das mit dem 192.168.2.0/24-Netzwerk verbunden ist, sind der Wireless-Modus als "Station" und der Network-Modus als "Router" konfiguriert. Die LAN0-Schnittstelle hat 192.168.2.2 zugewiesen (Gateway 192.168.2.1, DNS 192.168.2.1) und wlan0 hat 192.168.3.2/24. Dieses M2 hat eine statische Route, 192.168.5.0 über 192.168.3.1.

Der ASUS-Router an 192.168.5.1 verteilt DHCP und hat eine statische Route, 192.168.2.0 über 192.168.5.50.

Dem Laptop im Diagramm wird die statische Adresse 192.168.2.3 zugewiesen. Während des Tests wurde er direkt mit der "fernen" M2 verbunden. Ich könnte sofort 192.168.2.2, 192.168.5.50 und 192.168.5.13 pingen.

Hier fängt es an, merkwürdig zu werden.

Beim Versuch, von 192.168.2.3 auf 192.168.5.13 auf SSH zuzugreifen, wurde der Befehl für immer in die Länge gezogen, aber schließlich konnte ich mich verbinden. Ich habe den Befehl mit ausführlicher Ausgabe ausgeführt und festgestellt, dass ein Fehler bei der GSSAPI-Authentifizierung aufgrund eines Reverse-DNS-Lookup-Fehlers aufgetreten ist. Ich habe 192.168.5.1 zur Liste der DNS-Resolver auf dem Laptop hinzugefügt, wodurch dieses Problem behoben wurde und ich sofort eine Verbindung herstellen konnte.

Ich konnte jedoch überhaupt keine SSH auf 192.168.5.10 aufbauen. Ich kann es vom Laptop aus anpingen, aber wenn ich nicht manuell eine statische Route auf dem 5.10-Host für 192.168.2.0 über 192.168.5.50 hinzufüge, wird keine Verbindung hergestellt. Das Seltsame ist, dass der Host bei 192.168.5.13 diese statische Route nicht benötigt. es verbindet sich trotzdem. Der Laptop bei 192.168.2.2 hat keine statischen Routen und es wird keine Änderung vorgenommen, wenn eine statische Route hinzugefügt wird.

Ich kann den Laptop von 192.168.5.13 aus anpingen, die Ping-Ausgabe enthält jedoch ICMP-Weiterleitungen.

  1. Wie kann es sein, dass auf 192.168.5.13 ohne statische Route zugegriffen werden kann, aber 192.168.5.10 nicht?

  2. Sollte der oben genannte Zugriff nicht durch die statische Routeneingabe bei 192.168.5.1 abgedeckt werden?

  3. Fehlt eine Konfiguration oder eine falsche Konfiguration? Ich habe nach den DHCP-Optionen 141 und 249 gesucht. Ist dies der richtige Ansatz, um dieses Problem zu beheben?

3
Kannst du dies auf 2.3 ausführen: `ip route get 192.168.5.13` Ich denke, deine Konfiguration hört sich korrekt an, daher frage ich mich, ob es sich um eine zwischengespeicherte Route handelt. Paul vor 7 Jahren 0
Hast du die Brücke so eingerichtet? https://community.ubnt.com/t5/NanoStation-and-Loco-Devices/How-to-set-up-two-Nanostation-Loco-M2-s-as-a-wireless/td-p/524033 Vojtěch Dohnal vor 7 Jahren 0
In Ihrem Diagramm und Ihrer Frage haben Sie ausgelassen, welche IP-Einstellungen auf Computern vorhanden sind. Vojtěch Dohnal vor 7 Jahren 0
Würden Sie die Firewall-Einstellungen in 192.168.5.10 überprüfen? Bitte führen Sie auch eine Traceroute von 192.168.2.3 nach 192.168.5.10 und 192.168.5.13 durch, um zu prüfen, ob es Unterschiede gibt. Simon MC. Cheng vor 7 Jahren 0

1 Antwort auf die Frage

0
MariusMatutiae

Das hört sich nach einem Problem bei der umgekehrten Pfadfilterung an . Bearbeiten Sie (als Sudo) die Datei /etc/sysctl.confauf dem Debian-Rechner. Stellen Sie sicher, dass die beiden Zeilen wie folgt sind:

net.ipv4.conf.default.rp_filter=0 net.ipv4.conf.all.rp_filter=0

Speichern Sie, starten Sie den Computer neu und prüfen Sie, ob Sie immer noch Probleme haben. Wenn nicht, besteht die einfachste Lösung darin, die folgende Regel zur Asus-Firewall hinzuzufügen:

iptables -o ethN -j MASQUERADE

Wo ethNist der Name der Schnittstelle, mit der Ihre Centos- und Debian-Computer verbunden sind. Dies hätte den Vorteil, dass Sie eine Konfiguration auf dem eachPC speichern müssen, aber ich fürchte, Sie haben die proprietäre Firmware auf dem Asus, nichts dergleichen dd-wrt, openwrt, tomatound so weiter, habe ich recht? In diesem Fall müssen Sie das FM studieren, um zu sehen, ob dies überhaupt möglich ist. Oder Sie können prüfen, ob die Ubiquities das können (laufen sie EdgeOS? Wenn ja, dann können Sie die obige Regel sicherlich durchsetzen).

Verwandte Probleme