Server reagiert nicht mehr auf ARP Requests

V

vb-server

Registered User
Hallo zusammen

Ich habe gestern mit iproute2/Policy based Routing herumgespielt und nachher mit ip rule flush die Rules wieder gelöscht. Nun antwortet der Server nicht mehr auf ARP Requests. Trotz konfigurierter IP funktioniert nichts mehr.

IP: 10.64.107.33/39
OS: debian squeeze 64bit mit 3.2-bpo Kernel
Supermicro X7SPA-HF-D525 Mainboard

Habe bereits die Kernelmodule e1000e, STP, garp, bridge komplett unloaded und erneut geladen, war aber erfolglos. arp -a bringt keine MACs, Ping sagt network unreachable trotz Route auf eth0...

Hat jemand eine Idee? Komme echt nicht mehr weiter. Leider kommt ein Reboot momentan nicht in Frage.



Gruss
vb-server
 
Last edited by a moderator:
Wie hast Du die Route gesetzt (exakter Befehl bitte)?
Promiscuous mode mal deaktiviert?

Nach >220 Tagen sollte ein Reboot durchaus möglich sein, oder wie willst Du Bugfixe für den Kernel einspielen?
 
Hi und thx für die Antwort :)

Die Netroute kommt durch die IP-Konfiguration (ifconfig eth0 10.64.107.39/24). So sollte sich ja zumindest die .1 anpingen lassen. Promisc Mode kommt von tcpdump.

Rebooten werde ich nur, wenn dies nicht anders geht. Die Updates wurden natürlich installiert und wenns ein Kernelupdate gegeben hätte würd ich auch rebooten :)
 
Hm, scheint wohl ein Problem mit dem Netzwerkstack zu sein, kann nicht mal 127.0.0.1 bzw die IP von eth0 pingen.
 
100x ;) Hab nun doch meine 222d Uptime geopfert und rebootet. Funktioniert wieder. Waren wohl die IPRules, welche ich abgeschossen hab :S Jetzt muss ich nur das SourceBasedRouting noch zum laufen bringen.
 
Wenn du mit PBR arbeitest hilft dir der normale "route" Befehl nur noch ganz bedingt weiter.
Bei PBR werden mehrere Routingtabellen angelegt und es wird dann einfach je nach Source entschieden welche Tabelle genutzt wird. Die Regeln der PBR-Tabellen findest du dann natürlich nicht mit dem normalen Route-Befehl ;)
Btw: Im zweiten Screenshot sieht die Routingtabelle etwas verstümmelt aus - das System kennt keine Route mehr für die eigenen IPs an seinen eigenen Devices?!

Ich verwende selber PBR auf meinem Internetgateway zu Hause und kann dir ja ein paar Beispielbefehle geben - vielleicht hilft es dir ja:

Code: 
## Zwei PBR-Tabellen erzeugen die jeweils eine Default-Route auf ein 802.1q-Device enthalten
ip route add default table 100 dev vlan1
ip route add default table 200 dev vlan2

## Jetzt die Regeln erzeugen:
## von 188.246.9.xxx/29 nach irgendwo mit Priorität 9000 Routingtabelle 100 nehmen.
## Ich verwende immer recht hohe Prioritäten wenn das Ziel "all" ist, weil es praktisch die "Last-Resort-Route" ist.
ip rule add from 188.246.9.xxx/29 to all prio 9000 table 100
ip rule add from 46.41.18.xxx/29 to all prio 9000 table 200

## Jetzt müssen sich die Netze nur noch untereinander sehen können
ip rule add from 188.246.9.xxx/29 to 46.41.18.xxx/29 prio 100 table 200
ip rule add from 46.41.18.xxx/29 to 188.246.9.xxx/29 prio 100 table 100
Ansehen kannst du dir die Routingtabellen mit diesen Befehlen:
Code: 
## Die PBR-Tabellen anzeigen
ip route list table 100
ip route list table 200

## Die Regeln anzeigen
ip rule list
 
Hi und thx für die Antwort :)

Genau so hab ich das versucht, danach geflusht und die default rules waren weg. War wohl das.

