Anwendungen binden sich nur an ipv6 socket

[cyberchriss]

Komme beim Ausführen meiner Docker-images auf meinem DS218+ nicht weiter.
Habe mir das Image ixilon/nukkit:latest-Server runtergeladen und die Porteinsteelungen auf 19132:19132 UDP parametriert.
Das ganze läuft über die Bridge.
Wenn ich den Server Starte und mir die Portbindings anschaue, sehe ich lediglich das ipv6-Binding:

udp6       0      0 :::19132                :::*

Jemand eine Idee, was ich falsch mache?

 

[cyberchriss]

Bei der Bridge ist ipv6 deaktiviert.
Sobald ich den Container starte wird ein ipv6 interface gestartet.
Habe das ganze auch mit anderen Containern probiert.

Da ich hier sonst nichts finde, scheint es wohl an mir zu liegen - über einen Wink mit dem Zaun wäre ich dankbar.

 

[Ar-Al]

Ich weiß nicht, ob es etwas mit dem Problem zu tun hat, aber ich hatte "Ausfälle" von IPv4 in meiner FRITZ!Box.

Ein PC kam nicht ins Internet, aber mein iPhone.
Grund: PC kannte nur IPv4, iPhone auch IPv6.

Erst als ich die FRITZ!Box neu gestartet habe, war IPv4 wieder da.

 

[cyberchriss]

Fritzbox hängt nicht in dem Netz, wo mein Mac und meine DS218+ laufen.
Komme über ipv4 per SSH und Browser aufs NAS.

Bei nicht laufendem Container schaut das ganze so aus:

docker0   Link encap:Ethernet  HWaddr 02:42:7B:1D:38:43   
          inet addr:172.17.0.1  Bcast:0.0.0.0  Mask:255.255.0.0
          inet6 addr: fe80::42:7bff:fe1d:3843/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:34 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:3684 (3.5 KiB)

Sobald der Container läuft so:

dockerf09 Link encap:Ethernet  HWaddr DE:6C:5A:2D:91:16  
          inet6 addr: fe80::dc6c:5aff:fe2d:9116/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:42 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:4332 (4.2 KiB)

 

[haydibe]

Solange Du in /var/packages/Docker/etc/dockerd.json nicht explizit das Binding auf ipv6 beschränkt hast, sollten gemappte Container- Ports immer gegen alle Interfaces gebunden werden.

Was ist die Ausgabe von:
netstat -tulpn4

Wie startest Du Deinen Container?

 

[cyberchriss]

Habe die dockerd.json wie folgt angepasst:

{
    "ipv6": false,
    "registry-mirrors" : []
}

macht aber keinen Unterschied.

