Ich habe eine Situation mit einem Debian-Jessie-Server, auf dem ich eine IP-Route manuell erstelle und sie nach der ersten Verwendung nicht mehr funktioniert.

In meinem Netzwerk habe ich 192.168.2.0/24- und 192.168.1.0/24-Subnetze, die größtenteils isoliert sind. In meinem Cisco RV325-Router erlaube ich jedoch eine Ausnahme für 192.168.2. * -Verkehr zu 192.168.1. * -Hosts (aber nicht umgekehrt). Dies funktioniert für alle anderen Clients (MacOS, Win10) in meinem 192.168.2. * -Subnetz ohne zusätzliche Konfiguration.

Auf meinem 192.168.2. * Debian-Server kann ich jedoch keine 192.168.1. * -Hosts erreichen. Also habe ich versucht, manuell eine Route (auf der Debian-Box) über hinzuzufügen

root@debian$ route -v 
Kernel IP routing table 
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface 
default         router          0.0.0.0         UG    1024   0        0 eth1
192.168.2.0     *               255.255.255.0   U     0      0        0 eth1

root@debian$ route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.2.1 metric 1

root@debian$ route -v
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         router          0.0.0.0         UG    1024   0        0 eth1
192.168.1.0     router          255.255.255.0   UG    1      0        0 eth1
192.168.2.0     *               255.255.255.0   U     0      0        0 eth1

Zu diesem Zeitpunkt kann ich erfolgreich eine Verbindung zu einem HTTP-Host im anderen virtuellen LAN herstellen:

root@debian$ telnet 192.168.1.24 80
Trying 192.168.1.24...
Connected to 192.168.1.24.
Escape character is '^]'.

Ich kann zum Beispiel manuell nach einer Webseite fragen und der Inhalt wird zurückgegeben. Die Verbindung wird dann geschlossen und jeder nachfolgende Versuch schlägt fehl:

Trying 192.168.1.24...
telnet: Unable to connect to remote host: No route to host

Das route -vzeigt immer noch die Route, die ich hinzugefügt habe, aber sie ist im Wesentlichen unbrauchbar. Was läuft hier falsch? Ist es wahrscheinlich, dass eine andere Software aktiv herunterfährt, was sie für illegitime Routen hält?

Ich habe diese verwandte Frage gesehen und alle drei aktuellen Antworten ausprobiert, von denen keine für mich funktioniert hat.

Ich habe versucht, Network Manager vollständig zu deaktivieren, aber das hat meine Standardroute verletzt, was ein viel ernsthafteres Problem darstellt. Daher stelle ich die Frage: " Wie füge ich mit Network Manager eine Route zu einem anderen Subnetz auf einem System hinzu ?" Manuell oder automatisch beim Booten sind beide in Ordnung.

Aktualisieren

Gemäß den folgenden Fragen zeigt iptables:

root@debian$ iptables -vnL
Chain INPUT (policy ACCEPT 5376 packets, 1052K bytes)
 pkts bytes target     prot opt in     out     source               destination         
 2490  184K fail2ban-ssh  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            multiport dports 22

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 3041 packets, 1187K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain fail2ban-ssh (1 references)
 pkts bytes target     prot opt in     out     source               destination         
   13  1016 REJECT     all  --  *      *       154.8.139.43         0.0.0.0/0            reject-with icmp-port-unreachable
    0     0 REJECT     all  --  *      *       192.99.122.172       0.0.0.0/0            reject-with icmp-port-unreachable
 2477  183K RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0       

Keine dieser IPs scheint relevant zu sein. Bevor ich die Frage stellte, habe ich versucht, den fail2ban-Dienst ohne Auswirkung zu deaktivieren.

ip addr auf den debian host shows:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether 00:26:55:db:36:fa brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:26:55:db:36:fb brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.34/24 brd 192.168.2.255 scope global eth1
       valid_lft forever preferred_lft forever

Hinweis: Ich habe eine zweite Netzwerkkarte (eth2) auf dem Computer, diese ist jedoch nicht angeschlossen und nicht angeschlossen. In der Routing-Tabelle nicht vorhanden.

Dies ist mit ziemlicher Wahrscheinlichkeit kein Routing-Problem auf Ihrem Client, sondern eher ein Firewall-Problem oder ein Problem auf dem Server.

Meine Vermutung wäre falsches Routing auf dem Server aufgrund einer falschen Netzmaske (möglicherweise 255.255.0.0, was ziemlich häufig vorkommt), kombiniert mit umgekehrter Pfadfilterung auf dem Client. Sie können dies überprüfen, indem Sie beispielsweise die Rückwärtspfadfilterung auf dem Client mit einem Befehl wie echo "1"> / proc / sys / net / ipv4 / conf / default / rp_filter deaktivieren. Die Lösung besteht jedoch darin, das Netzwerk auf dem zu reparieren Server, da die Pakete nicht an den Router zurückgesendet werden. (Dies kann auch das Zulassen von "RELATED" -Datenverkehr im Router beinhalten.)

Wenn dies fehlschlägt, sehen Sie in den iptables-Regeln nach, ob es dort blockiert ist. Sie können dies durch Eingabe von iptables -vnL feststellen. (Vielleicht möchten Sie diese posten, damit wir sie uns ansehen können.) Es könnte auch mit dem Router zusammenhängen, möglicherweise sogar mit einem NAT-Problem.

Im Allgemeinen besteht der nächste Schritt, wenn möglich, darin, ein Paket-Sniffing durchzuführen, um festzustellen, was den Computer verlässt und was vom Webserver und von vv empfangen wird. Sie können tcpdump (in einem separaten Fenster und dann eine Anfrage stellen) mit einem Befehl wie

tcpdump -n -i eth1 tcp src or dst 192.168.1.24

(Ich stelle fest, dass der von Ihnen hinzugefügte Routenbefehl redundant ist - und ich vermute, dass Sie seinen Zweck falsch verstehen. Dies ist jedoch nicht die Ursache für Ihr Problem. Wenn das Problem mit der umgekehrten Pfadfilterung zusammenhängt, können Sie möglicherweise den Router insgesamt umgehen ein Befehl wie route add -net 192.168.1.0 netmask 255.255.255.0 eth1 )