Top-Themen

Aktuelle Themen (A bis Z)

Administrator.de FeedbackApache ServerAppleAssemblerAudioAusbildungAuslandBackupBasicBatch & ShellBenchmarksBibliotheken & ToolkitsBlogsCloud-DiensteClusterCMSCPU, RAM, MainboardsCSSC und C++DatenbankenDatenschutzDebianDigitiales FernsehenDNSDrucker und ScannerDSL, VDSLE-BooksE-BusinessE-MailEntwicklungErkennung und -AbwehrExchange ServerFestplatten, SSD, RaidFirewallFlatratesGoogle AndroidGrafikGrafikkarten & MonitoreGroupwareHardwareHosting & HousingHTMLHumor (lol)Hyper-VIconsIDE & EditorenInformationsdiensteInstallationInstant MessagingInternetInternet DomäneniOSISDN & AnaloganschlüsseiTunesJavaJavaScriptKiXtartKVMLAN, WAN, WirelessLinuxLinux DesktopLinux NetzwerkLinux ToolsLinux UserverwaltungLizenzierungMac OS XMicrosoftMicrosoft OfficeMikroTik RouterOSMonitoringMultimediaMultimedia & ZubehörNetzwerkeNetzwerkgrundlagenNetzwerkmanagementNetzwerkprotokolleNotebook & ZubehörNovell NetwareOff TopicOpenOffice, LibreOfficeOutlook & MailPapierkorbPascal und DelphiPeripheriegerätePerlPHPPythonRechtliche FragenRedHat, CentOS, FedoraRouter & RoutingSambaSAN, NAS, DASSchriftartenSchulung & TrainingSEOServerServer-HardwareSicherheitSicherheits-ToolsSicherheitsgrundlagenSolarisSonstige SystemeSoziale NetzwerkeSpeicherkartenStudentenjobs & PraktikumSuche ProjektpartnerSuseSwitche und HubsTipps & TricksTK-Netze & GeräteUbuntuUMTS, EDGE & GPRSUtilitiesVB for ApplicationsVerschlüsselung & ZertifikateVideo & StreamingViren und TrojanerVirtualisierungVisual StudioVmwareVoice over IPWebbrowserWebentwicklungWeiterbildungWindows 7Windows 8Windows 10Windows InstallationWindows MobileWindows NetzwerkWindows ServerWindows SystemdateienWindows ToolsWindows UpdateWindows UserverwaltungWindows VistaWindows XPXenserverXMLZusammenarbeit

gelöst Routingproblem in Homerouter-Kaskade mit Raspi

Mitglied: Oldschool

Oldschool (Level 1) - Jetzt verbinden

24.03.2017 um 21:41 Uhr, 3648 Aufrufe, 25 Kommentare

Hallo liebe Netzwerkspezialisten,

Ich habe in unserem Netzwerk einen Standardfall der gefühlt mehrere Tausend Mal in diesem Forum geschildert worden ist. Und obwohl ich diese Beiträge und auch die HowTos mehrmals rauf und runter gelesen habe, finde ich den Fehler bei uns im Netzwerk einfach nicht.

Hier kurz eine vereinfachte Darstellung meiner Problemstelle im Netzwerk:


netzwerk - einfach - Klicke auf das Bild, um es zu vergrößern


Es sind also zwei private Netze (ich nenne sie einfach mal anhand der IP-Adressierung 44er und 55er Netz). Das 44er Netz hat eine Verbindung zum Internet. Ein Raspi 3B verbindet die beiden privaten Class C Netze.
Das 55er Netz soll nun auch Zugriff zum Internet bekommen und auch auf die Ressourcen im 44er Netz zugreifen können (Drucker, Intranet). Auf dem Webserver mit dem Intranet läuft noch ein dnsmasq, der Anfragen an die http-Adresse des Intranets zur lokalen IP 192.168.44.253 umleitet. Alle anderen Anfragen gehen an 8.8.8.8.

Weiterhin habe ich auf dem Raspi noch folgendes konfiguriert, um die Netzwerke miteinander zu verbinden:

• IP-Forwarding aktiviert (net.ipv4.ip_forward=1)
• Statische Route auf dem Raspi (Zielnetz: 192.168.44.0, Gateway 192.168.55.1)


Nun habe ich folgende Situation:

Es funktioniert:

• Ein Ping vom 55er Netz auf die IP 192.168.44.254 (eth0 vom Raspi)
• Ein Ping vom 55er Netz auf die IP 192.168.44.1 (Internet Gateway)
• Ein Ping vom 55er Netz auf die IP 8.8.8.8


Es funktioniert nicht:

• Ein Ping vom 55er Netz auf 192.168.44.252 (Drucker) = “Zeitüberschreitung der Anforderung“
• Ein Ping vom 55er Netz auf 192.168.44.253 (Intranet Webserver) = “Zeitüberschreitung der Anforderung“
• Ein Ping auf http-Adressen des Internets




Ich habe auch schon getestet, NAT auf dem Raspi zu aktivieren (iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE)

Es machte für mich zwar keinen Sinn, weil NAT für mein Verständnis schon vom Internet-Gateway im 44er Netz erledigt wird, aber in der Verzweiflung klammert man sich ja an jeden Strohhalm. Es brachte dann auch wie erwartet keine Abhilfe.

Sobald ich im 55er Netz den DNS ändere von 192.168.44.253 auf 8.8.8.8, dann geht zumindest der Zugriff auf http-Adressen (logisch). Dann fehlt mir aber der Zugriff auf die Geräte im 44er Netz.


Kann mir hier bitte jemand helfen, meinen Fehler zu finden? Ich bin ratlos…

Schöne Grüsse,
Oldschool
Mitglied: Lochkartenstanzer
25.03.2017 um 07:38 Uhr
Moin,

Zitat von Oldschool:

• Statische Route auf dem Raspi (Zielnetz: 192.168.44.0, Gateway 192.168.55.1)

Das ist Blödsinn. Der Raspi braucht hängt doch direkt an beiden netzen dran. Diese Route schickt verhindert, daß er die Pakete auf das richtige Interface schickt.

Es funktioniert:

• Ein Ping vom 55er Netz auf die IP 192.168.44.254 (eth0 vom Raspi)
• Ein Ping vom 55er Netz auf die IP 192.168.44.1 (Internet Gateway)
• Ein Ping vom 55er Netz auf die IP 8.8.8.8


Es funktioniert nicht:

• Ein Ping vom 55er Netz auf 192.168.44.252 (Drucker) = “Zeitüberschreitung der Anforderung“
• Ein Ping vom 55er Netz auf 192.168.44.253 (Intranet Webserver) = “Zeitüberschreitung der Anforderung“
• Ein Ping auf http-Adressen des Internets


Und was sagen die traceroutes?
hast Du mal auf dem raspi mal mit tcpdump oder wireshark geschaut, wie die Pakete laufen?


Ich habe auch schon getestet, NAT auf dem Raspi zu aktivieren (iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE)

Es machte für mich zwar keinen Sinn, weil NAT für mein Verständnis schon vom Internet-Gateway im 44er Netz erledigt wird, aber in der Verzweiflung klammert man sich ja an jeden Strohhalm. Es brachte dann auch wie erwartet keine Abhilfe.

Wenn Du aus dem 44er netz ins 55 zugreifen willst, ist NAT kontraproduktiv.

Sobald ich im 55er Netz den DNS ändere von 192.168.44.253 auf 8.8.8.8, dann geht zumindest der Zugriff auf http-Adressen (logisch). Dann fehlt mir aber der Zugriff auf die Geräte im 44er Netz.

Da ist dann häöchstens die namensauflösung weg. Aber per IP solltest Du schon drauf kommen.

Kann mir hier bitte jemand helfen, meinen Fehler zu finden? Ich bin ratlos…

Als erstes solltest Du mal die Routingtabelle und die interface-konfiguration auf dem RasPi posten:

  • netstat -rn
  • ifconfig -a
  • cat /etc/resolv.conf

Und die oben erwähnte statische Route solltest Du löschen.

Vorallem mal mit tcpdump/wireshark schauen, wie die Pakete auf dem rasPi laufen.

lks

PS: Was ist das Ziel der obigen Aktion? Könnte man nciht einfach alle Geräte in das gkleiche Netz hängen oder soll der Raspberry was besonderes machen außer dem Routen?
Bitte warten ..
Mitglied: aqui
LÖSUNG 25.03.2017, aktualisiert um 12:18 Uhr
einen Standardfall der gefühlt mehrere Tausend Mal in diesem Forum geschildert worden ist.
Weise und wahre Worte....
Du hast die Tutorials dennoch nicht genau gelesen, denn es sind wieder einige schlimme Anfänger Fehler enthalten die zu diesem Fehlverhalten bzw. der Nichtfunktion führen:
Statische Route auf dem RasPi (Zielnetz: 192.168.44.0, Gateway 192.168.55.1)
Diese Route ist wie immer Schwachsinn. Sorry für die harten Worte aber der RasPi "kennt" doch sowohl das .44er als auch das .55er Netz da sie beide DIREKT an ihm angeschlossen sind !
Wozu also noch diese Netzwerke dem RasPi mit einer Route bekannt machen? Das ist Blödsinn und wird immer und immer wieder in den Routing Tutorials hier gepredigt:
https://www.administrator.de/wissen/routing-2-netzwerkkarten-windows-u-l ...
Lösche also diese vollkommen unsinnige Route wieder !
Das Einzige was der RasPi benötigt ist eine Default Route bzw. Default Gateway auf die 192.168.44.1 (Internet Router). Mehr nicht!
Grundlegende Infos zum PasPi Networking auch hier:
https://www.administrator.de/wissen/netzwerk-management-server-raspberry ...

Der Internet Router braucht aber natürlich zwingend eine statische Route ! Genau DIE hast du leider vergessen !
Klar, denn der Internet Router "kennt" das .55er Netz hinter dem RasPi nicht, woher auch? Das musst du ihm also mit einer statischen Route beibringen. Also kommt hier dann rein:
Zielnetz: 192.168.55.0, Maske: 255.255.255.0, Gateway: 192.168.44.254

Fertisch !
Das wars schon !

Fazit:
2 Kardinalsfehler !
  • Routing auf dem RasPi vollkommen falsch eingestellt !
  • Statische Route auf dem Internet Router vergessen !
Fazit vom Fazit:
Du hast wie hier leider so oft das o.a. Routing_Tutorial de facto NICHT gelesen. Erwischt !!!

Änder diese beiden Punkte, dann kommt das auch alles sofort problemlos zum Fliegen. Ansonsten ist dein Design absolut richtig. Und....
das nächste Mal wirklich die Tutorials lesen !
Bitte warten ..
Mitglied: Oldschool
25.03.2017 um 12:34 Uhr
Hallo Lochkartenstanzer!

Auf dem Raspberry Pi 3B soll zukünftig noch squid & squidguard laufen. Ich habe zwar noch zwei TP-Link-Router in der Schublade, die ich mit DD-WRT oder OpenWRT bespielen könnte, habe mich aber aus Performancegründen für die Anschaffung eines Raspberry Pi 3B entschieden. Zudem bin ich zukünftig flexibler und kann auf dem raspi noch weitere Dienste installieren. Beispielsweise könnte der Webserver für das Intranet auch noch auf dem raspi laufen und ich hätte damit ein Gerät gespart.

Zur Problemanalyse:

Die statische Route auf dem Raspi habe ich nun gelöscht

Auf dem Windows-Client im 55er Netz ergibt tracert nun:





Der Raspi ist folgendermassen konfiguriert:






Also der raspi selbst hat Zugriff auf meinen internen DNS. Logisch, denn er ist ja mit eth0 im selben Netz. Aber die Clients im 55er Netz sehen den internen DNS einfach nicht. Sie können IP-Adressen im Internet anpingen, aber die Namensauflösung erfolgt eben nicht. Der raspi scheint nicht zu routen. Ich verstehe nicht, woran es liegt.

Grüsse,
Oldschool
Bitte warten ..
Mitglied: Oldschool
25.03.2017 um 12:40 Uhr
Hallo aqui,

das Tutorial bezüglich routing mit 2 Netzwerkkarten habe ich schon gelesen. Das hat mich auch dazu gebracht, die statische Route auf dem Internet-Gateway anzulegen, wie von Dir empfohlen. Es ist auf meiner obigen Zeichnung dokumentiert; vielleicht hast du es übersehen.

Nur das mit der statischen Route auf dem Raspi ist tatsächlich ein dummer Fehler von mir. Vielleicht habe ich trotzdem nicht alles im Tutorial verstanden *rotwerd*

Das Tutorial zum grundlegenden Raspi-Networking ziehe ich mir jetzt noch rein und hoffe auf neue Erkenntnisse. Man kann ja nur dazulernen...

