28.03.2017, aktualisiert am 29.03.2017

3881

Statische Routen mit Shorewall, ISC-DHCP Server konfigurieren für Android Devices

Hallo,

ich versuche derzeit einen DHCP Server einzurichten.
Debian 8.7 mit ISC-DHCP.
Der Server liegt auf einer 3 Wege Firewall (shorewall) 192.168.1.246, die aus dem inneren Segment (192.168.1.0) einerseits nach außen geht und andererseits in ein (noch ungenutztes) DMZ Segment.
Außerdem liegt im inneren Segment eine Windows Domäne mit DNS und DHCP Server, den ich angehalten habe. Der ISC-DHCP ist sozusagen der Versuch, den Windows DHCP abzulösen.

Das innere Segment hat auf einem anderen System (Hardware) über einen weiteren Router (192.168.1.245) einen Zugang zu einer bestehenden DMZ.(192.168.2.0).
Das Routing funktioniert aber leider nur in den Windows Systemen.
Hier klappt ein Ping oder Trace in die bestehende DMZ problemlos.

Das gleiche funktioniert nicht mit einem Android Device (Pixel C oder Samsgung Galaxy Tab).
Die Geräte gehen schlicht über die Default Route nach draußen, was ich mittels Fling und Net Info geprüft habe.

Die Konfiguration sieht derzeit so aus:
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.120 192.168.1.139;
option routers 192.168.1.246;
#option static-routes 192.168.2.233 192.168.1.245;

Push static routes with ISC DHCP server to leases tables.

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 333417

Url: https://administrator.de/contentid/333417

Ausgedruckt am: 26.11.2024 um 11:11 Uhr

27 Kommentare

Neuester Kommentar

Moin,

Ich habe das Gefühl, dass ich hier irgendwie auf der falschen Spur bin und würde mich sehr über Hinweise freuen.

jepp so ist es, statische Routen gehören natürlich immer auf das Gateway nicht auf den Client! So ist man nicht darauf angewiesen wie DHCP-Clients die Optionen interpretieren, oder ob sie diese Optionen überhaupt anwenden.

Also ab auf die Firewall/GW mit der statischen Route:
ip route add 192.168.2.0/24 via 192.168.1.245

Und schon ist dein Problem gelöst.

http://linux-ip.net/html/tools-ip-route.html
Gruß p.

Mmh, ich dachte genau dafür würde DHCP eben auch eingesetzt?
Nur zum Verständnis:
statt auf dem Gateway dem DHCP Server statische Routen einzutragen, die er dann (erfolglos) einem Client übermittelt, soll ich auf OS Ebene die Route hinzufügen?
Ein Client würde also per Default Gateway am Router / Gateway ankommen, dort für einen spezifischen Zielbereich die statische Route erhalten und zu einem anderen Router weitergeschickt?

Zitat von @terminator:

Mmh, ich dachte genau dafür würde DHCP eben auch eingesetzt?

Für statische Routen gaaaaaanz selten, die gehören auf die Router und nicht die Clients.

Nur zum Verständnis:
statt auf dem Gateway dem DHCP Server statische Routen einzutragen, die er dann (erfolglos) einem Client übermittelt, soll ich auf OS Ebene die Route hinzufügen?

Korrekt!

Ein Client würde also per Default Gateway am Router / Gateway ankommen, dort für einen spezifischen Zielbereich die statische Route erhalten und zu einem anderen Router weitergeschickt?

Absolut richtig!

Moin,

Also zunächst mal müsstest du dir das TCP/IP Protokoll anschauen.
Dort findest du immer Quell- und Ziel-IP

Vereinfacht gesagt:
Wenn die Ziel-IP nicht im gleichen Subnetz wie die Quell-IP liegt, wird das Paket immer zum Gateway gesendet (sofern dem Client bekannt).
Wenn im Gateway statische Routen eingetragen sind, nimmt das Gateway das Paket und sendet es an das Gatway, welches in ihm als Ziel für die Ziel-IP angegeben wurde. Das nächste Gateway weiss dann, was es mit dem Paket machen soll: wieder weiterleiten.
Der Client bekommt davon nichts mit, warum auch? Hat ihn ja erstmal nicht zu jucken, wohin die Pakete gehen, hauptsache es kommt an und er bekommt eine Antwort.