netstat -tulpn6
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      9968/nginx: master  
tcp        0      0 192.168.2.4:50001       0.0.0.0:*               LISTEN      12185/dms           
tcp        0      0 192.168.2.4:49170       0.0.0.0:*               LISTEN      12473/synoaudiod    
tcp        0      0 0.0.0.0:50002           0.0.0.0:*               LISTEN      12301/lighttpd      
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      7384/sshd           
tcp        0      0 127.0.0.1:5432          0.0.0.0:*               LISTEN      9730/postgres       
tcp        0      0 127.0.0.1:18617         0.0.0.0:*               LISTEN      12542/synovpcd      
tcp        0      0 0.0.0.0:6011            0.0.0.0:*               LISTEN      12473/synoaudiod    
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      9968/nginx: master  
tcp        0      0 0.0.0.0:445             0.0.0.0:*               LISTEN      9680/smbd           
tcp        0      0 0.0.0.0:3262            0.0.0.0:*               LISTEN      8470/iscsi_snapshot 
tcp        0      0 127.0.0.1:512           0.0.0.0:*               LISTEN      27084/termd         
tcp        0      0 192.168.2.4:49160       0.0.0.0:*               LISTEN      12542/synovpcd      
tcp        0      0 0.0.0.0:5000            0.0.0.0:*               LISTEN      9968/nginx: master  
tcp        0      0 0.0.0.0:5001            0.0.0.0:*               LISTEN      9968/nginx: master  
tcp        0      0 0.0.0.0:139             0.0.0.0:*               LISTEN      9680/smbd           
udp        0      0 127.0.0.1:161           0.0.0.0:*                           7994/snmpd          
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           27261/avahi-daemon: 
udp        0      0 127.0.0.1:54604         0.0.0.0:*                           12542/synovpcd      
udp        0      0 127.0.0.1:50644         0.0.0.0:*                           12185/dms           
udp        0      0 192.168.2.4:55900       0.0.0.0:*                           12185/dms           
udp        0      0 192.168.2.4:55901       0.0.0.0:*                           12473/synoaudiod    
udp        0      0 192.168.2.4:55902       0.0.0.0:*                           12542/synovpcd      
udp        0      0 0.0.0.0:49822           0.0.0.0:*                           8156/synosnmpcd     
udp        0      0 0.0.0.0:9997            0.0.0.0:*                           7398/findhostd      
udp        0      0 0.0.0.0:9998            0.0.0.0:*                           7398/findhostd      
udp        0      0 0.0.0.0:9999            0.0.0.0:*                           7398/findhostd      
udp        0      0 127.0.0.1:39760         0.0.0.0:*                           12473/synoaudiod    
udp        0      0 0.0.0.0:1900            0.0.0.0:*                           12542/synovpcd      
udp        0      0 0.0.0.0:1900            0.0.0.0:*                           12473/synoaudiod    
udp        0      0 0.0.0.0:1900            0.0.0.0:*                           12185/dms           
udp        0      0 0.0.0.0:1900            0.0.0.0:*                           7565/minissdpd      
udp        0      0 0.0.0.0:43993           0.0.0.0:*                           27261/avahi-daemon: 
udp        0      0 172.17.0.1:123          0.0.0.0:*                           7382/ntpd           
udp        0      0 192.168.2.4:123         0.0.0.0:*                           7382/ntpd           
udp        0      0 127.0.0.1:123           0.0.0.0:*                           7382/ntpd           
udp        0      0 0.0.0.0:123             0.0.0.0:*                           7382/ntpd           
udp        0      0 172.17.255.255:137      0.0.0.0:*                           27189/nmbd          
udp        0      0 172.17.0.1:137          0.0.0.0:*                           27189/nmbd          
udp        0      0 192.168.2.255:137       0.0.0.0:*                           27189/nmbd          
udp        0      0 192.168.2.4:137         0.0.0.0:*                           27189/nmbd          
udp        0      0 0.0.0.0:137             0.0.0.0:*                           27189/nmbd          
udp        0      0 172.17.255.255:138      0.0.0.0:*                           27189/nmbd          
udp        0      0 172.17.0.1:138          0.0.0.0:*                           27189/nmbd          
udp        0      0 192.168.2.255:138       0.0.0.0:*                           27189/nmbd          
udp        0      0 192.168.2.4:138         0.0.0.0:*                           27189/nmbd          
udp        0      0 0.0.0.0:138             0.0.0.0:*                           27189/nmbd

port 19132/udp kann ich da nicht sehen :/

netstat -tulpn6 | grep 19132
udp6       0      0 :::19132                :::*                                27015/docker-proxy

Den Container Starte ich über das Docker-Gui

 

[haydibe]

Merkwürdig.

Annahme: Du meinst mit bridge die "default-bridge"

Was ist den die Ausgabe von:
docker network inspect $(docker network ls -f name=bridge -q)

 

[cyberchriss]

