VM aus dem Internet aufrufen

UCS - Univention Corporate Server
,
#1

Guten Morgen,

ich habe folgende Infrastruktur aufgebaut:

Router (192.168.178.1) <=> UCS Server mit KMV und Joomla (192.168.178.10) <=> VM Gitlab (192.168.178.11)

Im Router habe ich eine Portweiterleitung von 8080 auf 80 für den Joomla-Server eingestellt, was auch funktioniert. Unsere Webseite ist über das I-Net erreichbar.

Dann habe ich im Router eine Portweiterleitung von 8180 auf 80 auf die VM eingerichtet. Innerhalb des Netzwerks ist der Git-Server erreichtbar (dyndns.org:8180). Wenn ich mich verbinden will, dann dauert es eine Weile bis die Seite aufgebaut wird. Und das ist dann aber nicht der Git-Server (die VM) sondern der Joomla

Was ich schon herausgefunden habe ist, dass es irgendwas mit dem Bridging oder so zu tun haben kann. Vielleicht kann mir da jemand auf die Sprünge helfen, damit ich von Außerhalb auf meine Repositories im GitLab zugreifen kann.

#2

Moin,

wenn Sie über die interne IP des Servers von einem anderen Rechner im selben Netz aus zugreifen können, dann funktioniert das Bridging.

Ich tippe eher auf andere Probleme. Lassen Sie bitte mal auf dem VM-Host (also der .10) folgendes laufen: »tcpdump -n -i any host 192.168.178.11 and port 80«. Dann rufen Sie whatever.dyndns.org:8180 auf und schauen Sie, was tcpdump so ausspuckt. Pasten Sie die tcpdump-Ausgabe dann hier, damit wir uns ein Bild davon machen können, was passiert.

Gruß,
mosu

#3

Hallo,

hier meine Antwort:

~# tcpdump -n -i any host 192.168.178.11 and port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes

Beim Aufruf der Webseite kommt leider nichts durch. Beim internen Aufruf, kommt die korrekte Anfrage

#4

Moin,

wenn Sie dort gar nichts zu sehen bekommen, dann liegt das Problem eventuell bereits auf Seitens des Routers. Sie können aber bitte auch noch mal schauen, ob der Router überhaupt versucht, die 192.168.178.11 in eine MAC-Adresse aufzulösen. Dazu tcpdump wie folgt ausführen:

tcpdump -n -i any host 192.168.178.11 and arp

Auf einem KVM-Host sieht man bei diesem tcpdump definitiv, wenn ein Host im Netzwerk anfragt, welche MAC zu der IP gehört; das habe ich eben hier noch mal verifiziert.

Gruß,
mosu

#5

Anscheinend hat meine Fritzbox das ganze blockiert. Das ARP gab nichts zurück. Erst als ich in der PortWieterleitung einen anderen Namen vergeben habe, wurde das APR ausgeführt.

Hier nun das Ergebiss zu “… and port 80”

15:11:50.864671 IP 95.208.159.55.9354 > 192.168.178.11.80: Flags [S], seq 2664803724, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0 15:11:50.864689 IP 95.208.159.55.9354 > 192.168.178.11.80: Flags [S], seq 2664803724, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0 15:11:50.865110 IP 192.168.178.11.80 > 95.208.159.55.9354: Flags [S.], seq 312899077, ack 2664803725, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 15:11:50.865129 IP 192.168.178.11.80 > 95.208.159.55.9354: Flags [S.], seq 312899077, ack 2664803725, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 15:11:50.866822 IP 95.208.159.55.9354 > 192.168.178.11.80: Flags [.], ack 1, win 16425, length 0 15:11:50.866835 IP 95.208.159.55.9354 > 192.168.178.11.80: Flags [.], ack 1, win 16425, length 0 15:11:50.947011 IP 95.208.159.55.9354 > 192.168.178.11.80: Flags [P.], seq 1:418, ack 1, win 16425, length 417 15:11:50.947027 IP 95.208.159.55.9354 > 192.168.178.11.80: Flags [P.], seq 1:418, ack 1, win 16425, length 417 15:11:50.947736 IP 192.168.178.11.80 > 95.208.159.55.9354: Flags [.], ack 418, win 237, length 0 15:11:50.947754 IP 192.168.178.11.80 > 95.208.159.55.9354: Flags [.], ack 418, win 237, length 0 15:11:50.968255 IP 192.168.178.11.80 > 95.208.159.55.9354: Flags [P.], seq 1:752, ack 418, win 237, length 751 15:11:50.968290 IP 192.168.178.11.80 > 95.208.159.55.9354: Flags [P.], seq 1:752, ack 418, win 237, length 751 15:11:50.969647 IP 192.168.178.11.80 > 95.208.159.55.9354: Flags [P.], seq 752:757, ack 418, win 237, length 5 15:11:50.969672 IP 192.168.178.11.80 > 95.208.159.55.9354: Flags [P.], seq 752:757, ack 418, win 237, length 5 15:11:50.970043 IP 95.208.159.55.9354 > 192.168.178.11.80: Flags [.], ack 757, win 16236, length 0 15:11:50.970057 IP 95.208.159.55.9354 > 192.168.178.11.80: Flags [.], ack 757, win 16236, length 0

Leider wird immer noch nicht die GITlab Seite angezeigt

#6

Moin,

well… der Dump sieht erst mal relativ normal aus. Verbindungsaufbau klappt, dann stellt der Client gleich eine Anfrage, Server schickt zwei Antwortpakete, die vom Client auch quittiert werden. Die Verbindung bleibt aber offen.

Es könnte sich um ein MTU-Problem handeln. Zeigen Sie bitte mal die Ausgabe von »ip link show« von sowohl dem VM-Host als auch der virtuellen Maschine.