Am DHCP-Server gibst du dem Client also nur (neben IP und Subnetzmaske) das Gateway und die DNS-Server mit.
Bei erforderniss ggf. noch solche Dinge wie NTP- oder BootP-Server...

https://www.edv-lehrgang.de/router-im-ip-netzwerk/
http://www.elektronik-kompendium.de/sites/net/0903151.htm

Mit clientseitigen statischen Routen haben wir mal in folgendem Szenario gearbeitet:
Sporadisch mussten wir für einer der Gruppe angehörigen Gesellschaft im IT-Support "support" leisten.
Da das aber nur von zwei Clients aus der gesamten IT zulässig und für diese Schwestergesellschaft ein anderes Gateway existent gewesen ist, haben wir dann kurz eine clientseitige Route gesetzt. IP: 192.168.123.0/24 an GW 192.168.08.15
Hätte man sicherlich auch anders lösen können, aber der Weg ist dann der pragmatischste gewesen, ohne gleich der gesamten IT mittels zusätzlicher Firewall den Zugang zu diesem Netz zu gewähren.

Gruß
em-pie

Das ist jetzt etwas peinlich, ich hatte die statische Route schon irgendwann mal bei meinen Versuchen eingegeben.
Hab das unten mal aufgeführt, show, restart (manuelle route futsch), manuelles add (route wieder da)

root@gw:~# ip route show
default via 192.168.4.102 dev eth2
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.246
192.168.2.0/24 via 192.168.1.245 dev eth0
192.168.4.0/24 dev eth2  proto kernel  scope link  src 192.168.4.192
192.168.6.0/24 dev eth1  proto kernel  scope link  src 192.168.6.191
root@gw:~#
root@gw:~#
root@gw:~# /etc/init.d/networking restart
[ ok ] Restarting networking (via systemctl): networking.service.
root@gw:~# ip route show
default via 192.168.4.102 dev eth2
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.246
192.168.4.0/24 dev eth2  proto kernel  scope link  src 192.168.4.192
192.168.6.0/24 dev eth1  proto kernel  scope link  src 192.168.6.191
root@gw:~# ip route add 192.168.2.0/24 via 192.168.1.245
root@gw:~# ip route show
default via 192.168.4.102 dev eth2
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.246
192.168.2.0/24 via 192.168.1.245 dev eth0
192.168.4.0/24 dev eth2  proto kernel  scope link  src 192.168.4.192
192.168.6.0/24 dev eth1  proto kernel  scope link  src 192.168.6.191
root@gw:~#

Problem also, es wird ignoriert von Android.

Dabei wäre auch die Frage, was es hier bei solchen Änderungen für "Latenzen" gibt. Die Frage klingt vielleicht blöd, aber in der Windows Welt mit DHCP und DNS und AD hatte man gefühlt immer etwas Zeit, bis solche Änderungen bei den Clients "ankamen", caches aktualisiert waren usw.
Oder anders: Müsste eine solche Änderung sofort greifen?

Ist doch logisch warum die Route weg ist wenn du neu startest, obiger Befehl schreibt das nicht permanent in die Routing-Tabelle, für den permanenten Eintrag trägt man das in die Config ein:
http://www.prontosystems.org/tux/persistant_route

Routing-Tabellen Einträge am Gateway wirken sofort! Da gibt es keinen Cache bei den Clients.

Du solltest dir wirklich erst mal das 1 mal 1 des Routings aneignen, bevor du die Praxis anwendest.

Durch ein ip route add wird die Route aber nicht persistent abgelegt

Nach jedem Reboot ist die weg.
http://www.cloudibee.com/static-route-linux/

