Docker używa protokołu IPv4 do łączenia portów

Question 1

Mam hosta dockera, aw środku mam jeden kontener.

Host Dockera wiąże port tylko w interfejsie IPv6, a nie w IPv4.

To jest wynik

tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -
tcp        0      0 0.0.0.0:55082           0.0.0.0:*               LISTEN      -
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      -
tcp6       0      0 :::80                   :::*                    LISTEN      -
tcp6       0      0 :::22                   :::*                    LISTEN      -
tcp6       0      0 :::40280                :::*                    LISTEN      -
tcp6       0      0 :::5432                 :::*                    LISTEN      -
tcp6       0      0 :::40122                :::*                    LISTEN      -
tcp6       0      0 :::36378                :::*                    LISTEN      -
tcp6       0      0 :::40543                :::*                    LISTEN      -
tcp6       0      0 :::111                  :::*                    LISTEN      -

Teraz mam port 40122 na hoście do połączenia z portem 22 na kontenerze.

Chcę SSH do tego kontenera, ale nie jestem w stanie tego zrobić, ponieważ jest on powiązany tylko z IPv6

To jest moja wersja docker Docker version 1.5.0, build a8a31ef

docker ps

201bde6c839a        myapp:latest   "supervisord -n"    3 weeks ago         Up 2 hours          0.0.0.0:40122->22/tcp, 0.0.0.0:40280->80/tcp, 0.0.0.0:40543->443/tcp   myapp

Biegałem używając docker run -d -P -p 40122:22

netstat -tlna

tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
tcp        0      0 127.0.0.1:3031          0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:6379            0.0.0.0:*               LISTEN
tcp6       0      0 :::22                   :::*                    LISTEN
tcp6       0      0 :::6379                 :::*                    LISTEN

ps aux

root         1  0.0  0.8  52440 16668 ?        Ss   00:53   0:03 /usr/bin/python /usr/bin/supervisord -n
root        49  0.0  0.1  17980  3048 ?        S    01:32   0:00 bash
root        64  0.0  0.1  46632  2712 ?        S    01:32   0:00 su -l vagrant
vagrant     65  0.0  0.1  21308  3760 ?        S    01:32   0:00 -su
root       288  0.0  0.1  17980  3088 ?        S    02:01   0:00 bash
root       304  0.0  0.1  46632  2720 ?        S    02:01   0:00 su -l vagrant
vagrant    305  0.0  0.1  21304  3804 ?        S    02:01   0:00 -su
vagrant    308  0.0  3.7 429616 75840 ?        Sl+  02:01   0:05 python ./manage.py shell_plus
root       654  0.0  0.4  47596  9848 ?        S    03:12   0:01 /usr/local/bin/uwsgi --die-on-term --ini /var/www/conf/uwsgi.ini
root       655  0.0  0.3  90280  7732 ?        S    03:12   0:00 nginx: master process /usr/sbin/nginx
www-data   656  0.0  0.1  90600  3624 ?        S    03:12   0:00 nginx: worker process
www-data   657  0.0  0.1  90600  3624 ?        S    03:12   0:00 nginx: worker process
www-data   658  0.0  0.1  90600  3624 ?        S    03:12   0:00 nginx: worker process
www-data   659  0.0  0.2  90940  4500 ?        S    03:12   0:00 nginx: worker process
root       660  0.0  0.2  61372  5332 ?        S    03:12   0:00 /usr/sbin/sshd -D
root       669  0.0  0.4  37004  8892 ?        Sl   03:12   0:01 redis-server *:6379
root       856  8.0  2.8 388720 57792 ?        Sl   04:07   0:18 /usr/local/bin/uwsgi --die-on-term --ini /var/www/conf/uwsgi.ini
root       857  8.0  2.8 388720 57792 ?        Sl   04:07   0:18 /usr/local/bin/uwsgi --die-on-term --ini /var/www/conf/uwsgi.ini
root       858  8.0  2.8 388720 57792 ?        Sl   04:07   0:18 /usr/local/bin/uwsgi --die-on-term --ini /var/www/conf/uwsgi.ini
root       859  8.0  2.8 388720 57792 ?        Sl   04:07   0:18 /usr/local/bin/uwsgi --die-on-term --ini /var/www/conf/uwsgi.ini
vagrant    889  0.0  0.1  18692  2508 ?        R+   04:11   0:00 ps aux

Question 2

Jak @ daniel-t wskazuje w komentarzu: github.com/docker/docker/issues/2174 dotyczy pokazywania powiązania tylko z IPv6 w netstat, ale to nie jest problem. Jak stwierdza ten problem na githubie:

