Remote Zugriff zweier Debian server wechselseitig nicht möglich, von anderen jedoch schon
Hallo,
hab ein seltsames Problem, das ich nicht wirklich zuordnen kann. Seit 2 Tagen kann Server A nicht mehr auf die mysql DB von Server B, welche als Remote DB für diverse Server dient, zugreifen. Alle anderen Server können jedoch auf die mysql DB von Server B zugreifen.
Hab mir das ganze daher genauer angeschaut und es scheint eigentlich so, dass jedweder Zugriff von Server A auf Server B blockiert wird, also z.B. auch Telnet oder Traceroute o.ä. (all diese Zugriffe sind jedoch von allen anderen Servern, die auch den Server B als remote DB Server verwenden, ebenso möglich). Jetzt dachte ich mir dass vielleicht iptables o.ä. auf dem Server B läuft, tut es aber nicht. Noch schräger daran ist jedoch, dass auch wenn ich von Server B auf Server A konnekten will (mit welcher methodik auch immer) auch dort ein Timeout erfolgt und Traceroute quasi unmittelbar vor Server A in timeout geht.
Soll heißen es scheint so als würde jedweder Konnex von Server A auf Server B unmittelbar vor dem Server B unterbrochen, jedoch ebenso umgekehrt unmittelbar vor Server A.
Kann sich das jemand erklären?
hab ein seltsames Problem, das ich nicht wirklich zuordnen kann. Seit 2 Tagen kann Server A nicht mehr auf die mysql DB von Server B, welche als Remote DB für diverse Server dient, zugreifen. Alle anderen Server können jedoch auf die mysql DB von Server B zugreifen.
Hab mir das ganze daher genauer angeschaut und es scheint eigentlich so, dass jedweder Zugriff von Server A auf Server B blockiert wird, also z.B. auch Telnet oder Traceroute o.ä. (all diese Zugriffe sind jedoch von allen anderen Servern, die auch den Server B als remote DB Server verwenden, ebenso möglich). Jetzt dachte ich mir dass vielleicht iptables o.ä. auf dem Server B läuft, tut es aber nicht. Noch schräger daran ist jedoch, dass auch wenn ich von Server B auf Server A konnekten will (mit welcher methodik auch immer) auch dort ein Timeout erfolgt und Traceroute quasi unmittelbar vor Server A in timeout geht.
Soll heißen es scheint so als würde jedweder Konnex von Server A auf Server B unmittelbar vor dem Server B unterbrochen, jedoch ebenso umgekehrt unmittelbar vor Server A.
Kann sich das jemand erklären?
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 264936
Url: https://administrator.de/forum/remote-zugriff-zweier-debian-server-wechselseitig-nicht-moeglich-von-anderen-jedoch-schon-264936.html
Ausgedruckt am: 25.04.2025 um 08:04 Uhr
10 Kommentare
Neuester Kommentar
Zitat von @prione:
Soll heißen es scheint so als würde jedweder Konnex von Server A auf Server B unmittelbar vor dem Server B
unterbrochen, jedoch ebenso umgekehrt unmittelbar vor Server A.
Kann sich das jemand erklären?
Soll heißen es scheint so als würde jedweder Konnex von Server A auf Server B unmittelbar vor dem Server B
unterbrochen, jedoch ebenso umgekehrt unmittelbar vor Server A.
Kann sich das jemand erklären?
moin,
Da kann es viele Gründe geben:
- Wie weit stehen die Serve auseinander (in hops)?
- Sind das reguläre Router oder Firewalls, die "vor" den Servern stehen.
- Ist da ggf ein VPN daziwschen?
- Sind die Netze disjunkt?
- Was sagt tcpdump/wireshark?
- usw.
lks
PS: Hast Du z.B. fail2ban o.ä laufen?
Hallo,
danke für dein Feedback. Bin leider nicht so bewandert in Server administration. Ich versuche bestmöglich zu beantworten.
1) 14 hops (sprich andere DCs)
2) ja
3) nein, zumindest nicht dass ich wüßte
4) weiß leider nicht genau was du meinst. Falls gemeint ist, ob die Server in unterschiedlichen DCs/Netzwerken stehen: ja. Aber sind beide wie gesagt von diversen anderen Servern, die auch alle nochmal in anderen DCs/Netzwerken stehen voll konnektierbar, nur die zwei scheinen untereinander irgendein problem miteinander zu haben.
5) Könntest mir da bitte die Syntax sagen, die ich eingeben sollte um ne sinnvolle antwort zu halten?
danke für dein Feedback. Bin leider nicht so bewandert in Server administration. Ich versuche bestmöglich zu beantworten.
1) 14 hops (sprich andere DCs)
2) ja
3) nein, zumindest nicht dass ich wüßte
4) weiß leider nicht genau was du meinst. Falls gemeint ist, ob die Server in unterschiedlichen DCs/Netzwerken stehen: ja. Aber sind beide wie gesagt von diversen anderen Servern, die auch alle nochmal in anderen DCs/Netzwerken stehen voll konnektierbar, nur die zwei scheinen untereinander irgendein problem miteinander zu haben.
5) Könntest mir da bitte die Syntax sagen, die ich eingeben sollte um ne sinnvolle antwort zu halten?
Bin leider nicht so bewandert in Server administration.
Oha, keine gute Voraussetzung 
Hast du ggf. jemand an der hand der da weiss was er tut ?Falls gemeint ist, ob die Server in unterschiedlichen DCs/Netzwerken stehen: ja.
Das ist vermutlich der Knackpunkt, das die beiden Servernetze sich nicht sehen sprich deren Routing nicht klappt.Du solltes mal ein gegenseitiges traceroute <server_ip> -n machen um zu sehen wie die Routing Hops dazwischen aussehen.
Wenn das irgendwo abbricht ist da das (Routing) Problem der beiden IP Netze !
traceroute <server_ip> -n
-> hab ich zuvor schon gemacht -> bricht immer unmittelbar vor dem Server ab... sprich 13 HOPS funktionieren jedoch der letzte dann nie... und das in beide Richtungen gleich...
-> hab ich zuvor schon gemacht -> bricht immer unmittelbar vor dem Server ab... sprich 13 HOPS funktionieren jedoch der letzte dann nie... und das in beide Richtungen gleich...
Zitat von @prione:
traceroute <server_ip> -n
-> hab ich zuvor schon gemacht -> bricht immer unmittelbar vor dem Server ab... sprich 13 HOPS funktionieren jedoch der
letzte dann nie... und das in beide Richtungen gleich...
traceroute <server_ip> -n
-> hab ich zuvor schon gemacht -> bricht immer unmittelbar vor dem Server ab... sprich 13 HOPS funktionieren jedoch der
letzte dann nie... und das in beide Richtungen gleich...
- Wie sind die TTL's?
- Wie sind die IP-Adressen?
- Sind die netze wirklich disjunkt?
- Was sagt tcpdump -i eth0 -X host ip.von.anderem.server während Du einen Verbiindungsversuch vom andren Serevr aus machst?
lks
sprich 13 HOPS funktionieren jedoch der letzte dann nie...
Dann hast du am 13ten Routerhop ja ein Problem !! DA solltest du also mal suchen 
yep aber das paradoxe ist, wenn ich von Server A auf B zugreife hab ich ein problem am 13. Spot, aber andersrum hab ich nicht etwa ein Problem am 2. Spot, sondern auch wieder am 13....
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel
Zitat von @prione:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel
Es kommt offensichtlich nichts an. Dann schau die mal die jeweilige Kiste direkt "vorndedran" an.
lks
PS. Kristallkugel sagt, IP-Netzkonflikt, Routing-Problem. oder TTL zu klein.
Auf die Kiste "vornedran" komme ich nicht hin, da der Server ja in einem DC liegt... es scheint jedoch in dem DC prinzipiell netzwerkprobleme zu geben... mal sehen vielleicht ist das die Ursache... warte mal bis die bereinigt sind, vielleicht löst sich dann das Prob von selbst