Die unsinnige Route auf dem raspi ist ja nun gelöscht...

Grüsse,
Oldschool
Bitte warten ..
Mitglied: Lochkartenstanzer
25.03.2017 um 13:00 Uhr
Zitat von Oldschool:

Auf dem Raspberry Pi 3B soll zukünftig noch squid & squidguard laufen.

o.k. Das erklärt den Aufbau, auch wenn das natürlich auch mit einem Pi im gleichen Netz ohne die kaskade funktionieren würde.

Die statische Route auf dem Raspi habe ich nun gelöscht

brav.

Auf dem Windows-Client im 55er Netz ergibt tracert nun:


Kann der Pi denn 192.168.44.253 anpingen? Hat 192.168.44.253 denn eine default route zum Internet gateway oder eine statische zum Pi?

Sieht mir ganz nach einem routing-Problem aus. Mach mal einen tcpdump auf dem Pi während due pingst.


Wenn das routing ncht funktioniert, funktioniert natürlich auch dns nicht, weil die Antwortpakete nciht zurückkommen.

Der Raspi ist folgendermassen konfiguriert:


sieht gut aus.




sieht auch gut aus.


auch o.k.


Also der raspi selbst hat Zugriff auf meinen internen DNS. Logisch, denn er ist ja mit eth0 im selben Netz. Aber die Clients im 55er Netz sehen den internen DNS einfach nicht. Sie können IP-Adressen im Internet anpingen, aber die Namensauflösung erfolgt eben nicht. Der raspi scheint nicht zu routen. Ich verstehe nicht, woran es liegt.

Due solltest als erstes mal mit tcpdump prüfen, ob der rasPi wirklich der schuldige ist. Ich vermute imemr nochn eine falsche Route beim gateway oder deinem internen DNS.

lks
Bitte warten ..
Mitglied: aqui
LÖSUNG 25.03.2017, aktualisiert um 13:25 Uhr
Auf dem Windows-Client im 55er Netz ergibt tracert nun:
Ist das ein Winblows Server den du da antraceroutest ??
Bedenke das der eine lokale Firewall hat die gnadenlos alles was Absender IPs hat aus fremden Netzen blockt !
Außerdem ist bei allen Windows Versionen ab Win7 und höher ICMP geblockt ! Ping und Traceroute nutzen ICMP !
Hast du das beachtet ??
https://www.windowspro.de/tipp/ping-windows-7-server-2008-r2-zulassen
https://technet.microsoft.com/de-de/library/cc771915(v=ws.11).aspx
Das gilt natürlich auch für den 55er Client wenn man den aus dem 44er Netz erreichen will und das Winblows ist.
Sinnvollerweise traceroutet man zum Test immer ein Endgerät was kein Windows oder eine Firewall hat wie z.B den Drucker mit der 44..252 oder RasPi mit 44.254 oder den Router mit 44.1 um so der Falle lokale Firewall zu entgehen !!
tracert www.google.de
Ist natürlich Blödsinn wenn schon das Tracerouten im anderen lokalen Netzwerk fehlschlägt
Außerdem um erstmal DNS Problemen aus dem Wege zu gehen solltest du die nackte IP bei Google tracerouten mit traceroute 8.8.8.8 (tracert bei Winblows)

RasPi Konfig sieht gut aus ! Ein ip route show wär nochmal interessant. Und wichtig...
was ergibt ein ping 192.168.44.1 -c 5 -I 192.168.55.1 ??
Das pingt den Router vom RasPi mit dessen Absender IP aus dem 55er Netz und zeigt dann ob die statische Route am Internet Router greift.

Kannst du vom Client aus dem dem .55er Netz die beiden RasPi interfaces anpingen ?? Auch das muss fehlerlos klappen und zeigt sofort ob auf dem RasPi wirklich das IPv4 Forwarding aktiviert wurde !
Aber die Clients im 55er Netz sehen den internen DNS einfach nicht.
Hast du denen das denn statisch konfiguriert ?? Der Client müsste wenn statisch die folgenden IPs haben:
IP Adresse: 192.168.55.111
Maske: 255.255.255.0
Gateway: 192.168.55.1
DNS: 192.168.44.253

Also so wie im Bild ist das richtig. Der DNS Server, wenn Winblows, muss natürlich in seiner lokalen Firewall eingehende DNS Requests aus dem 192.168.55er Netz zulassen. Das musst du, sofern Winblows, in der lokalen Firewall customizen !

WAS ist mit der erforderlichen statischen Route ins 55er Netz auf dem Internet Router ???
Dazu wieder keinerlei Auskunft von dir ??
Es ist auf meiner obigen Zeichnung dokumentiert; vielleicht hast du es übersehen.
OK dann glauben wir dir das mal
Kannst du vom 55er Client dann die Router LAN IP .44.1 oder die RasPi IP .44.254 anpingen ???
Sieht so aus als ob routingtechnsich alles dann OK ist bei dir und du lediglich ein Firewall Problem hast.
Nimm zum Ping Test immer Geräte die keine lokale Firewall haben also Drucker IP oder Router LAN IP oder die beiden RasPi Interfaces !
Bitte warten ..
Mitglied: Lochkartenstanzer
25.03.2017 um 14:03 Uhr
Zitat von aqui:

Das gilt natürlich auch für den 55er Client wenn man den aus dem 44er Netz erreichen will und das Winblows ist.
Sinnvollerweise traceroutet man zum Test immer ein Endgerät was kein Windows oder eine Firewall hat wie z.B den Drucker mit der 44..252 oder RasPi mit 44.254 oder den Router mit 44.1 um so der Falle lokale Firewall zu entgehen !!
...
Sieht so aus als ob routingtechnsich alles dann OK ist bei dir und du lediglich ein Firewall Problem hast.
Nimm zum Ping Test immer Geräte die keine lokale Firewall haben also Drucker IP oder Router LAN IP oder die beiden RasPi Interfaces !

Naja,. wenn er endlich mal auf dem 44-er Interface mitsniffen würde, wie ich ihn schon ein paar Male aufgefordert habe, würde man sofort sehen, ob der pi oder die Windows-Kisten das Problem sind.