Zum Thema PBR: Ich habe in einem RZ ein /26 Subnetz. Nehmen wir an es ist 192.0.2.192/26, davon 192.0.2.192/28 als OpenVPN Transitnetz. Nun möchte ich 192.0.2.224/27 auf die OpenVPN IP des Homeservers routen. Wenn ich jetzt ja auf so eine geroutete IP zugreife, kommt die Antwort des Servers über den Default GW meines ISPs zuhause. Das funktioniert ja nicht und sollte nicht sein. Alles was über OpenVPN reinkam soll auch wieder über OpenVPN raus. Das sollte doch mit PBR machbar sein, oder? (sagen Source 192.0.2.224/27 über den OpenVPN GW) Hast du da vielleicht grad eine Idee?


Viele Grüsse,
vb-server
 
Klar, geht recht einfach ;)
Ach wie habe ich diesen Satz damals im Mathe-Unterricht gehasst...

Angenommen dein OpenVPN-Device heißt "tun0", die interne Netzwerkkarte fürs LAN eth0, die Netzwerkkarte fürs WAN eth1 und dein lokales Netz lautet 172.16.0.0/24 sähen die Regeln so aus:

Code: 
ip route add default table 100 dev tun0
ip route add default table 200 dev eth0
ip route add default table 300 dev eth1

ip rule add from 172.16.0.0/24 to 192.0.2.224/27 prio 2000 table 300
ip rule add from 192.0.2.224/27 to 172.16.0.0/24 prio 2000 table 200

ip rule add from 192.0.2.224/27 to all prio 9000 table 100
 
Last edited by a moderator:
Jetzt wo du es sagst...
Bin mir nicht sicher ob du das brauchst (weil eigentlich die regulären Routen vorher greifen müssten), habe aber mal zur Sicherheit den Post über dir ergänzt.
Ist aber ungetestet - kann gut sein dass ich irgendwas übersehen habe ;)
 
OK, soweit klar. Aber das Transitnetz müsste ja auch noch eine Rule haben oder?


eth0: ISP-zuhause -> Firewall (10.64.107.1) -> Server (10.64.107.39)
tap0: VPN-GW-RZ (188.92.xxx.193/28) -> Server (188.92.xxx.196/28, auf .196 routed 188.92.xxx.224/27)

Nun müsste man doch das Ganze so machen, dass 188.92.xxx.196/32 sowie 188.92.xxx.224/27 den Gateway 188.92.xxx.193 auf dem dev tap0 nutzen. Sehe ich das soweit richtig? Weil dann könnte ich am Homeserver ein VLAN machen, welches eine IP aus 188.92.xxx.224/27 hat. Und daran Clients mit PublicIP's hängen.
 
Das Transitnetz braucht eigentlich keine Regel - da beide Gegenstellen eine direkte Route dafür besitzen müsste es eigentlich auch ohne gehen.
 
Ja, habs nun geschafft, war leichter als gedacht :)

Code: 
ip route add default via 188.92.xxx.193 dev transit table 200
ip rule add from 188.92.xxx.224/27 to all table 200

Vielen Dank :)
 
Habe trotzdem noch eine Frage zu Policyrouting

Subnetz ist 192.0.2.0/26
Transit über GRE-Tunnel
RZ: 10.10.0.1/30, Home: 10.10.0.2/30
Router im RZ:
Code: 
route add -net 192.0.2.0/26 gw 10.10.0.2
Router zuhause:
Code: 
ip rule add from 192.0.2.0/26 to all table 200
Code: 
ip route add default via 10.10.0.1 dev gre0 table 200
IP zuhause: 192.0.2.66
Die gerouteten IPs liegen auf eth1.


Das Ganze funktioniert soweit auch. Wenn ich jedoch auf eine IP des gerouteten Netzwerks trace, sehe ich als 2tletzter Hop (Router zuhause) dessen IP, welche bei eth0 definiert ist. Es wird also die Source Adresse von eth0 verwendet, für die ICMP Reply, anstatt die vom gre0 Interface. Wieso das? Kann man das irgendwie ändern? Sieht sehr komisch aus.


Viele Grüsse
vb-server
 
AW: Server reagiert nicht mehr auf ARP Requests

Das liegt daran, dass der Host immer über die Route antwortet die er zum traceroutendem Ziel kennt - und das dürfte bei dir vermutlich die Defaultroute über eth0 sein ;-)
 
You must log in or register to reply here.
Back
Top