Problem also, es wird ignoriert von Android.

nicht von Android, den interessieren die am GW hinterlegten Routen nicht.

Dabei wäre auch die Frage, was es hier bei solchen Änderungen für "Latenzen" gibt. Die Frage klingt vielleicht blöd, aber in der Windows Welt mit DHCP und DNS und AD hatte man gefühlt immer etwas Zeit, bis solche Änderungen bei den Clients "ankamen", caches aktualisiert waren usw.

Was für Änderungen? Wenn du Routen an einem Gateway anlegst, muss da nichts zu einem Client gesendet werden.

Oder anders: Müsste eine solche Änderung sofort greifen?

Ja.

Äh langsam, ich hab die 1. Antwort von em-pie nicht gesehen.

Also, das eine manuelle route nicht persistent ist, ist mir klar. Ich habe das nur so dargestellt, wie es war.
Ich hatte bereits vor meinem Post hier die route mal probehalber angegeben, und sie wurde ignoriert, mir war das aber nach den verschiedenen versuchen nicht mehr klar.

Problem bleibt nachwievor, die manuelle Routenangabe zieht nicht bei den Android Devices. Wenn sie funktionieren würde, würde ich sie natürlich sofort so festnageln.

@em-pie

Wie soll ich das verstehen:

Zitat von @em-pie:

...

Problem also, es wird ignoriert von Android.

nicht von Android, den interessieren die am GW hinterlegten Routen nicht.

Genau das will ich doch, auch Android Devices sollen die Route annehmen.

Wenn deine Androiden die Routen nicht nehmen nutzen sie nicht dein Default GW, ganz einfach!
Öffne auf deinen Androids eine Konsole und lass dir mit tracert die Routenverfolgung anzeigen, dann hast du es schwarz auf weiß.
Ein packet dump zeigt dir ebenfalls was Sache ist.
Ich glaube hier hapert es eher an den Grundlagen.

ok, soweit so gut
Laut network info II bekommt das Android eine IP vom DHCP Server auf dem Gateway und es hat das Gateway als Gateway eingetragen. Ein traceroute nach draußen läuft auch normal über das Gateway, genauso wie ein traceroute in die DMZ, das geht ebenfalls über das gateway "glatt" nach draußen.

Naja, dass es an Grundlagen hapert, ist offensichtlich, deswegen frage ich ja hier.

Zitat von @132692:

Genau das will ich doch, auch Android Devices sollen die Route annehmen.

Du hast den Satz etwas falsch interpretiert/ hatte ich den unglücklich formuliert.

Wenn du am GW Routen setzt, ist es dem Client völlig egal, welche Routen dort liegen. Der Client weiss nur "ich muss die Pakete ans GW schicken, wenn sich das Ziel nicht in meinem Subnetz befindet!".

Wichtig ist also nur, dass der Client mitgeteilt bekommt, wie die IP seines Gateways lautet. Und genau das musst du in deinem DHCP-Server hinterlegen.

Welche IP-Settings bekommt dein Android denn (zu ersehen in den Einstellungen)?

Gruß

Wenn die Phones wirklich korrekte IP Settings haben bleibt eigentlich nur noch die shorewall auf der die ACLs falsch gesetzt oder Einschränkungen vermerkt sind.

Der Server liegt auf einer 3 Wege Firewall (shorewall)

Ja, ich hab es mittlerweile kapiert. Der Client kennt nur das Gateway, die static routes optionen sind nur für Ausnahmefälle gedacht.
Das Android Gerät bekommt eine IP aus dem Range des DHCP auf dem Gateway.
Es hat den Gateway 1.246 auch eingetragen.

Ich werde die static routen Optionen löschen und das Gateway wieder allein eintragen.

Ich weiß leider nicht, was Du mit ACL meinst. Schau ich nach.
Mir wäre dann aber auch nicht klar, warum die Windows Clients die Route zur DMZ finden.

Zitat von @terminator:

statt auf dem Gateway dem DHCP Server statische Routen einzutragen, die er dann (erfolglos) einem Client übermittelt, soll ich auf OS Ebene die Route hinzufügen?
Ein Client würde also per Default Gateway am Router / Gateway ankommen, dort für einen spezifischen Zielbereich die statische Route erhalten und zu einem anderen Router weitergeschickt?

Nein, die statische Router wird nciht per dhcp verteilt!

Der Client schickt das Paket an sein default gateway,

Der schickt das Paket anhand seiner routingtabelle an das Ziel weiter, wenn das anhand der statischen Route ein anderes ist als das WAN-Interface, dann halt dorthin.

ggf schickt der noch ein icmp-redirect an den Client, damit der in Zukunft weiß, wo er die nachfolgenden Pakete hinschicken soll. Allerdings wird in den meisten netzen ICMP-Redirekt blockiert, weil man damit unsinn treiben kann.

lks

PS: Du solltest Dich ein wenig mit den Grundlagen des IP-Routing beschäftigen.

Ok, ACL ist klar, kenne ich als Windows Entwickler in anderem Zusammenhang.

Wie gesagt, die Windows Clients aus Segment 1 kommen problemlos in die DMZ.
Allerdings nur solange, wie diese statischen Routeneinträge drin sind. Ich habe sie eben rausgenommen und die Windows Clients finden die DMZ nicht mehr.
Der Android Client, gleiches Segement wie die Windows Clients, kommt mit oder ohne static routes nicht in die DMZ.

Das sieht jedenfalls danach aus, dass die Windows Clients das anders handhaben, als ein Android Client.

Der Hinweis zu icmp ist im Zusammenhang mit der Firewall vielleicht ein guter Tipp.

Zitat von @Lochkartenstanzer:

Nein, die statische Router wird nciht per dhcp verteilt!

PS: Du solltest Dich ein wenig mit den Grundlagen des IP-Routing beschäftigen.

Dass DHCP keine statischen Routen verteilt, hab ich schon geschnallt. Allein das Verhalten der Windows Clients nach Abschalten der statischen Routen scheint etwas anderes zu sagen.

Und ja, was soll ich sagen, ich beschäftige mich ja gerade ein wenig mit den Grundlagen. Mir ist bewusst, dass ich kein Plan hab. Ich bin Datenbankentwickler und muss halt mit dem ### hier irgendwie klar kommen.

Zitat von @terminator:
Mir wäre dann aber auch nicht klar, warum die Windows Clients die Route zur DMZ finden.

Deswegen gibt es ja die Firewall, die sagt du darfst in ein bestimmtes Netz oder nicht. Das lässt sich auf unterschiedlichste Weise festlegen, anhand von Source-IP,MAC, etc. pp.
Wie und über welche Geräte deine Androiden ins Netz kommen hast du uns auch noch nicht verraten.

Und zum Thema Grundlagen: Die erarbeitet man sich nicht in einem Admin-Forum sondern liest sie sich erst einmal an!
Ich setz mich ja auch nicht ohne Führerschein in ein Taxi und kutschiere Leute durch die Gegend.

Zitat von @132692:

Deswegen gibt es ja die Firewall, die sagt du darfst in ein bestimmtes Netz oder nicht. Das lässt sich auf unterschiedlichste Weise festlegen, anhand von Source-IP,MAC, etc. pp.
Wie und über welche Geräte deine Androiden ins Netz kommen hast du uns auch noch nicht verraten.

Und zum Thema Grundlagen: Die erarbeitet man sich nicht in einem Admin-Forum sondern liest sie sich erst einmal an!
Ich setz mich ja auch nicht ohne Führerschein in ein Taxi und kutschiere Leute durch die Gegend.

Die Firewall hat keine gerätespezifischen Regeln, es gibt nur Zonen.
Die Android Geräte gehen über einen WLAN AP ins 1er Segment, falls Du das meinst.
Der WLAN AP arbeitet nicht als DHCP.
Er hat keine statischen Routen eingetragen.