lks
Bitte warten ..
Mitglied: aqui
25.03.2017, aktualisiert um 14:56 Uhr
Da hast du Recht. Der Output von...
tcpdump -i eth0 icmp
wäre mal recht interessant wenn der Client im .55er Netz Pingtests ins .44er Netz macht.
(Vorher natürlich sudo apt-get install tcpdump nicht zu vergessen )
Man fragt sich aber wirklich was der TO da macht. Ein Testaufbau hier mit einem ollen RasPi 2 und aktuellstem Jessie kam in 10 Minuten mit dem Design zum Fliegen.
Was da wohl wieder verschlimmbessert wurde..?? Ich vermute aber eher Firewall statt Routing Infrastruktur.
Wir nehmen noch Wetten an...
Bitte warten ..
Mitglied: 108012
25.03.2017 um 15:02 Uhr
Wir nehmen noch Wetten an... 
Na dann, der DNS Server ist falsch konfiguriert.

Gruß
Dobby
Bitte warten ..
Mitglied: Lochkartenstanzer
25.03.2017 um 15:15 Uhr
Zitat von 108012:

Wir nehmen noch Wetten an... 
Na dann, der DNS Server ist falsch konfiguriert.

Nachdem pings auf 8.8.8.8 funktionieren, nehme ich mal an, daß das Routing im Groben o.k ist.

Wenn der 192.168.55.253 nicht angepingt werden kann, so kann das nur daran liegen, daß entweder die Firewall das schon blockt oder die Kiste weder default route noch statische routen hat.

Da aber das ding DNS für das 55er-netz macht, gehe ich mal davon aus, daß die default-route korretk ist, sonst könnten 55er geräte nicht Internet-namen auflösen. Bleibt also nur die Firewall

Und das DNS im 44er-netz ist nur ein Folgefehler der Nichterreichbarkeit von 192.168.55.253

Ich tippe also, wie aqui auch, inwischen auf einen firewall-Fehler.

lks
Bitte warten ..
Mitglied: aqui
25.03.2017, aktualisiert um 15:21 Uhr
Das sollte er ja schnellstens verifizieren können wenn er nackte IPs pingt wie 8.8.8.8 (Google) oder 82.149.225.21 (www.administrator.de) oder 193.99.144.8 (www.heise.de) usw. Tcpdump idealerweise an...
Aber Wette ist vermerkt...
Nachdem pings auf 8.8.8.8 funktionieren
WO steht das ? Hat der TO ja noch nicht gesagt das das klappt, oder ? Wäre aber ein Durchbruch der den Verdacht dann auf Fehlkonfiguration des .253er DNS Servers erhärtet.
Die Spannung steigt....
Bitte warten ..
Mitglied: Lochkartenstanzer
25.03.2017, aktualisiert um 15:24 Uhr
Zitat von aqui:
Nachdem pings auf 8.8.8.8 funktionieren
WO steht das ?


Der TO sagte direkt in der frage.

Nun habe ich folgende Situation:

Es funktioniert:

• Ein Ping vom 55er Netz auf die IP 192.168.44.254 (eth0 vom Raspi)
• Ein Ping vom 55er Netz auf die IP 192.168.44.1 (Internet Gateway)
Ein Ping vom 55er Netz auf die IP 8.8.8.8


Es funktioniert nicht:

• Ein Ping vom 55er Netz auf 192.168.44.252 (Drucker) = “Zeitüberschreitung der Anforderung“
• Ein Ping vom 55er Netz auf 192.168.44.253 (Intranet Webserver) = “Zeitüberschreitung der Anforderung“
• Ein Ping auf http-Adressen des Internets


Hervorhebung von mir.

lks
Bitte warten ..
Mitglied: aqui
25.03.2017, aktualisiert um 18:33 Uhr
Sorry, überlesen im Eifer des Gefechts....
Das sieht dann aber gut aus und man kann davon ausgehen das das IP Routing dann grundsätzlich funktioniert und die Restfehler Winblows Firewall und DNS Server sind.
Mögliche Fehler des Rests:
• Ein Ping vom 55er Netz auf 192.168.44.252 (Drucker) = “Zeitüberschreitung der Anforderung“
Hier fehlt wie immer garantiert das Default Gateway 192.168.44.1 im Drucker !
• Ein Ping vom 55er Netz auf 192.168.44.253 (Intranet Webserver) = “Zeitüberschreitung der Anforderung“
Vermutlich auch fehlender Default Gateway .44.1 Eintrag des Servers. Oder...wenn das Winblows ist wieder die lokale Firewall HTTP Zugriff geblockt aus Fremdnetzen und ICMP Block.
• Ein Ping auf http-Adressen des Internets
Da muss man auch vorsichtig sein. Sehr viele Adressen haben ICMP geblockt um Ping Attacken zu unterdrücken.
Ganz sicher pingen lassen sich aber z.B. www.heise.de, www.spiegel.de und natürlich www.administrator.de.
Wenn die generell nicht pingbar sind, dann hat der DNS wie immer keine DNS Weiterleitung auf den Proxy DNS des Internet Routers .44.1 eingetragen.
Es bleibt also weiter spannend....
Bitte warten ..
Mitglied: Oldschool
25.03.2017 um 18:31 Uhr
Im WebGUI des Internet-Gateways sehe ich folgendes:



Der raspi kann quasi alles; außer Kaffee kochen. Will heißen, er pingt und tracert fleissig alle Geräte im 44er und 55er Netz sowie im Internet.

Ich habe auch schon versucht, andere Geräte im 44er Netz anzupingen (vom 55er Netz aus); aber ohne Erfolg.

Mein Test-Client im 55er Netz hat Windows 10, dies nur als Randinformation.

Der DNS-Server ist eine Linux-VM auf einem Windows 10 PC und tut zumindest im 44er Netz das was er soll. Die Geräte im 44er Netz haben nur diesen DNS eingetragen (über DHCP vom Internetgateway).

Im 55er Netz befindet sich noch ein WLAN-Access-Point mit DHCP-Server. Von dort beziehen alle Clients im 55er Netz auch Ihre DNS Einstellungen (192.168.44.253 als DNS) und Gateway Einstellungen (192.168.55.1).


Nun nochmal die Pings in ausführlicher Form auf dem 55er Client (192.168.55.11):


Der heiss ersehnte tcpdump dazu:


Ok. Jetzt wäre es vermutlich an der Zeit, sich die Konfiguration des DNS mal genauer anzuschauen, richtig?
Bitte warten ..
Mitglied: em-pie
25.03.2017 um 18:49 Uhr
Moin
Zitat von Oldschool:
Im WebGUI des Internet-Gateways sehe ich folgendes:
Sieht gut aus, damit sollten die Pakete des 44er Netzes grundsätzlich auch den Weg zurück ins 55er finden