Podczas konfigurowania proxy, Docker żąda adresu sprzężenia zwrotnego „127.0.0.1”, Linux zdaje sobie sprawę, że jest to adres, który istnieje w IPv6 (jako :: 0) i otwiera się na obu (ale formalnie jest to gniazdo IPv6). Po uruchomieniu netstat widzi to i mówi, że jest to IPv6 - ale nadal nasłuchuje na IPv4. Jeśli bawiłeś się trochę ustawieniami, być może wyłączyłeś tę sztuczkę, którą robi Linux - ustawiając net.ipv6.bindv6only = 1.

Innymi słowy, tylko dlatego, że widzisz go tylko jako IPv6, nadal jest w stanie komunikować się za pośrednictwem protokołu IPv4, chyba że masz ustawione połączenie IPv6 tylko z IPv6 z ustawieniem net.ipv6.bindv6only. Dla jasności, net.ipv6.bindv6only powinno mieć wartość 0 - możesz uruchomić sysctl net.ipv6.bindv6onlyweryfikację.

Question 3

Ustawienie net.ipv6.conf.all.forwarding=1rozwiąże problem.

Można to zrobić w systemie na żywo przy użyciu sudo sysctl -w net.ipv6.conf.all.forwarding=1

Question 4

Domyślnie docker używa gniazd AF_INET6, które mogą być używane zarówno do połączeń IPv4, jak i IPv6. Powoduje to, że netstat zgłasza adres IPv6 dla adresu nasłuchującego.

Z RedHat https://access.redhat.com/solutions/3114021

Question 5

PROBLEM ROZWIĄZANY :

POSŁUGIWAĆ SIĘ docker run -it -p 80:80 --name nginx --net=host -d nginx

To jest problem, z którym musimy się zmierzyć w przypadku maszyn wirtualnych, zamiast sieci mostkowej, spróbuj użyć hosta, który będzie dla Ciebie odpowiedni

tcp     0    0 0.0.0.0:80            0.0.0.0:*             LISTEN      - 
tcp6    0    0 :::80                 :::*                  LISTEN      -

Question 6

Jeśli chcesz, aby porty kontenerów były powiązane z adresem IPv4, po prostu:

znajdź plik ustawień
- / etc / sysconfig / docker-network na RedHacie
- / etc / default / docker-network na Debianie i podobnie
edytuj ustawienia sieciowe
- dodaj DOCKER_NETWORK_OPTIONS = -ip = xx.xx.xx.xx
- xx.xx.xx.xx to prawdziwy adres IPv4 (a nie 0.0.0.0)
zrestartuj docker deamon

działa u mnie na dockerze 1.9.1

Answer 1

Mam hosta dockera, aw środku mam jeden kontener.

Host Dockera wiąże port tylko w interfejsie IPv6, a nie w IPv4.

To jest wynik

tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -
tcp        0      0 0.0.0.0:55082           0.0.0.0:*               LISTEN      -
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      -
tcp6       0      0 :::80                   :::*                    LISTEN      -
tcp6       0      0 :::22                   :::*                    LISTEN      -
tcp6       0      0 :::40280                :::*                    LISTEN      -
tcp6       0      0 :::5432                 :::*                    LISTEN      -
tcp6       0      0 :::40122                :::*                    LISTEN      -
tcp6       0      0 :::36378                :::*                    LISTEN      -
tcp6       0      0 :::40543                :::*                    LISTEN      -
tcp6       0      0 :::111                  :::*                    LISTEN      -

Teraz mam port 40122 na hoście do połączenia z portem 22 na kontenerze.

Chcę SSH do tego kontenera, ale nie jestem w stanie tego zrobić, ponieważ jest on powiązany tylko z IPv6

To jest moja wersja docker Docker version 1.5.0, build a8a31ef

docker ps

201bde6c839a        myapp:latest   "supervisord -n"    3 weeks ago         Up 2 hours          0.0.0.0:40122->22/tcp, 0.0.0.0:40280->80/tcp, 0.0.0.0:40543->443/tcp   myapp

Biegałem używając docker run -d -P -p 40122:22

netstat -tlna

tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
tcp        0      0 127.0.0.1:3031          0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:6379            0.0.0.0:*               LISTEN
tcp6       0      0 :::22                   :::*                    LISTEN
tcp6       0      0 :::6379                 :::*                    LISTEN

ps aux