Seit der Abschaltung der statischen Routen kommt ein Windows Client im LAN nicht mehr in die DMZ.

Die Erarbeitung von Grundlagen ist ja ein dehnbarer Begriff. Das mache ich natürlich in dem Rahmen, wie es mir sinnvoll erscheint, Dinge die ich nicht gelesen habe oder falsch verstehe, sind dann letztlich der Punkt, die mich dazu bringen, hier zu fragen. Du kannst davon ausgehen, dass die Zeit, die ich mit dem Thema hier im Forum verbracht habe, ein Bruchteil der Gesamtzeit ist, in der ich mich damit beschäftige.
In welchem Grundlagenwerk finde ich bspw. Aussagen wie "statische Routen per DHCP" werden nur in Ausnahmefällen angelegt?

Seit der Abschaltung der statischen Routen kommt ein Windows Client im LAN nicht mehr in die DMZ.

Ist ja auch korrekt so, ohne Route kein Weg zum Netz und das DefGW fragt seinerseits sein DefGW also das ProviderGW.

In welchem Grundlagenwerk finde ich bspw. Aussagen wie "statische Routen per DHCP" werden nur in Ausnahmefällen angelegt?

Wenn du das Kapitel Routing durchhast erledigt sich die Frage von alleine

Zitat von @132692:

Seit der Abschaltung der statischen Routen kommt ein Windows Client im LAN nicht mehr in die DMZ.

Ist ja auch korrekt so, ohne Route kein Weg zum Netz und das DefGW fragt seinerseits sein DefGW also das ProviderGW.

In welchem Grundlagenwerk finde ich bspw. Aussagen wie "statische Routen per DHCP" werden nur in Ausnahmefällen angelegt?

Wenn du das Kapitel Routing durchhast erledigt sich die Frage von alleine

Kann es sein, dass wir aneinander vorbeireden?
Ich habe die statische Route Option zur DMZ (segment2) im DHCP Server abgeschaltet. Der Router selbst hat wie von dir empfohlen die Route in die DMZ per ip rout add erhalten. Wenn also irgendein Client mit einer Zieladresse im Segment 2 ankommt, sollte ihm da vom Gateway geholfen werden. Das wurde doch von verschiedener Seite hier so dargestellt.

Und ja, wenn lesen allein so erfolgreich wäre und alles wie im Lehrbuch, wundert es mich, dass es all diese Foren gibt.

Zitat von @terminator:

Zitat von @132692:

Gut hattest du leider nicht erwähnt.

Wenn also irgendein Client mit einer Zieladresse im Segment 2 ankommt, sollte ihm da vom Gateway geholfen werden. Das wurde doch von verschiedener Seite hier so dargestellt.

Richtig.

Und ja, wenn lesen allein so erfolgreich wäre und alles wie im Lehrbuch, wundert es mich, dass es all diese Foren gibt.

Es gibt halt wie überall Leute die sich dahinter knien und es auf eigene Faust lernen und lösen, und die die es sich leicht machen und Foren für sich arbeiten lassen

Aber lassen wir das bringt eh nichts.

Da wird einfach dein GW oder deine Androiden fehlerhaft konfiguriert sein.
Setzt du also mal schnell eine PFSense auf und du siehst was Sache ist. Wir können hier leider mit den dürftigen Infos nicht viel erreichen, wer weiß was du wo konfiguriert hast

Ohne vernünftige Zeichnung zum Netzaufbau etc.

So zum Abschluss noch eine Zusammenfassung

Situation
3 Wege firewall (shorewall) mit 3 Zonen
loc
dmz
net
Auf der Firewall ist ein isc-dhcp Server installiert.
In der loc zone steht ein Router, der in eine weitere DMZ2.
Diesem wurde per static route option mitgeteilt, wie das Routing in DMZ2 läuft.