Der raspi kann quasi alles; außer Kaffee kochen. Will heißen, er pingt und tracert fleissig alle Geräte im 44er und 55er Netz sowie im Internet.
Dass der alles anpingen/ auflösen kann, liegt daran, dass er mit einem bein im 55er Netz steht und über dieses auch alle Devices dort anspricht und mit dem anderen Bein im 44er Netz und darüber alle Geräte im dortigen Netz kontaktiert.

Ich habe auch schon versucht, andere Geräte im 44er Netz anzupingen (vom 55er Netz aus); aber ohne Erfolg.
Was sind diese anderen Geräte? alles Windows-Kisten?

Mein Test-Client im 55er Netz hat Windows 10, dies nur als Randinformation.

Der DNS-Server ist eine Linux-VM auf einem Windows 10 PC und tut zumindest im 44er Netz das was er soll. Die Geräte im 44er Netz haben nur diesen DNS eingetragen (über DHCP vom Internetgateway).

Im 55er Netz befindet sich noch ein WLAN-Access-Point mit DHCP-Server. Von dort beziehen alle Clients im 55er Netz auch Ihre DNS Einstellungen (192.168.44.253 als DNS) und Gateway Einstellungen (192.168.55.1).


Nun nochmal die Pings in ausführlicher Form auf dem 55er Client (192.168.55.11):


Entweder ein Firewall-Problem oder ein fehlendes/ falsches Gateway dort eingetragen.
Wie sieht das Ergebnis aus, wenn du auf deiner DNS-VM mal ein
eingibst?

Ok. Jetzt wäre es vermutlich an der Zeit, sich die Konfiguration des DNS mal genauer anzuschauen, richtig?

Korrekt!

Gruß
em-pie
Bitte warten ..
Mitglied: aqui
25.03.2017, aktualisiert um 19:07 Uhr
Im WebGUI des Internet-Gateways sehe ich folgendes:
Das ist richtig und korrekt. Siehst du auch daran das der Ping ins Internet zu 8.8.8.8 klappt, sonst wäre das unmöglich.
Der raspi kann quasi alles; außer Kaffee kochen.
Das stimmt !! Und gut, zeigt das das IP Routing da sauber funktioniert.
Kollege em-pie hat aber Recht.
Du solltest beim Ping vom RasPi mit -I <ip_adresse> immer mal die Quell IP Adresse an geben. Es macht also Sinn wenn du vom RasPi mal ins 44er Netz pingst das mit seiner 55er Absender IP zu machen. Also sowas wie:
ping -c 5 -I 192.168.55.1 www.heise.de

auch geht
ping -c 5 -I eth1 www.heise.de
ping -c 5 -I 192.168.55.1 8.8.8.8
ping -c 5 -I eth1 193.99.144.8

Auch hier gilt: Um DNS Probleme deines vermurksten Servers sicher auszuschliessen einfach testweise mal den Internet Router 44.1 als DNS Server auf dem RasPi konfigurieren.
Ich habe auch schon versucht, andere Geräte im 44er Netz anzupingen (vom 55er Netz aus); aber ohne Erfolg.
Komisch ? Du hast doch oben gerade geschrieben das du den Internet Router mit der 44.1 aus dem 66er Netz anpingen kannst, oder ??
Der Drucker muss auch anpingbar sein. Der hat keine lokale Firewall. Allerdings MUSS er zwingend den Internet Router als Default Gateway konfiguriert haben, ansonsten findet er die Rückroute ins 55er Netz nicht...logisch !
Hast du das im Drucker Setup geprüft ?? Drucker und Server sollten IMMER eine statische IP Adresse haben und klar das diese NICHT im DHCP Pool liegen dürfen. Also querchecken mit dem 44er DHCP Server im Router.
Das gilt ebenso für ALLE anderen Geräte im 44er Netz was das Gateway anbetrifft.
Bei allen Windows Kisten da wie gesagt lokale Firewall immer beachten !
Mein Test-Client im 55er Netz hat Windows 10, dies nur als Randinformation.
Sollte erstmal kein Hinderungsgrund sein.
Der DNS-Server ist eine Linux-VM auf einem Windows 10 PC
Hier ist es essentiell wichtig in welchem Modus die virtuellen NICs des Hypervisor Hosts eingestellt sind !
Die müssen alle im Bridging Mode sein !
Das bedeutet das alles VMs auch IP Adressen im .44.0 /24er IP Netz haben müssen.
Keinesfalls dürfen diese Interfaces im Host oder NAT Mode sein !
Im 55er Netz befindet sich noch ein WLAN-Access-Point mit DHCP-Server.
Wäre netztechnsich besser das auf dem RasPi zu machen aber ertsmal ist das egal, denn es geht natürlich auch so.
Was hier wichtig ist das die statischen IP Adressen des RasPi NICHT im DHCP Pool sind !
Ein ipconfig -all Check (Winblows) im 55er Netz sollte dann die richtigen IP Adressen anzeigen.
Achte darauf das ein Client im 55er LAN Segment nicht auch gleichzeitig im WLAN mit einer 55er IP ist. Hier darf nur entweder WLAN oder LAN aktiv sein !!
Und....
Hast du mal den Test gemacht und diesen Accesspoint und seine 55er IP mal von Geräten und VMs aus dem 44er Netz anzupingen ?? Klappt das ??

Um ggf. DNS Problemen im 55er Netz mal aus dem Wege zu gehen setze dort bei den Endgeräten doch testweise einfach mal den Internet Router .44.1 als DNS ein und teste mal ob du dann z.B. www.heise.de pingen kannst.
Das würde dann tatsächlich einen Fehler im DNS Server verifizieren sollte das klappen.
IP 192.168.55.11 > intranet.domain.net:
Ooops... intranet.domain.net (.net) ??? Das kann doch niemals sein !!!
Der DNS Server macht ein reverse Lookup auf eine öffentliche Root Domain ?? Da stimmt wirklich was nicht mit dem DNS. Aber das ist erstmal egal...kommt später bzw. hat mit dem IP Routing im Netz nichts zu tun.
Es bleibt mal wieder die Frage warum du den Drucker nicht pingst ?? Vorausgesetzt der hat eine gültige Default Gateway Adresse 44.1 MUSS das klappen aus dem 55er Netz.
Am Drucker besteht wenigstens nicht die Gefahr falscher virtueller NIC Modi oder lokaler Firewalls die nicht angepasst sind.
Jetzt wäre es vermutlich an der Zeit, sich die Konfiguration des DNS mal genauer anzuschauen, richtig?
Bingo !!!
Bitte warten ..
Mitglied: 108012
25.03.2017 um 19:05 Uhr
Was hat denn Dein interner DNS Server (im LAN) für eine IP Adresse zu einem externen DNS Server?
- Die IP des Speedport Routers (funktioniert)
- Googles DNS IP Adressen (funktioniert)
- Die DNS IPs Deines ISP (funktioniert)
- Seine eigene IP (funktioniert nicht)
- Gar keine IP (funktioniert nicht)
- Loopback (127.0.0.0) (funktioniert nicht)