root         1  0.0  0.8  52440 16668 ?        Ss   00:53   0:03 /usr/bin/python /usr/bin/supervisord -n
root        49  0.0  0.1  17980  3048 ?        S    01:32   0:00 bash
root        64  0.0  0.1  46632  2712 ?        S    01:32   0:00 su -l vagrant
vagrant     65  0.0  0.1  21308  3760 ?        S    01:32   0:00 -su
root       288  0.0  0.1  17980  3088 ?        S    02:01   0:00 bash
root       304  0.0  0.1  46632  2720 ?        S    02:01   0:00 su -l vagrant
vagrant    305  0.0  0.1  21304  3804 ?        S    02:01   0:00 -su
vagrant    308  0.0  3.7 429616 75840 ?        Sl+  02:01   0:05 python ./manage.py shell_plus
root       654  0.0  0.4  47596  9848 ?        S    03:12   0:01 /usr/local/bin/uwsgi --die-on-term --ini /var/www/conf/uwsgi.ini
root       655  0.0  0.3  90280  7732 ?        S    03:12   0:00 nginx: master process /usr/sbin/nginx
www-data   656  0.0  0.1  90600  3624 ?        S    03:12   0:00 nginx: worker process
www-data   657  0.0  0.1  90600  3624 ?        S    03:12   0:00 nginx: worker process
www-data   658  0.0  0.1  90600  3624 ?        S    03:12   0:00 nginx: worker process
www-data   659  0.0  0.2  90940  4500 ?        S    03:12   0:00 nginx: worker process
root       660  0.0  0.2  61372  5332 ?        S    03:12   0:00 /usr/sbin/sshd -D
root       669  0.0  0.4  37004  8892 ?        Sl   03:12   0:01 redis-server *:6379
root       856  8.0  2.8 388720 57792 ?        Sl   04:07   0:18 /usr/local/bin/uwsgi --die-on-term --ini /var/www/conf/uwsgi.ini
root       857  8.0  2.8 388720 57792 ?        Sl   04:07   0:18 /usr/local/bin/uwsgi --die-on-term --ini /var/www/conf/uwsgi.ini
root       858  8.0  2.8 388720 57792 ?        Sl   04:07   0:18 /usr/local/bin/uwsgi --die-on-term --ini /var/www/conf/uwsgi.ini
root       859  8.0  2.8 388720 57792 ?        Sl   04:07   0:18 /usr/local/bin/uwsgi --die-on-term --ini /var/www/conf/uwsgi.ini
vagrant    889  0.0  0.1  18692  2508 ?        R+   04:11   0:00 ps aux

Answer 2

Jakiego polecenia użyłeś do uruchomienia kontenera? Opublikuj także wynik działania docker pskontenera.

Daniel T.

Answer 3

Czy możesz potwierdzić, że sshd faktycznie działa w kontenerze? Uruchom docker exec -ti 201bde6c839a /bin/bash, kiedy już jesteś w, opublikuj wyjście ps aux inetstat -taln

Daniel t.

Answer 4

Na moim hoście Docker wszystkie porty Dockera nasłuchują na IPv6 i nie mają problemu z łączeniem się z ssh w kontenerach.

Daniel T.

Answer 5

@Danielt. dodałem informacje. Jestem w stanie ssh przy użyciu exec, ale nie mogę ssh do kontenera bezpośrednio z zewnątrz przy użyciu portu hosta 40122 z komputera Mac

user3214546

Answer 6

Możesz trafić na ten problem github.com/docker/docker/issues/2174 , nie jestem pewien, czy został rozwiązany. Czy możesz również podzielić się tym, jak próbujesz połączyć się przez ssh i jaki pojawia się błąd?

Daniel T.

Answer 7

76

Jak @ daniel-t wskazuje w komentarzu: github.com/docker/docker/issues/2174 dotyczy pokazywania powiązania tylko z IPv6 w netstat, ale to nie jest problem. Jak stwierdza ten problem na githubie:

Podczas konfigurowania proxy, Docker żąda adresu sprzężenia zwrotnego „127.0.0.1”, Linux zdaje sobie sprawę, że jest to adres, który istnieje w IPv6 (jako :: 0) i otwiera się na obu (ale formalnie jest to gniazdo IPv6). Po uruchomieniu netstat widzi to i mówi, że jest to IPv6 - ale nadal nasłuchuje na IPv4. Jeśli bawiłeś się trochę ustawieniami, być może wyłączyłeś tę sztuczkę, którą robi Linux - ustawiając net.ipv6.bindv6only = 1.

Innymi słowy, tylko dlatego, że widzisz go tylko jako IPv6, nadal jest w stanie komunikować się za pośrednictwem protokołu IPv4, chyba że masz ustawione połączenie IPv6 tylko z IPv6 z ustawieniem net.ipv6.bindv6only. Dla jasności, net.ipv6.bindv6only powinno mieć wartość 0 - możesz uruchomić sysctl net.ipv6.bindv6onlyweryfikację.

Michał
źródło

5

To jest właściwie duży problem. Chmura publiczna, taka jak Azure, nie mówi zbyt dobrze o IPV6, na przykład publiczny moduł równoważenia obciążenia platformy Azure próbuje użyć protokołu IPV4 jako zaplecza.

Thomas Decaux

1

