14
1 Server kann nicht mit Clients kommunizieren
Guten Morgen, ihr Götter aller Netzwerke!
Ich stehe mittlerweile ein bisschen seeeeehr auf der Leitung & bräuchte bitte eure Hilfe!
Folgendes Szenario:
Ich habe 2 VLANS - wir nennen diese jetzt mal ServerLAN und ClientLAN.
Im ServerLAN werden an jeden Server die gleichen Policies verteilt und im ClientLAN werden an jeden Client die gleichen Policies verteilt.
Ich habe nun im ServerLAN einen virtuellen Server(hier:Server1) - der seit gestern (letzte Woche lief noch alles gut) mit keinem Client mehr aus dem ClientLAN kommunizieren kann.
Und umgekehrt genauso, sprich kein Client kann mit diesem einen Server kommunizieren.
Jeder andere Server kann mit dem ClientLAN kommunizieren und jeder Client kann einen anderen Server im ServerLAN erreichen.
Server1 ist online - aus dem ServerLAN ohne Probleme zu erreichen, aus dem VPN Netz zu erreichen und sogar von extern (via Website mit öffentlicher IP).
Firewall Rule: Erlaubt alle sources auf die interne und öffentliche Adresse mit Port 80&443. ICMP erlaubt.
Wenn ich eine Wireshark Abfrage mache von einem Client der Server1 erreichen will. Sehe ich dass beim Ping keine Antwort zurück kommt und beim Aufruf der Website, dass die SYN Anfrage losgeschickt wird - aber keine ACK zurückkommt. Sprich TCP-Handshake nicht vorhanden.
In den Logs vom Server sehe ich allerdings dass keine Anfragen von dem Client Netz zum Server kommen.
Ich suche gerade eine Nadel im Heuhaufen und bin maßlos überfordert mit diesem Problem.
Vielleicht kann mir einer von euch helfen oder einen guten Denkanstoß liefern?
Liebe Grüße,
ITGhost
Ich stehe mittlerweile ein bisschen seeeeehr auf der Leitung & bräuchte bitte eure Hilfe!
Folgendes Szenario:
Ich habe 2 VLANS - wir nennen diese jetzt mal ServerLAN und ClientLAN.
Im ServerLAN werden an jeden Server die gleichen Policies verteilt und im ClientLAN werden an jeden Client die gleichen Policies verteilt.
Ich habe nun im ServerLAN einen virtuellen Server(hier:Server1) - der seit gestern (letzte Woche lief noch alles gut) mit keinem Client mehr aus dem ClientLAN kommunizieren kann.
Und umgekehrt genauso, sprich kein Client kann mit diesem einen Server kommunizieren.
Jeder andere Server kann mit dem ClientLAN kommunizieren und jeder Client kann einen anderen Server im ServerLAN erreichen.
Server1 ist online - aus dem ServerLAN ohne Probleme zu erreichen, aus dem VPN Netz zu erreichen und sogar von extern (via Website mit öffentlicher IP).
Firewall Rule: Erlaubt alle sources auf die interne und öffentliche Adresse mit Port 80&443. ICMP erlaubt.
Wenn ich eine Wireshark Abfrage mache von einem Client der Server1 erreichen will. Sehe ich dass beim Ping keine Antwort zurück kommt und beim Aufruf der Website, dass die SYN Anfrage losgeschickt wird - aber keine ACK zurückkommt. Sprich TCP-Handshake nicht vorhanden.
In den Logs vom Server sehe ich allerdings dass keine Anfragen von dem Client Netz zum Server kommen.
Ich suche gerade eine Nadel im Heuhaufen und bin maßlos überfordert mit diesem Problem.
Vielleicht kann mir einer von euch helfen oder einen guten Denkanstoß liefern?
Liebe Grüße,
ITGhost
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-ID: 1258121848
Url: https://administrator.de/forum/1-server-kann-nicht-mit-clients-kommunizieren-1258121848.html
Ausgedruckt am: 22.12.2024 um 21:12 Uhr
14 Kommentare
Neuester Kommentar
Moin,
also als erstes würde ich mal auf der Firewall bzw. dem Gerät schauen, welches das Routing für die VLANs übernimmt.
Stimmen die Standardgateways?
Wurden Routing-Einträge "irgendwo" kürzlich verändert?
Gruß
em-pie
also als erstes würde ich mal auf der Firewall bzw. dem Gerät schauen, welches das Routing für die VLANs übernimmt.
Stimmen die Standardgateways?
Wurden Routing-Einträge "irgendwo" kürzlich verändert?
Gruß
em-pie
Zitat von @em-pie:
Moin,
also als erstes würde ich mal auf der Firewall bzw. dem Gerät schauen, welches das Routing für die VLANs übernimmt.
Stimmen die Standardgateways?
Wurden Routing-Einträge "irgendwo" kürzlich verändert?
Gruß
em-pie
Moin,
also als erstes würde ich mal auf der Firewall bzw. dem Gerät schauen, welches das Routing für die VLANs übernimmt.
Stimmen die Standardgateways?
Wurden Routing-Einträge "irgendwo" kürzlich verändert?
Gruß
em-pie
Hey,
Standardgateways stimmen, sind erreichbar und up. Und das Routing für die VLANS habe ich auch überprüft. Da es bei anderen virtuellen Maschinen, die am gleichen Host angelegt sind funktioniert kann man das ausschließen oder?
Weder ich noch mein Kollege haben irgendetwas verändert. Der System-Stand ist der gleiche wie von letzter Woche wo es noch funktioniert hat.
LG,
Zitat von @ITghost:
Wenn ich eine Wireshark Abfrage mache von einem Client der Server1 erreichen will. Sehe ich dass beim Ping keine Antwort zurück kommt und beim Aufruf der Website, dass die SYN Anfrage losgeschickt wird - aber keine ACK zurückkommt. Sprich TCP-Handshake nicht vorhanden.
In den Logs vom Server sehe ich allerdings dass keine Anfragen von dem Client Netz zum Server kommen.
Wenn ich eine Wireshark Abfrage mache von einem Client der Server1 erreichen will. Sehe ich dass beim Ping keine Antwort zurück kommt und beim Aufruf der Website, dass die SYN Anfrage losgeschickt wird - aber keine ACK zurückkommt. Sprich TCP-Handshake nicht vorhanden.
In den Logs vom Server sehe ich allerdings dass keine Anfragen von dem Client Netz zum Server kommen.
Mach sowohl auf dem Server als auch auf dem Hypervisor einen Wireshark-Mitschnitt, ob die SYN- oder ICMP-Pakete bis dahin kommen. Dann weißt Du, ob Du beim Gateway, der Firewall, im Hypervisor oder der VM suchen mußt.
Weder ich noch mein Kollege haben irgendetwas verändert.
Das sagen sie alle.
Der System-Stand ist der gleiche wie von letzter Woche wo es noch funktioniert hat.
Offensichtlich nicht, denn sonst würde es ja funktioniren. Euer Gesamtsystem hat sich anscheinend so verändert, daß es eben jetzt nicht mehr geht. Mag sein, daß die VM vielleicht noch die gleiche Config hat, aber ohne den Hypervisor, die Firewall und die Router, ggf. sogar noch die switche, zu prüfen, kannst Du nicht behaupten, es hätte sich nichts geändert.
lks
Spontan hätte ich auch gesagt:
Gateway oder Subnetzmaske in der Server-VM falsch (warum auch immer). Auf jeden Fall prüfen.
Dann sollte es aber auch aus dem VPN nicht klappen, davon ausgehend, dass das ein eigenes Netz ist.
Gateway oder Subnetzmaske in der Server-VM falsch (warum auch immer). Auf jeden Fall prüfen.
Dann sollte es aber auch aus dem VPN nicht klappen, davon ausgehend, dass das ein eigenes Netz ist.
1Zitat von @ITghost:
Hey,
Standardgateways stimmen, sind erreichbar und up. Und das Routing für die VLANS habe ich auch überprüft. Da es bei anderen virtuellen Maschinen, die am gleichen Host angelegt sind funktioniert kann man das ausschließen oder?
Weder ich noch mein Kollege haben irgendetwas verändert. Der System-Stand ist der gleiche wie von letzter Woche wo es noch funktioniert hat.
LG,
Zitat von @em-pie:
Moin,
also als erstes würde ich mal auf der Firewall bzw. dem Gerät schauen, welches das Routing für die VLANs übernimmt.
Stimmen die Standardgateways?
Wurden Routing-Einträge "irgendwo" kürzlich verändert?
Gruß
em-pie
Moin,
also als erstes würde ich mal auf der Firewall bzw. dem Gerät schauen, welches das Routing für die VLANs übernimmt.
Stimmen die Standardgateways?
Wurden Routing-Einträge "irgendwo" kürzlich verändert?
Gruß
em-pie
Hey,
Standardgateways stimmen, sind erreichbar und up. Und das Routing für die VLANS habe ich auch überprüft. Da es bei anderen virtuellen Maschinen, die am gleichen Host angelegt sind funktioniert kann man das ausschließen oder?
Weder ich noch mein Kollege haben irgendetwas verändert. Der System-Stand ist der gleiche wie von letzter Woche wo es noch funktioniert hat.
LG,
Dann erzähle mal ein wenig etwas zum besagten Server selbst, und auch, wer nun das Routing übernimmt. ein L3-Switch oder eine Firewall/ UTM?
Bzgl. des Servers ist mir eines nicht ganz klar:
Hängt der mit dem "nackten Ar***" im WWW, weil ihr eine Portweiterleitung auf 80 & 443 aktiv habt oder ist da noch ein ReverseProxy vorgesschaltet?
Im ersten Fall: ich würde mal sämtliche Logs verifizieren. Nicht, dass eure Kiste gekapert wurde.
auch mal ein
route Print laufen lassen und prüfen, ob da nicht irgendwelche Einträge verbogen sind.Zitat von @Lochkartenstanzer:
Mach sowohl auf dem Server als auch auf dem Hypervisor einen Wireshark-Mitschnitt, ob die SYN- oder ICMP-Pakete bis dahin kommen. Dann weißt Du, ob Du beim Gateway, der Firewall, im Hypervisor oder der VM suchen mußt.
Zitat von @ITghost:
Wenn ich eine Wireshark Abfrage mache von einem Client der Server1 erreichen will. Sehe ich dass beim Ping keine Antwort zurück kommt und beim Aufruf der Website, dass die SYN Anfrage losgeschickt wird - aber keine ACK zurückkommt. Sprich TCP-Handshake nicht vorhanden.
In den Logs vom Server sehe ich allerdings dass keine Anfragen von dem Client Netz zum Server kommen.
Wenn ich eine Wireshark Abfrage mache von einem Client der Server1 erreichen will. Sehe ich dass beim Ping keine Antwort zurück kommt und beim Aufruf der Website, dass die SYN Anfrage losgeschickt wird - aber keine ACK zurückkommt. Sprich TCP-Handshake nicht vorhanden.
In den Logs vom Server sehe ich allerdings dass keine Anfragen von dem Client Netz zum Server kommen.
Mach sowohl auf dem Server als auch auf dem Hypervisor einen Wireshark-Mitschnitt, ob die SYN- oder ICMP-Pakete bis dahin kommen. Dann weißt Du, ob Du beim Gateway, der Firewall, im Hypervisor oder der VM suchen mußt.
Was mich wundert - wenn ich ein tracert mache vom Client auf Server1 - ist der first hop die FW ( bis dahin ja noch gut) aber es kommt kein Second hop.
Da, dass ganze aber eigentlich eine interne Abwicklung ist, sollte er auf die FW gehen und dann auf die interne IP von dem Server. Denn so funktionierts im VPN Netz - ich weiß leider ob er beim ClientLAN nach der FW den Server versucht zu kontaktieren oder ob er da noch nen zwischen hop machen würde zu was/wem auch immer..
Weder ich noch mein Kollege haben irgendetwas verändert.
Das sagen sie alle.
haha Der System-Stand ist der gleiche wie von letzter Woche wo es noch funktioniert hat.
Offensichtlich nicht, denn sonst würde es ja funktioniren. Euer Gesamtsystem hat sich anscheinend so verändert, daß es eben jetzt nicht mehr geht. Mag sein, daß die VM vielleicht noch die gleiche Config hat, aber ohne den Hypervisor, die Firewall und die Router, ggf. sogar noch die switche, zu prüfen, kannst Du nicht behaupten, es hätte sich nichts geändert.
Dann erzähle mal ein wenig etwas zum besagten Server selbst, und auch, wer nun das Routing übernimmt. ein L3-Switch oder eine Firewall/ UTM?
Der besagte Server ist einfach ein virtueller Windows Server 2016 - auf dem eine FileMaker Datenbank rennt (die von einem externen Dienstleister betreut und verwaltet wird). Wir stellen hier nur den Server und das Netzwerk zur Verfügung. Das Routing übernimmt eine "wunderschöne" Checkpoint Firewall.Bzgl. des Servers ist mir eines nicht ganz klar:
Hängt der mit dem "nackten Ar***" im WWW, weil ihr eine Portweiterleitung auf 80 & 443 aktiv habt oder ist da noch ein ReverseProxy vorgesschaltet?
.Im ersten Fall: ich würde mal sämtliche Logs verifizieren. Nicht, dass eure Kiste gekapert wurde.
auch mal ein
auch mal ein
route Print laufen lassen und prüfen, ob da nicht irgendwelche Einträge verbogen sind.Die Logs habe ich gestern vom externen Anbieter überprüfen lassen, in denen wir dann eben auch gesehen haben, dass Anfragen vom ServerLAN, von Extern und vom VPN Netz reinkommen aber keine Anfragen aus dem ClientLAN.
Ich selbst habe leider keinen Zugriff auf die Datenbank Logs, aber servertechnisch alles rein und es wirkt "fehlerfrei" auf ersten, zweiten und dritten Blick
LG,
Dann nimm dir die Checkpoint vor.
Kenne die Kiste selbst nicht, aber die hat doch bestimmt auch einen LiveMonitor oder so etwas.
Kenne die Kiste selbst nicht, aber die hat doch bestimmt auch einen LiveMonitor oder so etwas.
Mach mal einen TCPDUMP auf der Firewall selbst bzw dem Gerät, das das Routing zwischen den zwei VLANs übernimmt. Rein kommen müsste das ICMP Paket noch, geht es auch auf der richtigen Schnittstelle raus? Wenn nicht, weisst du, dass Client und Server nicht schuld sind.
die am gleichen Host angelegt sind funktioniert kann man das ausschließen oder?
Ja, kann man dann wohl sicher ausschliessen.Hilfreich wäre auch mal ein Ping vom Server direkt auf sein VLAN IP Gateway und die VLAN IP Gateway IP des Client Netzes ob das überhaupt erreichbar ist.
Sofern es keine ACLs auf dem Layer 3 VLAN Switch gibt und die IP Adressierung des Servers wasserdicht geprüft wurde kann es nur noch an den Firewall Regeln selber liegen.
Das betrifft dann sowohl die externe Firewall zwischen den IP VLAN Segmenten als auch die interne Server Firewall sofern aktiviert.
Da solltest du also einmal anfangen zu suchen...
Du kannst die externe Firewall ganz einfach mal checken indem du die inbound Regeln des Server VLAN Segments testweise einmal deaktivierst bzw. any any erlaubst. Klappt dann alles, hast du den bösen Buhmann gefunden.
Ohne also dein FW Regelwerk ganz genau zu kennen ist das hier alles Shooting in the dark und somit sinnfreie Raterei mit Blick in die Kristallkugel !! Das weisst du auch selber....
Man könnte, ja einfach auf der Firewall prüfen, was für Daten über die Leitung gehen.
Hi,
hast du mal die Firewall Einstellungen auf dem Server selber geprüft ?
Vielleicht ist die Zone geändert worden.
CH
hast du mal die Firewall Einstellungen auf dem Server selber geprüft ?
Vielleicht ist die Zone geändert worden.
CH
Vielen Dank für eure zahlreichen Antworten!
Ich bin jetzt nochmal jede Instanz durchgegangen und es war ein definitives Routing Problem auf dem Switch der nach der FW kam. Dies wurde jetzt von einem externen Dienstleister behoben. Daher habe ich da leider keine näheren Lösungsinfos die ich euch mitteilen könnte..
Trotzdem danke für die Hilfe Leute!
LG,
Ich bin jetzt nochmal jede Instanz durchgegangen und es war ein definitives Routing Problem auf dem Switch der nach der FW kam. Dies wurde jetzt von einem externen Dienstleister behoben. Daher habe ich da leider keine näheren Lösungsinfos die ich euch mitteilen könnte..
Trotzdem danke für die Hilfe Leute!
LG,
Zitat von @ITghost:
Vielen Dank für eure zahlreichen Antworten!
Ich bin jetzt nochmal jede Instanz durchgegangen und es war ein definitives Routing Problem auf dem Switch der nach der FW kam.
Vielen Dank für eure zahlreichen Antworten!
Ich bin jetzt nochmal jede Instanz durchgegangen und es war ein definitives Routing Problem auf dem Switch der nach der FW kam.
Wie ich schon oben sagte: Der Teufel hätt ein jedem Teil auf dem Weg vom Client zum Server stecken können. Das Problem ist in solchen Fällen oft, wenn für die untertschiedlichen Komponenten unterschiedliche Leute zuständig sind, die sich dann koordinieren müssen, um zu debuggen.
lks
1