Gruß
Dobby
Bitte warten ..
Mitglied: aqui
25.03.2017, aktualisiert um 19:10 Uhr
Die IP des Speedport Routers (funktioniert)
Das kann man ganz sicher ausschliessen Dobby, denn ein Speedport supportet KEINE statischen Routen
Da er die aber konfiguriert hat, hat er im Umkehrschluss glücklicherweise keinen Speedport.
Bitte warten ..
Mitglied: Oldschool
25.03.2017 um 20:26 Uhr
Hallo zusammen,

hier noch mal kurz zusammengefasst die weiteren Infos:

Andere Geräte im 44er Netz sind neben weiteren Windows 10 Büchsen auch noch ein AppleTV, ein weiterer WLAN-Acess-Point (nicht zu verwechseln mit einem WLAN-Repeater), ein weiterer Raspi B3 mit openElec als Mediastreamer, und etliche Smartphones, eBooks, etc.

Der DNS- und Webserver läuft auf Oracle Virtualbox mit NIC als Netzwerkbrücke und dementsprechend mit eigener IP.

Die DHCP-Server im 44er sowie im 55er Netz sind mit einer DHCP-Range von 192.168.x.10 bis 192.168.x.100 ausgestattet und sollten somit nicht mit den statisch vergebenen IPs kollidieren.

In meinem ersten Beitrag schrieb ich ja bereits, dass der Internetzugriff vom 55er Netz tadellos funktioniert, wenn ich beispielsweise 8.8.8.8 als DNS eintrage. Wenn ich nun 192.168.44.1 (Internet-Gateway) als DNS eintrage funktioniert das auflösen von Internet-Adressen ebenso.

Ein Ping aus dem 44er Netz auf meinen Test-Client im 55er Netz resultiert in „Zeitüberschreitung der Anforderung.“

Zu intranet.domain.net : Dort stand vorher die originale Adresse unseres Intranets. Habe ich dann entsprechend anonymisiert.

Ich brauch jetzt ma 'ne Pause und widme mich morgen noch mal der Analyse bezüglich der Default Gateways. Gerade sehe ich nur noch Zahlen und Buchstaben auf meiner Netzhaut.

Schöne Grüsse,
Oldschool
Bitte warten ..
Mitglied: aqui
26.03.2017, aktualisiert um 12:19 Uhr
Ein Ping aus dem 44er Netz auf meinen Test-Client im 55er Netz resultiert in „Zeitüberschreitung der Anforderung.“
Klar und zu erwarten, denn das ist wieder die alte Leier das die lokale Windows Firewall alles mit fremden Absender IPs im Default blockt UND auch das sie generell das ICMP Protokoll blockt wie oben schon mehrfach beschrieben.
Solange du DAS nicht beides in den lokalen Firewalls deiner Windows Rechner anpasst wirst du weiter diese Probleme haben Windows Maschinen zu pingen:
https://www.windowspro.de/tipp/ping-windows-7-server-2008-r2-zulassen
Sinnvoll wäre hier wieder gewesen wenn du mal geschrieben hättest ob der wenigstens die .55.1 am RasPi hat pingen können
Deshalb auch der wiederkehrende Appell hier zum Ping Test erstmal einem RasPi, Drucker oder was auch immer zu nehmen was keine lokale Firewall hat um nicht in diese Falle zu tappen.
Hier auch wieder der wichtige Tip: Auf dem .55er Client mal einen Wireshark installieren und checken ob du die eingehenden ICMP Ping Pakete (Echo) aus dem 44er Netz sehen kannst.
Grundproblem bei Windows ist und bleibt aber die nicht angepasste Firewall mit dem Blocking von ICMP.
Der DNS- und Webserver läuft auf Oracle Virtualbox mit NIC als Netzwerkbrücke und dementsprechend mit eigener IP.
Das ist auch OK solange das eine .44.x IP ist und das Default Gateway der Rechner auf die 44.1 eingestellt ist und die frei ins 44er und 55er Netz pingen können z.B. die 55.1 am RasPi.
Wenn ich nun 192.168.44.1 (Internet-Gateway) als DNS eintrage funktioniert das auflösen von Internet-Adressen ebenso.
Zeigt eigentlich das das Routing dann sauber funktioniert und das DNS auch wenn es denn richtig gemacht wird.
Gerade sehe ich nur noch Zahlen und Buchstaben auf meiner Netzhaut.
Das ist richtig. Beim Schlafen kommen einem meistens auch noch Ideen in den Sinn.
Dann warten wir mal ab was der Sonntag bringt... Hier die wichtigstens ToDos:
Dazu sähe deine dhcpd.conf Datei dann so aus:
ACHTUNG!: Da du den DHCP Server im RasPi nur auf das eth1 Segment einschränken willst (eth0 darf keine IPs vergeben, das macht der Internet Router) musst du dem Server das noch in der /etc/default/isc-dhcp-server Datei sagen unter:
Dann /etc/init.d/isc-dhcp-server restart und fertig ist der Lack. DHCP am AP dann natürlich deaktivieren !
So, jetzt hast du was zu basteln für den Sonntag...
Bitte warten ..
Mitglied: Oldschool
26.03.2017 um 20:18 Uhr
Also,

habe dann heute morgen festgestellt, dass ich Einiges dank diesem Forum dazugelernt habe. Danke dafür.

Heute morgen ging es trotz Zeitumstellung früh ans Werk. Ich habe den privaten DNS erst einmal runtergefahren und im 55er Netz den DNS neu auf 192.168.11.1 konfiguriert.

Danach funktionierte auch der Ping von zB 192.168.55.11 (Windows-PC) auf 192.168.44.252 (Netzwerkdrucker). Die Testseite, die ich dann gedruckt habe, rahme ich mir ein. Auch das pingen auf www.heise.de funktionierte.