docker network inspect $(docker network ls -f name=bridge)
[
{
"Name": "bridge",
"Id": "8c501ea35d5da0a2e00044fd78a921ae7f48b12d578684218866ad16659d652b",
"Created": "2018-04-13T20:45:47.97125372+02:00",
"Scope": "local",
"Driver": "bridge",
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": null,
"Config": [
{
"Subnet": "172.17.0.0/16",
"Gateway": "172.17.0.1"
}
]
},
"Internal": false,
"Attachable": false,
"Ingress": false,
"Containers": {},
"Options": {
"com.docker.network.bridge.default_bridge": "true",
"com.docker.network.bridge.enable_icc": "true",
"com.docker.network.bridge.enable_ip_masquerade": "true",
"com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
"com.docker.network.bridge.name": "docker0",
"com.docker.network.driver.mtu": "1500"
},
"Labels": {}
},
{
"Name": "bridge",
"Id": "8c501ea35d5da0a2e00044fd78a921ae7f48b12d578684218866ad16659d652b",
"Created": "2018-04-13T20:45:47.97125372+02:00",
"Scope": "local",
"Driver": "bridge",
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": null,
"Config": [
{
"Subnet": "172.17.0.0/16",
"Gateway": "172.17.0.1"
}
]
},
"Internal": false,
"Attachable": false,
"Ingress": false,
"Containers": {},
"Options": {
"com.docker.network.bridge.default_bridge": "true",
"com.docker.network.bridge.enable_icc": "true",
"com.docker.network.bridge.enable_ip_masquerade": "true",
"com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
"com.docker.network.bridge.name": "docker0",
"com.docker.network.driver.mtu": "1500"
},
"Labels": {}
},
{
"Name": "bridge",
"Id": "8c501ea35d5da0a2e00044fd78a921ae7f48b12d578684218866ad16659d652b",
"Created": "2018-04-13T20:45:47.97125372+02:00",
"Scope": "local",
"Driver": "bridge",
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": null,
"Config": [
{
"Subnet": "172.17.0.0/16",
"Gateway": "172.17.0.1"
}
]
},
"Internal": false,
"Attachable": false,
"Ingress": false,
"Containers": {},
"Options": {
"com.docker.network.bridge.default_bridge": "true",
"com.docker.network.bridge.enable_icc": "true",
"com.docker.network.bridge.enable_ip_masquerade": "true",
"com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
"com.docker.network.bridge.name": "docker0",
"com.docker.network.driver.mtu": "1500"
},
"Labels": {}
}
]
Error: No such network: NETWORK
Error: No such network: ID
Error: No such network: NAME
Error: No such network: DRIVER
Error: No such network: SCOPE
Error: No such network: local

 

[haydibe]

Bei der Befehlszeile hatte noch ein Parameter gefehlt, den ich nachgetragen habe.
Dann wäre der Informationsblock nur einmal gekommen und die Fehlermeldungen gar nicht.

Das war jetzt nicht sonderlich hilfreich, da bei dir an der Default-Bridge kein Container hängt.

Wenn ein Container darin laufen würde, dann würden unterhalb des "Containers"-Knoten so etwas erscheinen:

"Containers": {
            "d8d459eef7558d5bad72bc159681195ba913d3b1f439a32ca9755e7a34a44117":   
            {
                "Name": "watchtower",
                "EndpointID": "881a685ea5a4b4d0303a0228219d6528e3f0cfcf3083fb4e0ba029c15c673b4b",
                "MacAddress": "02:42:ac:11:00:02",
                "IPv4Address": "172.17.0.2/16",
                "IPv6Address": ""
            }
}

Dann lass mal den Filter auf den namen der Bridge weg, so dass wir alle zu sehen bekommen.
docker network inspect $(docker network ls -q)

 

[cyberchriss]

docker network inspect $(docker network ls -q)
[
    {
        "Name": "bridge",
        "Id": "4896cd08e185fe849a06c0068ca6445d916e21a1d717a18e3a7838f1aa462e0f",
        "Created": "2018-04-14T10:31:45.231289949+02:00",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "172.17.0.0/16",
                    "Gateway": "172.17.0.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "Containers": {
            "bc9bd9449d77fb38ee8f9febc587834702e556d79a62ac221886cb0ccfbb5750": {
                "Name": "nukkit",
                "EndpointID": "600ff0fc3656e6479bcf929a3a69206db504cfd3bbfd02e23e13d99a7ec47b1d",
                "MacAddress": "02:42:ac:11:00:02",
                "IPv4Address": "172.17.0.2/16",
                "IPv6Address": ""
            }
        },
        "Options": {
            "com.docker.network.bridge.default_bridge": "true",
            "com.docker.network.bridge.enable_icc": "true",
            "com.docker.network.bridge.enable_ip_masquerade": "true",
            "com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
            "com.docker.network.bridge.name": "docker0",
            "com.docker.network.driver.mtu": "1500"
        },
        "Labels": {}
    },
    {
        "Name": "host",
        "Id": "e64994fb6e3216a9ae64d0cca7b00d4845da13b78f0ed15f536cc5c0f37e06a7",
        "Created": "2018-04-06T19:06:46.960180013+02:00",
        "Scope": "local",
        "Driver": "host",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": []
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "Containers": {},
        "Options": {},
        "Labels": {}
    },
    {
        "Name": "none",
        "Id": "f11e1a3c708f0fadab662b08632755628bc25608db94891c36c0933e233812d7",
        "Created": "2018-04-06T19:06:46.648993127+02:00",
        "Scope": "local",
        "Driver": "null",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": []
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "Containers": {},
        "Options": {},
        "Labels": {}
    }
]

netstat -napu | grep 19132
udp6       0      0 :::19132                :::*                                26051/docker-proxy

Habe auch mal versucht die 172.16.0.2 in die config des Servers als Listening-IP einzutragen - selbes Ergebnis

docker inspect --format='{{json .NetworkSettings.Networks}}' nukkit
{"bridge":{"IPAMConfig":null,"Links":null,"Aliases":null,"NetworkID":"4896cd08e185fe849a06c0068ca6445d916e21a1d717a18e3a7838f1aa462e0f","EndpointID":"e2bc01b9f7b6134c33565adcd29f432b92b351e435526a2e4950541ad422be11","Gateway":"172.17.0.1","IPAddress":"172.17.0.2","IPPrefixLen":16,"IPv6Gateway":"","GlobalIPv6Address":"","GlobalIPv6PrefixLen":0,"MacAddress":"02:42:ac:11:00:02"}}

Schaut doch auch korrekt aus oder? K.A. woher er den ipv6 socket bekommt und den v4 komplett ignoriert?

ping 172.17.0.2 -c3
PING 172.17.0.2 (172.17.0.2) 56(84) bytes of data.
64 bytes from 172.17.0.2: icmp_seq=1 ttl=64 time=0.061 ms
64 bytes from 172.17.0.2: icmp_seq=2 ttl=64 time=0.067 ms
64 bytes from 172.17.0.2: icmp_seq=3 ttl=64 time=0.055 ms

--- 172.17.0.2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.055/0.061/0.067/0.005 ms

Pingbar ist die Adresse auch.

 

[haydibe]

Was auffällt:
- Die Bridge ist nur für ipv4 konfiguriert -> gut
- Dein Container hat eine ipv4 Adresse -> gut
- Die EndtpointID im Container ist abweichend zu der aus den Netzwerk-Einstellungen?! -> nicht gut, Vermutung: zwischen den beiden Befehlen hast Du den Container weggeworfen und neu angelegt?

Wenn ich Inspect auf einen Container mache, dann sieht der Output genauso aus wie bei dir. Daran kann es also nicht liegen.
Aber wenn ich mir die EndpointIDs aus dem inspect Container und inspect Netwerk (und dort für den Container) anschaue, dann sind die IDs bei mir identisch. Bei dir nicht! -> Das könnte die Ursache für die nicht Erreichbarkeit unter ipv4 sein.

beim Portmapping kannst du ja mal statt port -> port mal dsmiport -> port probieren. Zumindest über die Kommandozeile kann man so das Portmapping auf einzelne IPs beschränken.
Aber im Grunde sollte es nicht nötig sein.

Bei mir horchen die Ports vom docker-proxy laut netstat auch nur auf ipv6, aber ich kann ALLES auch unter ipv4 nutzen.
Hast Du überhaupt die Ports gemapped und versucht über dsmip:{hostport vom mapping} auf den Port zuzugreifen?

 

[cyberchriss]

Bei mir horchen die Ports vom docker-proxy laut netstat auch nur auf ipv6, aber ich kann ALLES auch unter ipv4 nutzen.
Hast Du überhaupt die Ports gemapped und versucht über dsmip:{hostport vom mapping} auf den Port zuzugreifen?

Strange - hab eben versucht von der App drauf zuzugreifen und es gab eine Verbindung über ipv4.
Bin die ganze Zeit davon ausgegangen, dass es einen Listening-Socket geben muss, damit ein Server eine Verbindung annehmen kann.

Nungut - Problem scheint erstmal gelöst - auch wenn ich das Docker-Konzept noch nicht so ganz verstanden habe.

 

[haydibe]

Ist wohl eine ipv4/ipv6 Dual-Stack Sonderlocke in der Darstellung:
https://serverfault.com/questions/7...ipv6-according-netstat-but-reacheable-in-ipv4

Sprich wir haben rumgedoktort an einem Problem das nicht existiert hat

 

[cyberchriss]

Muss man halt nur wissen.
Finde es jedoch bedenklich, dass es anscheinend keine Möglichkeit mehr gibt zu sehen, ob auf ipv4 gelauscht wird.