Wydaje się, że może być konieczne zainstalowanie „Docker VM Extension” na platformie Azure i korzystanie z Ubuntu 14.04 LTS. Jednak nie wydaje mi się, aby był problem z ipv6, ponieważ jest to tylko na lokalnym hoście, a nie w sieci.

Michael

Masz rację, problem wystąpił w mojej konfiguracji (wyłączenie IPV6 nie jest dobrym pomysłem ^^)

Thomas Decaux

1

@bigdong, na którym chcesz włączyć IPv6.

Michael

1

@Michael You are my timeaver. :)

lv0gun9

Answer 8

5

To jest właściwie duży problem. Chmura publiczna, taka jak Azure, nie mówi zbyt dobrze o IPV6, na przykład publiczny moduł równoważenia obciążenia platformy Azure próbuje użyć protokołu IPV4 jako zaplecza.

Thomas Decaux

Answer 9

1

Wydaje się, że może być konieczne zainstalowanie „Docker VM Extension” na platformie Azure i korzystanie z Ubuntu 14.04 LTS. Jednak nie wydaje mi się, aby był problem z ipv6, ponieważ jest to tylko na lokalnym hoście, a nie w sieci.

Michael

Answer 10

Masz rację, problem wystąpił w mojej konfiguracji (wyłączenie IPV6 nie jest dobrym pomysłem ^^)

Thomas Decaux

Answer 11

1

@bigdong, na którym chcesz włączyć IPv6.

Michael

Answer 12

1

@Michael You are my timeaver. :)

lv0gun9

Answer 13

6

Ustawienie net.ipv6.conf.all.forwarding=1rozwiąże problem.

Można to zrobić w systemie na żywo przy użyciu sudo sysctl -w net.ipv6.conf.all.forwarding=1

LuciferJack
źródło

Ta odpowiedź ma jedną zaletę: pozwala „naprawić” problem bez konieczności restartowania demona docker (odpowiedź ze zmianą konfiguracji docker'a poniżej tak). Odnośnie góry, wybrana odpowiedź: tak naprawdę miałem, sysctl net.ipv6.bindv6only=0więc zmiana tej konfiguracji nie pomogła.

pkoperek

Answer 14

Ta odpowiedź ma jedną zaletę: pozwala „naprawić” problem bez konieczności restartowania demona docker (odpowiedź ze zmianą konfiguracji docker'a poniżej tak). Odnośnie góry, wybrana odpowiedź: tak naprawdę miałem, sysctl net.ipv6.bindv6only=0więc zmiana tej konfiguracji nie pomogła.

pkoperek

Answer 15

Domyślnie docker używa gniazd AF_INET6, które mogą być używane zarówno do połączeń IPv4, jak i IPv6. Powoduje to, że netstat zgłasza adres IPv6 dla adresu nasłuchującego.

Z RedHat https://access.redhat.com/solutions/3114021

Answer 16

PROBLEM ROZWIĄZANY :

POSŁUGIWAĆ SIĘ docker run -it -p 80:80 --name nginx --net=host -d nginx

To jest problem, z którym musimy się zmierzyć w przypadku maszyn wirtualnych, zamiast sieci mostkowej, spróbuj użyć hosta, który będzie dla Ciebie odpowiedni

tcp     0    0 0.0.0.0:80            0.0.0.0:*             LISTEN      - 
tcp6    0    0 :::80                 :::*                  LISTEN      -

Answer 17

0

Jeśli chcesz, aby porty kontenerów były powiązane z adresem IPv4, po prostu:

znajdź plik ustawień
- / etc / sysconfig / docker-network na RedHacie
- / etc / default / docker-network na Debianie i podobnie
edytuj ustawienia sieciowe
- dodaj DOCKER_NETWORK_OPTIONS = -ip = xx.xx.xx.xx
- xx.xx.xx.xx to prawdziwy adres IPv4 (a nie 0.0.0.0)
zrestartuj docker deamon

działa u mnie na dockerze 1.9.1

Sylvain
źródło

1

czy to działa na Debianie? czy nie powinien to być / etc / default / docker?

Dimitri Kopriwa

1

@BigDong dzięki za komentarz, jestem na RedHacie jak OS, więc ścieżka jest trochę inna od jednego systemu operacyjnego do drugiego. Starałem się odzwierciedlić twój komentarz w odpowiedzi

Sylvain

Answer 18

1

czy to działa na Debianie? czy nie powinien to być / etc / default / docker?

Dimitri Kopriwa

Answer 19

1

@BigDong dzięki za komentarz, jestem na RedHacie jak OS, więc ścieżka jest trochę inna od jednego systemu operacyjnego do drugiego. Starałem się odzwierciedlić twój komentarz w odpowiedzi

Sylvain

Docker używa protokołu IPv4 do łączenia portów

Odpowiedzi: