UCS nicht über VPN?

german

#1

Hallo zusammen,

ich komme überhaupt nicht weiter. Ein UCS 4.1 arbeitet am Standort 1 als Master und ist über VPN an einen zweiten Standort angeschlossen. Von dort komme ich aber nicht an den Server heran. Besser gesagt, ich kann ihn über SSH ansprechen, gebe Passwort ein und kann mir das Directory Listing anzeigen lassen. Offenbar hängt sich die Verbindung zum Server aber nach einigen 100 Bytes auf. Bei ps ax sieht es z. B. so aus:

root@dcm:~# ps ax PID TTY STAT TIME COMMAND 1 ? Ss 0:02 init [2] 2 ? S 0:00 [kthreadd] 3 ? S 0:00 [ksoftirqd/0] 4 ? S 0:00 [kworker/0:0] 5 ? S< 0:00 [kworker/0:0H] 7 ? S 0:09 [rcu_sched] 8 ? S 0:00 [rcu_bh] 9 ? S 0:00 [migration/0] 10 ? S 0:00 [watchdog/0]

danach geht nichts mehr. Eine neue ssh-Verbindung kann ich aber öffnen. Http geht gar nicht, vermutlich wg. zu viel Traffic.

Das VPN schließe ich eigentlich als Fehlerursache aus, denn andere Devices kann ich problemlos, auch über http: ansprechen. Habe auch schon die IP-Adressen gewechselt, z. B. auf eine, mit der ich zuvor ein Webinterface eines Druckers ansprechen konnte (habe den Drucker natürlich temporär anders eingestellt). Bin ich im lokalen Netz, habe ich keine Probleme. So kann ich das Webinterface z. B. über einen Rechner mit Teamviewer erreichen, nicht aber über das VPN.

Das Gateway ist auch richtig eingetragen,

Kernel-IP-Routentabelle Ziel Router Genmask Flags Metric Ref Use Iface default 192.168.100.254 0.0.0.0 UG 0 0 0 eth0 172.17.0.0 * 255.255.0.0 U 0 0 0 docker0 192.168.100.0 * 255.255.255.0 U 0 0 0 eth0

ich kann den Server über das VPN anpingen und ein Portscan zeigt auch den offenen http: Port über das VPN.

Jetzt weiß ich echt nicht weiter. Man könnte meinen, das VPN verschluckt sich an den Ausgaben vom Server, aber das sollte doch eigentlich kein Thema sein.

Hat jemand schon mal so etwas beobachtet oder eine Idee, wo ich weitersuchen könnte ?

Bin für jeden Hinweis dankbar

Martin


#2

Hallo Martin,

[quote=“mschlee”]Ein UCS 4.1 arbeitet am Standort 1 als Master und ist über VPN an einen zweiten Standort angeschlossen…
Jetzt weiß ich echt nicht weiter. Man könnte meinen, das VPN verschluckt sich an den Ausgaben vom Server, aber das sollte doch eigentlich kein Thema sein.

Hat jemand schon mal so etwas beobachtet oder eine Idee, wo ich weitersuchen könnte ?

Bin für jeden Hinweis dankbar

Martin[/quote]

Bist Du sicher das Dein VPN ok ist? Die beschriebenen Probleme klingen für mich nach einem MTU Problem des VPN. Bitte teste Deine MTU-Einstellungen und passe diese ggf. für das VPN an.

Windows-Test: strongvpn.com/mtu_ping_test.html
Linux-Test: michael.stapelberg.de/Artikel/mtu_openvpn

Gruß Lutz Willek


#3

Hallo Lutz,

ich werde das prüfen. Allerdings merkwürdig ist, dass umgekehrt der Slave-Server am 2. Standort vom 1. Standort aus problemlos erreicht werden kann. Also je ein UCS an Standort A und B, die per VPN verbunden sind. Bei A kann mann Server B ansprechen, aber umgekehrt geht es nicht.

Kann das sein ?

Gruß
Martin


#4

Hallo zusammen, habe jetzt auf Server A (der von B nicht erreichbar ist), den Server B mit einer MTU von 1472 angepingt:

root@dcm:~# ping -M do -s 1472 192.168.22.1 PING 192.168.22.1 (192.168.22.1) 1472(1500) bytes of data. ping: local error: Message too long, mtu=1444 ping: local error: Message too long, mtu=1444 ping: local error: Message too long, mtu=1444 ping: local error: Message too long, mtu=1444 ping: local error: Message too long, mtu=1444

Pinge ich auf Server B den Server A genauso an, gibt es wohl kein Problem:

root@dcs1:~# ping -M do -s 1472 192.168.100.6 PING 192.168.100.6 (192.168.100.6) 1472(1500) bytes of data. 1480 bytes from 192.168.100.6: icmp_req=1 ttl=63 time=50.4 ms 1480 bytes from 192.168.100.6: icmp_req=2 ttl=63 time=48.8 ms 1480 bytes from 192.168.100.6: icmp_req=3 ttl=63 time=51.4 ms 1480 bytes from 192.168.100.6: icmp_req=4 ttl=63 time=50.2 ms 1480 bytes from 192.168.100.6: icmp_req=5 ttl=63 time=48.7 ms

Wenn ich auf Server A den Server B mit einer MTU von 1376 anpinge, funktioniert es schließlich:

root@dcm:~# ping -M do -s 1376 192.168.22.1
PING 192.168.22.1 (192.168.22.1) 1376(1404) bytes of data.
1384 bytes from 192.168.22.1: icmp_req=1 ttl=63 time=49.5 ms
1384 bytes from 192.168.22.1: icmp_req=2 ttl=63 time=47.9 ms
1384 bytes from 192.168.22.1: icmp_req=3 ttl=63 time=51.0 ms
1384 bytes from 192.168.22.1: icmp_req=4 ttl=63 time=50.1 ms

Wenn ich das richtig verstanden habe, sollte ich jetzt die MTU von Server A von 1500 auf 1384 herabsetzen. Ist das richtig ? Wenn ja, mache ich das direkt in /etc/network/interfaces, oder kann ich etwas über UCM machen ?

Danke für Eure Antworten

Gruß
Martin


#5

Unabhängig vom konkreten Problem ist meiner Erfahrung nach die MTU des Internetzugangs über den das VPN läuft ausschlaggebend, so, dass die VPN-Pakete nicht fragmentiert werden. Ich gehe einfach davon aus, dass in dem Setup zwei Firewalls/Router das VPN machen die Server dahinter sind. Ich hatte das mehr als ein mal, dass die MTU des Internetzuggans VPNs so negativ beeinflusst hat, dass kleine Pakete kein Problem hatten und die Kommunikation bei grösseren Datenmengen nicht mehr funktioniert hat.


#6

Hm, das mag sein. Und was mache ich jetzt am besten ? So kann ich den Slave ja nicht joinen …

Gruß
Martin


#7

Okay, ich habe nun einfach in /etc/network/interfaces herumeditiert und eine MTU von 1400 eingestellt. Das hat es gebracht ;-). Der Slave ließ sich joinen. Wie ich die Änderung der MTU permanent mache, weiß ich aber noch nicht. MTU für eth0 unter UCS 4.1 einstellen - wie?

Vielen Dank für den Tipp, Lutz.

Martin