4
NAS nach Proxyinstallation nicht mehr erreichbar
Hallo an alle!
Ich habe momentan ein Problem mit einem neu installierten Proxy innerhalb des Netzwerkes.
Bei diesem Netzwerk handelt es sich um ein Schulungsnetzwerk was ein Backbone besitzt und ansonsten alle weiteren Subnetze als VLAN weitererreicht. Der Backbone arbeitet mit dem Netz 192.168.254.0/24 und die VLANs mit den Netzen 10.9.x.x/24. Besagter Proxy sitzt auf dem Backbone, da darüber auch der DHCP und DNS läuft, sowie die Verbindung in das Internet. Eine direkte Konfiguration des Proxys oder VLAN-Switch ist mir so nicht möglich, da dies von der zentralen IT gemanaget wird. Soviel zu den Eckdaten des Netzwerkes.
Besagtes NAS ist nun so angeschlossen das es im Backbone mit der IP 192.168.254.100/24 erreichbar ist, was auch über den Browser funktioniert (Adminoberfläche läßt sich aufrufen und konfigurieren). Das NAS ist ein D-Link 320L was für die Schulungsteilnehmer gedacht ist. Problem hierbei ist das ich das NAS allerdings nicht per Windows Explorer oder mount-Befehl unter Linux einhängen / erreichen kann. Der entsprechende Proxy ist auch auf den Rechner in den Internetoptionen unter Verbindungen => LAN-Einstellungen ganz normal eingetragen, da dieser noch nicht per DHCP ausgeliefert wird.
Einer meiner Ideen war schon mal die Option das der Proxy bei internen IPs umgangen wird, was aber ebenfalls nicht zur Lösung beigetragen hat. Anpingen läßt sich das NAS ebenfalls nicht, da es dort zu einer Zeitüberschreitung der Anforderung kommt und das war es auch schon gewesen was ich aus den entsprechenden VLANs machen kann, da alles andere entsprechend geblockt wird / anscheinend nicht mehr funktioniert. Bevor der Proxy installiert wurde, lief der Zugriff auf das NAS für die Teilnehmer.
Falls da jemand eine Idee hat woran das liegen könnte (ich vermute eine Fehlkonfiguration des Proxys) oder was ich direkt probieren könnte (ohne die zentrale IT zu involvieren) bin ich für jede Hilfe dankbar
Gruß
liquid
Ich habe momentan ein Problem mit einem neu installierten Proxy innerhalb des Netzwerkes.
Bei diesem Netzwerk handelt es sich um ein Schulungsnetzwerk was ein Backbone besitzt und ansonsten alle weiteren Subnetze als VLAN weitererreicht. Der Backbone arbeitet mit dem Netz 192.168.254.0/24 und die VLANs mit den Netzen 10.9.x.x/24. Besagter Proxy sitzt auf dem Backbone, da darüber auch der DHCP und DNS läuft, sowie die Verbindung in das Internet. Eine direkte Konfiguration des Proxys oder VLAN-Switch ist mir so nicht möglich, da dies von der zentralen IT gemanaget wird. Soviel zu den Eckdaten des Netzwerkes.
Besagtes NAS ist nun so angeschlossen das es im Backbone mit der IP 192.168.254.100/24 erreichbar ist, was auch über den Browser funktioniert (Adminoberfläche läßt sich aufrufen und konfigurieren). Das NAS ist ein D-Link 320L was für die Schulungsteilnehmer gedacht ist. Problem hierbei ist das ich das NAS allerdings nicht per Windows Explorer oder mount-Befehl unter Linux einhängen / erreichen kann. Der entsprechende Proxy ist auch auf den Rechner in den Internetoptionen unter Verbindungen => LAN-Einstellungen ganz normal eingetragen, da dieser noch nicht per DHCP ausgeliefert wird.
Einer meiner Ideen war schon mal die Option das der Proxy bei internen IPs umgangen wird, was aber ebenfalls nicht zur Lösung beigetragen hat. Anpingen läßt sich das NAS ebenfalls nicht, da es dort zu einer Zeitüberschreitung der Anforderung kommt und das war es auch schon gewesen was ich aus den entsprechenden VLANs machen kann, da alles andere entsprechend geblockt wird / anscheinend nicht mehr funktioniert. Bevor der Proxy installiert wurde, lief der Zugriff auf das NAS für die Teilnehmer.
Falls da jemand eine Idee hat woran das liegen könnte (ich vermute eine Fehlkonfiguration des Proxys) oder was ich direkt probieren könnte (ohne die zentrale IT zu involvieren) bin ich für jede Hilfe dankbar
Gruß
liquid
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-Key: 280105
Url: https://administrator.de/contentid/280105
Ausgedruckt am: 19.04.2024 um 19:04 Uhr
4 Kommentare
Neuester Kommentar
Hallo,
schon mal versucht, die lokalen Subnetze (VLANs) im obigen Fenster unter "Erweitert" als Ausnahmen (soll nicht über Proxy erreicht werden, sondern direkt) einzutragen?
Jürgen
schon mal versucht, die lokalen Subnetze (VLANs) im obigen Fenster unter "Erweitert" als Ausnahmen (soll nicht über Proxy erreicht werden, sondern direkt) einzutragen?
Jürgen
1
Gerade getestet und zeigt keine Wirkung. An die Option hatte ich jetzt im ersten Moment nicht gedacht. Danke für den Hinweis.
Hallo.
schon mal mit tracert geschaut, wo die Pakete lang gehen?
Oder mit Wireshark die Antworten auf die nicht ankommenden Pakete analysiert?
Jürgen
schon mal mit tracert geschaut, wo die Pakete lang gehen?
Oder mit Wireshark die Antworten auf die nicht ankommenden Pakete analysiert?
Jürgen
Erstmal Entschuldigung das ich mich heute erst wieder melde, aber ich musste einen unfreiwilligen Krankenhausaufenthalt einschieben. Aber das wird jetzt nachgeholt, da dass Problem weiterhin besteht.
tracert =>
Das hatte ich nach drei Versuchen immer wieder abgebrochen weil ab dem VLAN-Switch der Weg ins Backbonenetz geht. 10.9.11.254 ist hierbei der VLAN-Switch der den Port zur Verfügung stellt.
Wireshark selbst gibt auch ein Not Response zurück
Wenn ich mir das Datenpaket so anschaue und mal durchgehe, hört der Weg direkt am Proxy auf und wird von diesem einfach verworfen da er den Aufruf über den Windows-Explorer oder per mount unter Linux einfach blockt. Sehe ich das richtig?
tracert =>
Routenverfolgung zu eduhost.schule.local [192.168.254.100]
über maximal 30 Hops:
1 <1 ms <1 ms <1 ms 10.9.11.254
2 * * * Zeitberschreitung der Anforderung.
3 * * * Zeitberschreitung der Anforderung.
4 * * * Zeitberschreitung der Anforderung.Das hatte ich nach drei Versuchen immer wieder abgebrochen weil ab dem VLAN-Switch der Weg ins Backbonenetz geht. 10.9.11.254 ist hierbei der VLAN-Switch der den Port zur Verfügung stellt.
Wireshark selbst gibt auch ein Not Response zurück
No. Time Source Destination Protocol Length Info
18 0.327630000 10.9.11.17 192.168.254.100 ICMP 106 Echo (ping) request id=0x0001, seq=49/12544, ttl=16 (no response found!)
Frame 18: 106 bytes on wire (848 bits), 106 bytes captured (848 bits) on interface 0
Interface id: 0 (\Device\NPF_{C9C93873-F5D9-4867-B05D-C7579BF55D5F})
Encapsulation type: Ethernet (1)
Arrival Time: Aug 24, 2015 09:05:38.366834000 Mitteleuropäische Sommerzeit
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1440399938.366834000 seconds
[Time delta from previous captured frame: 0.013299000 seconds]
[Time delta from previous displayed frame: 0.013299000 seconds]
[Time since reference or first frame: 0.327630000 seconds]
Frame Number: 18
Frame Length: 106 bytes (848 bits)
Capture Length: 106 bytes (848 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:icmp:data]
[Coloring Rule Name: ICMP]
[Coloring Rule String: icmp || icmpv6]
Ethernet II, Src: FujitsuT_91:72:c0 (00:19:99:91:72:c0), Dst: Routerbo_e8:8c:ca (4c:5e:0c:e8:8c:ca)
Destination: Routerbo_e8:8c:ca (4c:5e:0c:e8:8c:ca)
Address: Routerbo_e8:8c:ca (4c:5e:0c:e8:8c:ca)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Source: FujitsuT_91:72:c0 (00:19:99:91:72:c0)
Address: FujitsuT_91:72:c0 (00:19:99:91:72:c0)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: IP (0x0800)
Internet Protocol Version 4, Src: 10.9.11.17 (10.9.11.17), Dst: 192.168.254.100 (192.168.254.100)
Version: 4
Header Length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
Total Length: 92
Identification: 0x0e47 (3655)
Flags: 0x00
0... .... = Reserved bit: Not set
.0.. .... = Don't fragment: Not set
..0. .... = More fragments: Not set
Fragment offset: 0
Time to live: 16
Protocol: ICMP (1)
Header checksum: 0x0000 [validation disabled]
[Good: False]
[Bad: False]
Source: 10.9.11.17 (10.9.11.17)
Destination: 192.168.254.100 (192.168.254.100)
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
Internet Control Message Protocol
Type: 8 (Echo (ping) request)
Code: 0
Checksum: 0xf7cd [correct]
Identifier (BE): 1 (0x0001)
Identifier (LE): 256 (0x0100)
Sequence number (BE): 49 (0x0031)
Sequence number (LE): 12544 (0x3100)
[No response seen]
[Expert Info (Warn/Sequence): No response seen to ICMP request in frame 18]
[No response seen to ICMP request in frame 18]
[Severity level: Warn]
[Group: Sequence]
Data (64 bytes)
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Data: 000000000000000000000000000000000000000000000000...
[Length: 64]Wenn ich mir das Datenpaket so anschaue und mal durchgehe, hört der Weg direkt am Proxy auf und wird von diesem einfach verworfen da er den Aufruf über den Windows-Explorer oder per mount unter Linux einfach blockt. Sehe ich das richtig?