Anschließend setzen Sie die MTU auf der VM mal bewusst herunter, z.B. mit »ip link set mtu 1450 dev eth0« (»eth0« durch den Namen des Interfaces in der VM ersetzen, falls das nicht »eth0« ist), und probieren Sie den Zugriff erneut.

Gruß,
mosu

#7

Hier die Ergebnisse für die Abfragen:

Host

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP mode DEFAULT qlen 1000 link/ether 74:d4:35:ef:85:56 brd ff:ff:ff:ff:ff:ff 3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT qlen 1000 link/ether 74:d4:35:ef:85:54 brd ff:ff:ff:ff:ff:ff 4: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT link/ether 74:d4:35:ef:85:56 brd ff:ff:ff:ff:ff:ff 5: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UNKNOWN mode DEFAULT qlen 500 link/ether fe:54:00:8e:74:61 brd ff:ff:ff:ff:ff:ff 6: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT link/ether de:72:62:c8:68:20 brd ff:ff:ff:ff:ff:ff

VM

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:8e:74:61 brd ff:ff:ff:ff:ff:ff

Auch nach dem Heruntersetzen der MTU, kann ich trotdem immer noch nicht drauf zugreifen.

Hier ein tcpdump von der VM, mit Zugriff aus dem lokalen Netz

2016-10-12 03:27:17.764173 IP 192.168.178.163.6250 > 192.168.178.11.80: Flags [S], seq 2898601153, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0 2016-10-12 03:27:17.764253 IP 192.168.178.11.80 > 192.168.178.163.6250: Flags [S.], seq 1113858826, ack 2898601154, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 2016-10-12 03:27:17.764660 IP 192.168.178.163.6250 > 192.168.178.11.80: Flags [.], ack 1, win 16425, length 0 2016-10-12 03:27:17.766783 IP 192.168.178.163.6250 > 192.168.178.11.80: Flags [P.], seq 1:396, ack 1, win 16425, length 395 2016-10-12 03:27:17.766868 IP 192.168.178.11.80 > 192.168.178.163.6250: Flags [.], ack 396, win 237, length 0 2016-10-12 03:27:18.928146 IP 192.168.178.11.80 > 192.168.178.163.6250: Flags [.], seq 1:1461, ack 396, win 237, length 1460 2016-10-12 03:27:18.928395 IP 192.168.178.11.80 > 192.168.178.163.6250: Flags [P.], seq 1461:2636, ack 396, win 237, length 1175 2016-10-12 03:27:18.928930 IP 192.168.178.163.6250 > 192.168.178.11.80: Flags [.], ack 2636, win 16425, length 0 2016-10-12 03:27:23.933814 IP 192.168.178.11.80 > 192.168.178.163.6250: Flags [F.], seq 2636, ack 396, win 237, length 0 2016-10-12 03:27:23.934686 IP 192.168.178.163.6250 > 192.168.178.11.80: Flags [.], ack 2637, win 16425, length 0 2016-10-12 03:27:23.935164 IP 192.168.178.163.6250 > 192.168.178.11.80: Flags [F.], seq 396, ack 2637, win 16425, length 0 2016-10-12 03:27:23.935196 IP 192.168.178.11.80 > 192.168.178.163.6250: Flags [.], ack 397, win 237, length 0

Hier der tcpdump von der VM bei Zugriff von außen

2016-10-12 03:28:12.588523 IP 95.208.159.55.6286 > 192.168.178.11.80: Flags [S], seq 4222305606, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0 2016-10-12 03:28:12.588611 IP 192.168.178.11.80 > 95.208.159.55.6286: Flags [S.], seq 2215227872, ack 4222305607, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 2016-10-12 03:28:12.590672 IP 95.208.159.55.6286 > 192.168.178.11.80: Flags [.], ack 1, win 16425, length 0 2016-10-12 03:28:12.682230 IP 95.208.159.55.6286 > 192.168.178.11.80: Flags [P.], seq 1:418, ack 1, win 16425, length 417 2016-10-12 03:28:12.682316 IP 192.168.178.11.80 > 95.208.159.55.6286: Flags [.], ack 418, win 237, length 0 2016-10-12 03:28:12.700915 IP 192.168.178.11.80 > 95.208.159.55.6286: Flags [P.], seq 1:752, ack 418, win 237, length 751 2016-10-12 03:28:12.702088 IP 192.168.178.11.80 > 95.208.159.55.6286: Flags [P.], seq 752:757, ack 418, win 237, length 5 2016-10-12 03:28:12.702516 IP 95.208.159.55.6286 > 192.168.178.11.80: Flags [.], ack 757, win 16236, length 0 2016-10-12 03:28:17.707596 IP 192.168.178.11.80 > 95.208.159.55.6286: Flags [F.], seq 757, ack 418, win 237, length 0 2016-10-12 03:28:17.709488 IP 95.208.159.55.6286 > 192.168.178.11.80: Flags [.], ack 758, win 16236, length 0 2016-10-12 03:28:17.710243 IP 95.208.159.55.6286 > 192.168.178.11.80: Flags [F.], seq 418, ack 758, win 16236, length 0 2016-10-12 03:28:17.710298 IP 192.168.178.11.80 > 95.208.159.55.6286: Flags [.], ack 419, win 237, length 0

#8

Moin,

die tcumpdump-Ausgaben zeigen eine komplette Verbindung von Anfang bis Ende. Da ist noch nichts Ungewöhnliches zu sehen.

Was genau sagen denn /var/log/apache2/access.log und error.log bei dem Zugriffsversuch?

Gruß,
mosu

Mastodon