Android Geräte finden aber den Weg in DMZ2 nicht.
Windows Geräte finden allerdings den Weg in die DMZ.
Sobald die static route option im DHCP gelöscht wird, finden auch die Windows Systeme nicht mehr in die DMZ2
Das sieht so aus, also ob Windows es gerne anders hat. Die Lösung gilt am Ende aber pauschal. Auch Windows braucht diese Angaben einer statischen Route nicht.

Hier gelernt:
Routen werden nicht per DHCP verteilt.
Android Devices (mindestens) interessiert das nicht, was da per DHCP propagiert wird.
Statische Routen werden auf dem Gateway definiert
Das Gateway sagt dann ankommenden Paketen, wo es lang geht
Also habe ich eine statische Route auf dem Router definiert (nicht per DHCP)

Das hat jedoch keine Abhilfe geschaffen. Pakte für DMZ2 liefen nachwievor ins Leere

Lösung:
Anhand von Logfiles wurde klar, dass es sich um ein Firewall Problem handelt
In der Firewallkonfiguration der Interfaces, fehlte für die loc zone eine net Angabe für DMZ2
Nach Ergänzung dieser Angabe lief alles wie gewünscht.

Danke an @em-pie für die sachliche Hilfe.
Danke an @132692 für den sachlichen Teil der Hilfe.

Demnach müsste man eigentlich den Titel des Threads ändern.
(Habe den Titel soweit erlauabt angepasst, da die Fehler in der Firewall und Gateway Konfiguration lagen und letztlich Android nicht das Problem war, sondern nur der Anlass)

@132692
Ich habe in diesem Beitrag geschrieben, dass ich die Route am Start habe und einen Command Log dazu geliefert.
ip route add ...
[quote]aber lassen wir das[/quote]
Sehr gut, der Meinung bin ich auch. Ich habe nie nach dieser Art Belehrungen gefragt.
Nur mal so eine Grundüberlegung für die Situation "Ich habe ein Problem und weiß nicht weiter". Wie soll der nicht wissende Hintergrundinformationen liefern, wenn er die Problematik nicht durchschaut? Der Wissende sollte erfragen, was an Informationen fehlt, statt zu meckern, dass Informationen fehlen.

Grundlegend muss man aber auch sagen das der Weg statische Routen an Endgeräte zu propagieren immer der Falsche ist und nur eine Notlösung sein sollte.
Endgeräte sollen niemals selber routen sondern das sollte immer die Netzwerk Infrastruktur machen und nur diese.
Abgesehen von dem o.a. Firewall Problem wäre dann eine einfache statische Route an der .246er Firewall ala:
Zielnetz: <dmz_netzwerk>, Maske: <dmz_netzmaske>, Gateway: 192.168.1.254
IP technisch immer der bessere Weg und auch die einfachere Lösung gewesen.

Natürlich sollte man dann noch lokal ICMP Redirects (Typ 5) an der Firewall erlauben für das lokale LAN und diesen lokalen Traffic vom Firewalling ausnehmen.
Die FW schickt dann ein ICMP Redirect an die Endgeräte Clients die dann den .245er Router direkt kontaktieren ohne überflüssigen Umweg über die .246.
Das wäre netztechnisch der bessere Weg.
Aber egal...Hauptsache es rennt jetzt.

@aqui
Ich hab mich offenbar erneut missverständlich ausgedrückt.
Die von Dir genannte Route ist so eingetragen, das habe ich ziemlich zu des Threads geschrieben. Das ist Teil der Lösung. Gleiches gilt für das genannte Routing Prinzip. Anhand der Beschreibungen der Konfiguration des DHCP Servers war ich davon ausgegangen, dass die static routes option "state of the art" sind. Diesen Irrtum habe ich sofort korrigiert. "Dank" der fehlerhaften Firewall Konfiguration hat sich die Verbesserung leider nicht bemerkbar gemacht.
Was fehlte war eine zusätzliche "net" Angabe in der interfaces Datei von Shorewall.
Damit war dann auch die static route option für Windows Clients im DHCP obsolet.
ICMP Handling war von Anfang an berücksichtigt in der Firewall Konfiguration.