liquidbase
Goto Top

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.

a386e07712b71d13de6241b478db9944

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 face-smile

Gruß
liquid

Content-Key: 280105

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

Printed on: April 21, 2024 at 17:04 o'clock

Member: chiefteddy
chiefteddy Aug 13, 2015 at 11:19:55 (UTC)
Goto Top
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
Member: liquidbase
liquidbase Aug 13, 2015 at 12:24:35 (UTC)
Goto Top
Gerade getestet und zeigt keine Wirkung. An die Option hatte ich jetzt im ersten Moment nicht gedacht. Danke für den Hinweis.
Member: chiefteddy
chiefteddy Aug 13, 2015 updated at 12:36:22 (UTC)
Goto Top
Hallo.

schon mal mit tracert geschaut, wo die Pakete lang gehen?

Oder mit Wireshark die Antworten auf die nicht ankommenden Pakete analysiert?

Jürgen
Member: liquidbase
liquidbase Aug 24, 2015 at 07:37:03 (UTC)
Goto Top
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 =>
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     *        *        *     Zeitberschreitung der Anforderung.
 3     *        *        *     Zeitberschreitung der Anforderung.
 4     *        *        *     Zeitberschreitung 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?