13
Verbindung zum Linux Server nicht möglich
Hallo zusammen,
habe gerade ein sonderbares Problem auf dessen Lösung ich gerade nicht komme. Wir haben hier seit einigen Jahren einen Nextcloud Server in einer extra isolierten Zone laufen. Rein Debian 9.x mit einer alten NC-Version. Ruft man NC im Browser vom LAN aus auf, so erscheint der Login. So weit, so gut. Nun habe ich gestern einen Außenstandort per VPN angeschlossen. Anforderung ist, dass der Standort ebenfalls NC nutzen kann. Versuche ich von dort eine Verbindung aufzubauen, dann verschwinden alle Anfragen ins Nirvana. Eine Regel, die den Zugriff erlaubt, habe ich in Iptables bereits hinterlegt. Ein benachbarter Server des NC (gleiche Zone) lässt sich problemlos erreichen.
Nun dachte ich zuerst, dass die Anfragen nicht richtig geroutet werden. Die Verfolgung sagt mir aber, dass von der FW am Standort die Pakete ins VPN gesteckt werden. Die FW hier am Hauptstandort bestätigt das. Auf dem Server sehe ich sogar mit pktstat die eintreffende Anfrage. Ein tcpdump -n -i eno1 bestätigt mir das auch noch mal. So, und jetzt habe ich sogar einen Verbindungsversuch mit ncat hinter mir. Auch hier sehe ich den ankommenden Verbindungsversuch, aber dann passiert nichts mehr. Iptables-Tabelle ist jetzt sogar leer. Daran liegt es also nicht.
Und /etc/hosts.allow bzw. hosts.deny ist nichts hinterlegt. Gerade habe ich keine weitere Idee woran es hängen könnte. Jemand noch eine Idee?
Danke und Gruß
Neue Erkenntnis:
Verbindungen aus dem gleichen Netzwerksegment funktionieren. Ich kann also von einem Testclient, der zum Test dort eingebracht ist den Server anpingen. Auch netcat geht. Aus dem LAN heraus geht es auch. Aber nicht, wenn die Verbindung vom VPN kommt.
habe gerade ein sonderbares Problem auf dessen Lösung ich gerade nicht komme. Wir haben hier seit einigen Jahren einen Nextcloud Server in einer extra isolierten Zone laufen. Rein Debian 9.x mit einer alten NC-Version. Ruft man NC im Browser vom LAN aus auf, so erscheint der Login. So weit, so gut. Nun habe ich gestern einen Außenstandort per VPN angeschlossen. Anforderung ist, dass der Standort ebenfalls NC nutzen kann. Versuche ich von dort eine Verbindung aufzubauen, dann verschwinden alle Anfragen ins Nirvana. Eine Regel, die den Zugriff erlaubt, habe ich in Iptables bereits hinterlegt. Ein benachbarter Server des NC (gleiche Zone) lässt sich problemlos erreichen.
Nun dachte ich zuerst, dass die Anfragen nicht richtig geroutet werden. Die Verfolgung sagt mir aber, dass von der FW am Standort die Pakete ins VPN gesteckt werden. Die FW hier am Hauptstandort bestätigt das. Auf dem Server sehe ich sogar mit pktstat die eintreffende Anfrage. Ein tcpdump -n -i eno1 bestätigt mir das auch noch mal. So, und jetzt habe ich sogar einen Verbindungsversuch mit ncat hinter mir. Auch hier sehe ich den ankommenden Verbindungsversuch, aber dann passiert nichts mehr. Iptables-Tabelle ist jetzt sogar leer. Daran liegt es also nicht.
Und /etc/hosts.allow bzw. hosts.deny ist nichts hinterlegt. Gerade habe ich keine weitere Idee woran es hängen könnte. Jemand noch eine Idee?
Danke und Gruß
Neue Erkenntnis:
Verbindungen aus dem gleichen Netzwerksegment funktionieren. Ich kann also von einem Testclient, der zum Test dort eingebracht ist den Server anpingen. Auch netcat geht. Aus dem LAN heraus geht es auch. Aber nicht, wenn die Verbindung vom VPN kommt.
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: 594465
Url: https://administrator.de/contentid/594465
Ausgedruckt am: 23.11.2024 um 12:11 Uhr
13 Kommentare
Neuester Kommentar
Hi,
ins Blaue geraten: Kennt der Server die Rück-Route?
E.
ins Blaue geraten: Kennt der Server die Rück-Route?
E.
1
Ah, habe ich vergessen reinzuschreiben. Ein Ping vom Server aus zum Client am Außenstandort ist problemlos möglich. Ich habe das Gefühl als wäre am Server selbst irgendwas konfiguriert, was Antworten verhindert, wenn sie nicht aus dem LAN kommen.
Hallo,
bei Owncloud konfiguriert man ein Array mit Hostnamen, über die man den Server anspricht. Vielleicht ist das bei NC auch so und Du nutzt einen anderen Hostnamen (oder Direktaufruf über IP-Adresse), der aber noch nicht in der Liste geführt ist?
In dem Fall gibt es aber "eigentlich" auch eine eindeutige Meldung
Gruß,
Jörg
bei Owncloud konfiguriert man ein Array mit Hostnamen, über die man den Server anspricht. Vielleicht ist das bei NC auch so und Du nutzt einen anderen Hostnamen (oder Direktaufruf über IP-Adresse), der aber noch nicht in der Liste geführt ist?
In dem Fall gibt es aber "eigentlich" auch eine eindeutige Meldung
Gruß,
Jörg
1
Danke, aber das schließe ich aus, denn, wie du sagst, gibt es eine Meldung, die besagt, dass er für die Adresse/Name XXXX konfiguriert ist. Ich schließe es aber auch deswegen aus, weil ich mit ncat keine Verbindung hinbekomme. Auch steht in den Apachelogs nichts.
Moin,
Nextcloud meldet sich bei nicht autorisierter Adresse selbst und bitte diese dicht m durch den Admin hinzu zu fügen. Daher sollte es daran nicht scheitern. Es sei denn davor läuft noch ein Reverseproxy welche dahin gehend filtert.
Das heißt pingen kannst du den Server?
Gruß
Spirit
Nextcloud meldet sich bei nicht autorisierter Adresse selbst und bitte diese dicht m durch den Admin hinzu zu fügen. Daher sollte es daran nicht scheitern. Es sei denn davor läuft noch ein Reverseproxy welche dahin gehend filtert.
Das heißt pingen kannst du den Server?
Gruß
Spirit
1
Leider auch nicht. Der Server kann pingen, aber nicht angepingt werden.
Wie ist denn die Uptime des Servers? Nicht umsonst heißt es "reboot tut gut!"
lks
PS: iptables sollte zumindest eine default regel (deny oder allow) haben und nicht leer sein.
1
Neue Erkenntnis:
Verbindungen aus dem gleichen Netzwerksegment funktionieren. Ich kann also von einem Testclient, der zum Test dort eingebracht ist den Server anpingen. Auch netcat geht. Aus dem LAN heraus geht es auch. Aber nicht, wenn die Verbindung vom VPN kommt.
Verbindungen aus dem gleichen Netzwerksegment funktionieren. Ich kann also von einem Testclient, der zum Test dort eingebracht ist den Server anpingen. Auch netcat geht. Aus dem LAN heraus geht es auch. Aber nicht, wenn die Verbindung vom VPN kommt.
Zitat von @it-fraggle:
Neue Erkenntnis:
Verbindungen aus dem gleichen Netzwerksegment funktionieren. Ich kann also von einem Testclient, der zum Test dort eingebracht ist den Server anpingen. Auch netcat geht. Aus dem LAN heraus geht es auch. Aber nicht, wenn die Verbindung vom VPN kommt.
Neue Erkenntnis:
Verbindungen aus dem gleichen Netzwerksegment funktionieren. Ich kann also von einem Testclient, der zum Test dort eingebracht ist den Server anpingen. Auch netcat geht. Aus dem LAN heraus geht es auch. Aber nicht, wenn die Verbindung vom VPN kommt.
Dann prüf mal, was die (SYN-)Pakete aus dem VPN von denen unterscheidet, die aus dem gleichen Netzsegment kommen.
lks
1
Moin,
blöde Frage:
In der Firewall sind alle Verbindungen vom VPN-Netz zum Servernetz erlaubt?
Viele Grüße
blöde Frage:
In der Firewall sind alle Verbindungen vom VPN-Netz zum Servernetz erlaubt?
Viele Grüße
1
Ja, sind erlaubt. Es endet am Server und dort passiert nichts. Weder ncat noch Aufrufe (Apache) der Website funktionieren. Am Server kommt es an, aber er reagiert nicht.
Ich habe so den Verdacht, dass dein Server doch eine andere Route für den Rückweg nutzt als die anderen Server.
Das kannst du mit "ip route get <ipadresse>" nachprüfen und vergleichen.
Wenn die Antworten über ein falsches Interface gesendet werden, könnten diese dort an Firewalls versanden oder z.B. durch NAT auf eine falsche IP-Adresse übersetzt werden.
Mach vom Server auch mal einen Traceroute (mal mit ICMP und mal mit TCP-Source-Port 80 / 443 - dafür musst du den Apache kurz stoppen) zu dem Client von dem aus du den Zugriff testest. Nicht, dass der vorgelagerte Router aufgrund irgendwelcher PBR-Regeln den HTTP-Traffic woandersher leiten will und damit die Route bricht.
Das kannst du mit "ip route get <ipadresse>" nachprüfen und vergleichen.
Wenn die Antworten über ein falsches Interface gesendet werden, könnten diese dort an Firewalls versanden oder z.B. durch NAT auf eine falsche IP-Adresse übersetzt werden.
Mach vom Server auch mal einen Traceroute (mal mit ICMP und mal mit TCP-Source-Port 80 / 443 - dafür musst du den Apache kurz stoppen) zu dem Client von dem aus du den Zugriff testest. Nicht, dass der vorgelagerte Router aufgrund irgendwelcher PBR-Regeln den HTTP-Traffic woandersher leiten will und damit die Route bricht.
1
ip route get <ipadresse> zeigte mir eine falsche Rückroute. Jetzt läuft es. Vielen Dank an alle für die Mühe, Tips und Hinweise. Jetzt kann ich Feierabend machen
