[Docker] Webpage van container niet bereikbaar op andere PC - Linux en overige clients

zondag 18 november 2018 14:40

Acties:

0 Henk 'm!

(C) FutureCow

Topicstarter

Ik maak al maanden gebruiken van verschillende docker containers, maar sinds de update van vorige week (18.09) lukt het mij niet meer om buiten de server op een webpagina van een draaiende container te komen. Dit geld voor alle containers.

Bijvoorbeeld Sonarr:

code:

1	da62a813ed7c linuxserver/sonarr "/init" 4 months ago Up About an hour 0.0.0.0:8989->8989/tcp sonarr

netstat -tunlp | grep 8989:

code:

1	tcp6 0 0 :::8989 :::* LISTEN -

curl 127.0.0.1:8989:

code:

<!doctype html>
<html>
<head>
    <title>Sonarr</title>
    <meta name="viewport" content="width=device-width, initial-scale=1.0"/>
blablabla

IP van de sever is 192.168.1.2
curl 192.168.1.2:8989:

code:

1	curl: (7) Failed to connect to 192.168.1.2 port 8989: Connection refused

Dit laat curl zien bij alle gesloten porten.
Maar op een andere PC is port 8989 niet beschikbaar(portscan laat port ook niet zien). Alle andere processen op de server die niet in een container zitten (Webserver/sabnzbd etc) zijn wel gewoon bereikbaar. Het gaat dus specifiek over de processen die in een container zitten die niet bereikbaar zijn. Hoe kan ik dit debuggen?

zondag 18 november 2018 16:06

Acties:

0 Henk 'm!

Hero of Time

Moderator LNX

There is only one Legend

Wat draait er op versie 18.09? Enige OS die ik met dat versie/buildnummer kan bedenken is WIndows 10. En dat bespreken we hier niet. Kom dus even met volledige specificaties van je systeem. En denk ook even aan je firewall.

Commandline FTW | Tweakt met mate

zondag 18 november 2018 16:08

Acties:

0 Henk 'm!

Kees

Serveradmin / BOFH / DoC

Zijn docker versie is 18.09 neem ik aan.

En inderdaad, check even of bijvoorbeeld iptables je forwards niet DROP'ed by default (dat doet docker nog wel eens zelf instellen). En anders, restart de container met --net=host zodat je buiten iptables om kan. Dat is een workaround en niet perse een oplossing.

[ Voor 9% gewijzigd door Kees op 18-11-2018 16:09 ]

"Een serveradmin, voluit een serveradministrator, is dan weer een slavenbeheerder oftewel een slavendrijver" - Rataplan

zondag 18 november 2018 16:38

Acties:

0 Henk 'm!

SadisticPanda

Heet patatje :o

In je netstat staat er dat sonar luisterd op ipv6...en je probeert te verbinden met ipv4...

Voor localhost maakt dit niet uit denk ik, voor andere pcs wel denk ik

Marstek 5.12kw v151, CT003 v117, Sagecom Xs212 1P,

zondag 18 november 2018 17:41

Acties:

0 Henk 'm!

FutureCow

(C) FutureCow

Topicstarter

Hero of Time schreef op zondag 18 november 2018 @ 16:06:
Wat draait er op versie 18.09? Enige OS die ik met dat versie/buildnummer kan bedenken is WIndows 10. En dat bespreken we hier niet. Kom dus even met volledige specificaties van je systeem. En denk ook even aan je firewall.

Sorry, gaat om de versie van Docker. OS is Debian testing.

Kees schreef op zondag 18 november 2018 @ 16:08:
Zijn docker versie is 18.09 neem ik aan.

En inderdaad, check even of bijvoorbeeld iptables je forwards niet DROP'ed by default (dat doet docker nog wel eens zelf instellen). En anders, restart de container met --net=host zodat je buiten iptables om kan. Dat is een workaround en niet perse een oplossing.

sudo iptables -t nat -L -n:

code:

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
DOCKER     all  --  0.0.0.0/0            0.0.0.0/0            ADDRTYPE match dst-type LOCAL

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
MASQUERADE  all  --  172.21.0.0/16        0.0.0.0/0
MASQUERADE  all  --  172.17.0.0/16        0.0.0.0/0
MASQUERADE  tcp  --  172.21.0.2           172.21.0.2           tcp dpt:24224
MASQUERADE  udp  --  172.21.0.3           172.21.0.3           udp dpt:2055
MASQUERADE  tcp  --  172.21.0.5           172.21.0.5           tcp dpt:8447
MASQUERADE  tcp  --  172.21.0.5           172.21.0.5           tcp dpt:8446
MASQUERADE  tcp  --  172.17.0.3           172.17.0.3           tcp dpt:8989

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
DOCKER     all  --  0.0.0.0/0           !127.0.0.0/8          ADDRTYPE match dst-type LOCAL

Chain DOCKER (2 references)
target     prot opt source               destination
RETURN     all  --  0.0.0.0/0            0.0.0.0/0
RETURN     all  --  0.0.0.0/0            0.0.0.0/0
DNAT       tcp  --  0.0.0.0/0            127.0.0.1            tcp dpt:24224 to:172.21.0.2:24224
DNAT       udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:2055 to:172.21.0.3:2055
DNAT       tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:8447 to:172.21.0.5:8447
DNAT       tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:8446 to:172.21.0.5:8446
DNAT       tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:8989 to:172.17.0.3:8989

Helaas werkt het met --net=host ook niet. Wellicht zit het probleem dus niet in docker, maar ergens anders?

azz_kikr schreef op zondag 18 november 2018 @ 16:38:
In je netstat staat er dat sonar luisterd op ipv6...en je probeert te verbinden met ipv4...

Voor localhost maakt dit niet uit denk ik, voor andere pcs wel denk ik

Zou volgens mij niet uit moeten maken, port 80 zie ik ook bij tcp6 staan, die is wel gewoon bereikbaar.

[ Voor 6% gewijzigd door FutureCow op 18-11-2018 17:42 ]

zondag 18 november 2018 20:25

Acties:

0 Henk 'm!

Hero of Time

Moderator LNX

There is only one Legend

azz_kikr schreef op zondag 18 november 2018 @ 16:38:
In je netstat staat er dat sonar luisterd op ipv6...en je probeert te verbinden met ipv4...

Voor localhost maakt dit niet uit denk ik, voor andere pcs wel denk ik

Er staat naast TCP6 ook ':::<poortnummer>', wat wil zeggen dat het op elk adres luistert. Het is bij Linux standaard om in zo'n geval alleen TCP6 te laten zien, terwijl het op zowel IPv4 als IPv6 luistert. Kijk maar eens op je eigen systeem als je openssh-server hebt draaien.

Commandline FTW | Tweakt met mate

maandag 19 november 2018 07:13

Acties:

0 Henk 'm!

Kees

Serveradmin / BOFH / DoC

FutureCow schreef op zondag 18 november 2018 @ 17:41:

sudo iptables -t nat -L -n:

En de forward chain in de standaard table? dus: sudo iptables -L -nvx

"Een serveradmin, voluit een serveradministrator, is dan weer een slavenbeheerder oftewel een slavendrijver" - Rataplan