Ich habe die Standard-Gateway-Einstellungen alle überprüft und es waren bereits überall Einträge drin auf 192.168.44.1. Auch das Routing auf dem Raspi scheint ja jetzt nach kleinen Änderungen sauber zu sein. Im Grossen und Ganzen muss ich sagen, dass ich ordentlich und konsequent gearbeitet habe - um mich mal an dieser Stelle selbst zu loben

Ich habe jetzt auch dank Euren Beiträgen verstanden, dass ich nicht einfach irgendwelche Windows-Rechner aus fremden Netzen anpingen kann, ohne das in der PC-eigenen Firewall entsprechend freizugeben. Man ist es ja so gewohnt dass man Rechner einfach anpingen kann, wenn man sich nur in einem Netz befindet und nimmt an, dass es auch geht wenn man die Netze mit einem Router verbindet... Grosser Fehler meinerseits.

Gestern Abend noch war ich schier am Verzweifeln und habe immer wieder die statische Route im InternetGateway hinterfragt. Ich war schon fast soweit ein neues Gerät anzuschaffen, weil es nach meiner Ansicht kaputt sein musste.

Natürlich habe ich auch schon von beiden Netzen aus auf den jeweils anderen NIC des Raspis gepingt. Also aus dem 44er Netz auf 192.168.55.1 und vom 55er Netz auf 192.168.44.254. Das funktionierte immer. Aber alle Adressen dahinter gingen dann nicht. Auch tracert, traceroute und pathping starben hinter dem NIC des Raspis. Nun weiss ich, dass es in den meisten Fällen an der ICMP-Freigabe der PC-Firewalls lag.

Um den privaten DNS und den Webserver mit dem Intranet wieder zu aktivieren, schaue ich mir im Laufe der Woche mal die Konfig der VM an. Eine Frage dazu hätte ich noch: Der virtuelle NIC steht ja auf Bridged und hat eine eigene IP. Muss ich dennoch auf dem Windows-Host, wo sich ja der physische NIC befindet, Zugriffe vom 55er Netz zulassen?

Ansonsten würde ich meine Ursprungsfrage zum Routingproblem als gelöst markieren, wenn niemand einer anderen Ansicht ist. Meine nächste Grossbaustelle ist dann der private DNS. Dazu würde ich dann aber besser eine neue Frage eröffnen. Aber erst einmal sollte ich mit dem neu erlangten Wissen selber klar kommen.

Schöne Grüsse und grossen Dank an alle Beteiligten.
Bitte warten ..
Mitglied: Lochkartenstanzer
26.03.2017 um 20:36 Uhr
Zitat von Oldschool:

Ansonsten würde ich meine Ursprungsfrage zum Routingproblem als gelöst markieren, wenn niemand einer anderen Ansicht ist.

Du mußt es selbst wissen, ob Dein Probem damit gelöst ist oder nicht.

Dann bleibt also nur noch https://www.administrator.de/faq/32

Schönen Restsonntag noch.

lks
Bitte warten ..
Mitglied: aqui
27.03.2017 um 10:19 Uhr
und im 55er Netz den DNS neu auf 192.168.11.1 konfiguriert.
Huch ??? Was hat diese IP denn da nun wieder zu suchen ?? Du hast doch weit und breit gar kein .11.0er Netzwerk.
Was ist das denn nun schon wieder ??
Danach funktionierte auch der Ping von zB 192.168.55.11 .....
Wie erwartet. So sollte es sein !
dass ich ordentlich und konsequent gearbeitet habe - um mich mal an dieser Stelle selbst zu loben
Riecht zwar ziemlich stark nach Eichenlaub aber wo du Recht hast hast du Recht....
Man ist es ja so gewohnt dass man Rechner einfach anpingen kann
Generell stimmt das auch aber Winblows ist wie immer etwas spezieller....
Das liegt aber daran das das OS weltweit Angriffsziel Nummer 1 ist und MS hier den Spagat zwischen Sicherheit und User Bequemlichkeit machen muss. Nicht imemr ganz einfach muss man denen fairerweise zugestehen.
und habe immer wieder die statische Route im InternetGateway hinterfragt.
Ooops, warum ???
Die ist essentiell wichtig, Ohne sie würde das Routing in deinen beiden Netzen nicht klappen. Hier hat der Administrator.de Erklärbärmal so einen IP Paket Flow durch Router genau beschrieben:
https://www.administrator.de/wissen/routing-2-netzwerkkarten-windows-u-l ...
Da sollte auch dir dann klar sein wie wichtig diese Route ist.
Nun weiss ich, dass es in den meisten Fällen an der ICMP-Freigabe der PC-Firewalls lag.
Ja, immer wenn diese Winblows Gurken sind...
Um den privaten DNS und den Webserver mit dem Intranet wieder zu aktivieren, schaue ich mir im Laufe der Woche mal die Konfig der VM an.
Nicht nur das sondern auch die des DNS Servers selber:
http://www.raspberry-pi-geek.de/Magazin/2014/03/RasPi-als-DHCP-und-DNS- ...
https://www.blogging-it.com/bind-dns-server-unter-raspbian-installieren- ...
https://it-lehre.de/2013/02/dns-server-unter-debian-installieren-und-kon ...
usw.
Meine nächste Grossbaustelle ist dann der private DNS.
Weise Worte und Dr. Google hat da für dich Tausende Dokumente parat

Dann bleibt in der Tat nur https://www.administrator.de/faq/32
Und...ebenso viel Erfolg !
Bitte warten ..
Mitglied: Oldschool
28.03.2017 um 19:26 Uhr
Zitat von aqui:

und im 55er Netz den DNS neu auf 192.168.11.1 konfiguriert.
Huch ??? Was hat diese IP denn da nun wieder zu suchen ?? Du hast doch weit und breit gar kein .11.0er Netzwerk.
Was ist das denn nun schon wieder ??
Danach funktionierte auch der Ping von zB 192.168.55.11 .....

Das war ein Verschreiber. Solle 192.168.44.1 heissen. Ich war aber gedanklich schon bei der Client IP mit der 11 am Ende…


So, kurz die Zusammenfassung der Lösung:

Zur Lösung beigetragen hat die Erkenntnis, dass es auf einen ping-request auf WindowsClients in anderen Netzen keinen ping-response gibt, wenn man die Firewall nicht für ICMP aus anderen Netzen freischaltet.
Desweiteren habe ich nun verstanden, dass es in meinem oben geschilderten Fall keine statische Route auf dem Raspi braucht, denn er steht ja mit jeweils einem NIC in beide Netze und kennt sie somit auch. Es braucht nur die statische Route ins 55er Netz auf dem Standard-Gateway des 44er Netzes.


Klugscheissmodus = on

Wenn man beispielsweise neben einem bestehenden Netz (mit DNS- und Intranet-Server) eine Art Gästenetzwerk bereitstellen möchte, dann ist es sehr sinnvoll in diesen Server eine zweite Netzwerkkarte einzubauen und Ihn auch als Router zwischen beide Netze zu verwenden. Macht man es so wie ich und schafft sich ein Gerät für das Routing neu an, sollte man eventuell bestehende Dienste auf dieses Gerät umziehen, insofern man die Dienste auch für beide Netze nutzen möchte. Das reduziert Fehlerquellen und spart Ressourcen und Wartungsaufwand.

Klugscheissmodus = off

Nahezu jede Antwort hat hier dazu beigetragen, dass ich mein Eingangs-Problem lösen konnte.

Unbedingt lesenswert sind die weiterführenden Links von aqui für die Einrichtung des DNS und megaklasse die für meinen speziellen Fall angepasste Config des DHCP. Danke dafür.

Bis neulich
Bitte warten ..
Mitglied: aqui
29.03.2017 um 10:03 Uhr
wenn man die Firewall nicht für ICMP aus anderen Netzen freischaltet.
Unser reden oben...!
dass es in meinem oben geschilderten Fall keine statische Route auf dem Raspi braucht,
Auch nicht ganz richtig, denn es braucht wenigstens eine auf dem RasPi, nämlich die statische Default Route. Aber wir wollen ja nicht spitzfindig sein...
eine Art Gästenetzwerk bereitstellen möchte, dann ist es sehr sinnvoll in diesen Server eine zweite Netzwerkkarte einzubauen und Ihn auch als Router zwischen beide Netze zu verwenden.
Nein !
Das ist vollkommen falsch, denn so hättest du einen parallelen Backdoor Router. Aus Sicherheitssicht wäre das tödlich, denn ein Gästenetz ist IMMER vollkommen separiert vom eigenen, privaten Netz. Oder sollte es wenigstens sein wenn man es richtig macht.
In so fern schaltet man immer einen Router oder eine Firewall mit 3 Interfaces dazu. Hier findest du Konzepte wie man es richtig macht um die Netze zu trennen:
https://www.administrator.de/wissen/preiswerte-vpn-fähige-firewall- ...
Dein Konzept ein Gastnetz quasi "durchzuschleifen" ist die grundlegende Fehlerquelle, denn das Netzwerk Design ist vollkommen falsch. Leuchtet dir vermutlich auch selber ein jetzt. Kein Netzwerker würde das so lösen.
Nahezu jede Antwort hat hier dazu beigetragen, dass ich mein Eingangs-Problem lösen konnte.
Das ist doch die Hauptsache ! Wenn jetzt noch die Design Erkenntnis kommt hat das Forum ja was bewirkt
Danke dafür.
Immer gerne wieder
Bitte warten ..
Ähnliche Inhalte
Linux
Lizenzfrage realvnc Raspi
Frage von BitboyLinux2 Kommentare

Hi zusammen, ich habe einen Raspi mit rasbian Buster in der Firma und wollte VNC benutzen. Vorinstalliert ist ja ...

Debian
Raspi als Hotspot - Proxyeinstellungen?
Frage von billy01Debian9 Kommentare

Hey zusammen, Ich habe meinen Raspi so konfiguriert, dass er als Hotspot die Lanverbindung mit dem Wlaninterface teilt. Das ...

Debian
Raspi VM Partition erweitern
gelöst Frage von blackhawk17Debian4 Kommentare

Guten morgen, ich habe ein Raspi auf einem ESXi Server laufen. Leider ist nur mir nun meine Festplatte auf ...

Netzwerkmanagement

Unify WLAN Controller mit RasPi und Docker

Tipp von aquiNetzwerkmanagement6 Kommentare

Andere WiFi Hersteller haben den Controller sinnvollerweise gleich beim WLAN AP mit an Bord. Bei den einfachen Unify APs ...

Neue Wissensbeiträge
Administrator.de Feedback
Hinweise auf Dienstleister oder auf Suchmaschinen
Information von Frank vor 3 TagenAdministrator.de Feedback71 Kommentare

Lieber User, Admins und Moderatoren, aus gegebenen Anlass möchte ich zwei Dinge endgültig klarstellen und für die Nachwelt festhalten: ...

Router & Routing

PfSense 2.4 IPSec VPN mobile Clients Phase 2 wird plötzlich nicht mehr aufgebaut - So einfach war die Lösung

Tipp von the-buccaneer vor 4 TagenRouter & Routing9 Kommentare

Moinsen! Nachdem ich mir hierbei nen Wolf gesucht habe, möchte ich doch die Welt an dieser simplen Lösung teilhaben ...

Humor (lol)
Wählscheiben Telefon
Information von brammer vor 4 TagenHumor (lol)4 Kommentare

Hallo, Mal wirkliche eine nette Spielerei brammer

Sicherheit

Zeitenwende: Mehr pot. Mac- (Heise Wortlaut) als Windowsbedrohungen

Information von certifiedit.net vor 5 TagenSicherheit4 Kommentare

Wir hatten es ja hier erst letztens, dass OS bzw Mac auch nicht der Weisheit letzter Schluss ist, nun ...

Heiß diskutierte Inhalte
Backup
VMware ESXi Cluster Backup
Frage von ADRNEXBackup22 Kommentare

Hallo zusammen, Ich habe eine vmware esxi cluster Umgebung mit ca. 20TB Daten, die auf einem SAN liegen. Es ...

Netzwerkmanagement
Softwareverteilung für kleines Unternehmen mit sehr gemixter Hardware
gelöst Frage von BavarianSysadNetzwerkmanagement20 Kommentare

Hallo zusammen^^, ich stehe vor dem Problem das wir im Unternehmen eine Softwareverteilung einführen soll, leider ist dies wie ...

Netzwerke
Frage zu Spanning-Tree-Layout
Frage von LordGurkeNetzwerke11 Kommentare

Hallo zusammen, ich habe aktuell das Problem, dass in einem relativ frisch aufgebauten Netzwerk mit redundanten Pfaden und MSTP ...

Router & Routing
OpenWrt Router und IPsec iptables
Frage von Achim462Router & Routing10 Kommentare

Hallo. Ich weiß nicht ob das der richtige Ort für dieses Thema ist. Falls nicht, kann ein Administrator dieses ...