Docker pull: limit czasu uzgadniania TLS


14

Otrzymuję to konsekwentnie (Ubuntu 16.04 LTS):

$ docker pull nginx
Using default tag: latest
Error response from daemon: Get https://registry-1.docker.io/v2/: net/http: TLS handshake timeout

Jednak curl TLS działa dobrze (oprócz błędu autoryzacji):

$ curl https://registry-1.docker.io/v2/
{"errors":[{"code":"UNAUTHORIZED","message":"authentication required","detail":null}]}

Nawet mały program Golang (naśladujący dokera) działa dobrze:

package main
import (
    "fmt"
    "io/ioutil"
    "net/http"
)
func main() {
    resp, err := http.Get("https://registry-1.docker.io/v2/")
    if err != nil {
        panic(err)
    }
    defer resp.Body.Close()
    body, err := ioutil.ReadAll(resp.Body)
    if err != nil {
        panic(err)
    }
    fmt.Println("Got: ", string(body))
}

Plik pcap żądania limitu czasu dokowania TLS:

reading from file docker-timeout.pcap, link-type LINUX_SLL (Linux cooked)
00:38:54.782452 IP my-ubuntu.52036 > registry-1.docker.io.https: Flags [S], seq 26945613, win 29200, options [mss 1460,sackOK,TS val 1609360 ecr 0,nop,wscale 7], length 0
00:38:54.878630 IP registry-1.docker.io.https > my-ubuntu.52036: Flags [S.], seq 2700732154, ack 26945614, win 26847, options [mss 1460,sackOK,TS val 947941366 ecr 1609360,nop,wscale 8], length 0
00:38:54.878691 IP my-ubuntu.52036 > registry-1.docker.io.https: Flags [.], ack 1, win 229, options [nop,nop,TS val 1609384 ecr 947941366], length 0
00:38:54.878892 IP my-ubuntu.52036 > registry-1.docker.io.https: Flags [P.], seq 1:156, ack 1, win 229, options [nop,nop,TS val 1609384 ecr 947941366], length 155
00:38:55.175931 IP my-ubuntu.52036 > registry-1.docker.io.https: Flags [P.], seq 1:156, ack 1, win 229, options [nop,nop,TS val 1609459 ecr 947941366], length 155
00:38:55.475954 IP my-ubuntu.52036 > registry-1.docker.io.https: Flags [P.], seq 1:156, ack 1, win 229, options [nop,nop,TS val 1609534 ecr 947941366], length 155
00:38:56.076327 IP my-ubuntu.52036 > registry-1.docker.io.https: Flags [P.], seq 1:156, ack 1, win 229, options [nop,nop,TS val 1609684 ecr 947941366], length 155
00:38:57.280103 IP my-ubuntu.52036 > registry-1.docker.io.https: Flags [P.], seq 1:156, ack 1, win 229, options [nop,nop,TS val 1609985 ecr 947941366], length 155
00:38:59.684095 IP my-ubuntu.52036 > registry-1.docker.io.https: Flags [P.], seq 1:156, ack 1, win 229, options [nop,nop,TS val 1610586 ecr 947941366], length 155
00:39:04.492102 IP my-ubuntu.52036 > registry-1.docker.io.https: Flags [P.], seq 1:156, ack 1, win 229, options [nop,nop,TS val 1611788 ecr 947941366], length 155
00:39:04.879468 IP my-ubuntu.52036 > registry-1.docker.io.https: Flags [F.], seq 156, ack 1, win 229, options [nop,nop,TS val 1611884 ecr 947941366], length 0
00:39:04.976015 IP registry-1.docker.io.https > my-ubuntu.52036: Flags [.], ack 1, win 105, options [nop,nop,TS val 947943890 ecr 1609384,nop,nop,sack 1 {156:157}], length 0
00:39:04.976073 IP my-ubuntu.52036 > registry-1.docker.io.https: Flags [P.], seq 1:156, ack 1, win 229, options [nop,nop,TS val 1611909 ecr 947943890], length 155
00:39:05.275922 IP my-ubuntu.52036 > registry-1.docker.io.https: Flags [P.], seq 1:156, ack 1, win 229, options [nop,nop,TS val 1611984 ecr 947943890], length 155
00:39:05.876104 IP my-ubuntu.52036 > registry-1.docker.io.https: Flags [P.], seq 1:156, ack 1, win 229, options [nop,nop,TS val 1612134 ecr 947943890], length 155

Co może pójść nie tak?


1
Zamieniłem modem DSL i problem zniknął ... Podejrzewam, że to problem Mtu.
Willem,

Odpowiedzi:


14

net/http: TLS handshake timeoutoznacza, że ​​masz wolne połączenie z Internetem. Domyślna wartość limitu czasu połączenia jest zbyt mała dla twojego środowiska. Niestety doker nie ma żadnych ustawień, które pozwalają zmienić limit czasu połączenia. Możesz spróbować utworzyć własną pamięć podręczną rejestru w innym miejscu i pobrać z niej obrazy.


1
Cóż, speedtest.neti fast.compokaż moją prędkość internetu to 90 Mbit / s. Czy to jest wolne? Ciągnę python:2.7-slimobraz. Jestem w stanie ściągnąć hello-worldz hubu, ale nie z pythonowego. Daje mi ten sam TLS handshake timeoutbłąd.
Nikhil Chilwant

3
Zanim ludzie zaczną robić coś dramatycznego, chcę zauważyć: literówka w nazwie obrazu również powoduje ten sam błąd. Bardzo opisowy.
Barafu Albino

1
Limit czasu uzgadniania TLS w większości przypadków nie oznacza, że ​​połączenie internetowe jest wolne. Ten komunikat pojawi się również, jeśli uzgadnianie TLS zatrzyma się z różnych powodów. Na przykład, jeśli jedna strona nie lubi rozmawiać z określoną wersją TLS lub z powodu problemu z certyfikatem.
The Bndr

4

W moim przypadku mój serwer był za nat i proxy i ustawiłem automatyczne wykrywanie proxy, co zrobiłem na bieżącym terminalu, mam ustawienia proxy eksportu

root@k8master:~/runner# export http_proxy="http://192.168.10.208:3128"
root@k8master:~/runner# docker pull gitlab/gitlab-runner:latest
latest: Pulling from gitlab/gitlab-runner
7b722c1070cd: Pull complete 
5fbf74db61f1: Pull complete 
ed41cb72e5c9: Pull complete 
7ea47a67709e: Pull complete 
ae336ceeca88: Pull complete 
f9f79780e6cf: Pull complete 
67e622273f37: Pull complete 
bc84c40af701: Pull complete 
69e36092e9de: Pull complete 
Digest: sha256:b1f5387942aaaf8c220f6613a1e96ba2cbcb6c58a5e47ca0df8ae3216720a15e
Status: Downloaded newer image for gitlab/gitlab-runner:latest

3

Miałem ten sam problem, używając docker run hello-world1. czasu, co powoduje pobranie obrazu za pomocą https://registry-1.docker.io/v2/, który kończy się

docker: Error response from daemon: Get https://registry-1.docker.io/v2/: proxyconnect tcp: net/http: TLS handshake timeout.

Przeszukując sieć godzinami i dowiedziałem się, że dzieje się tak u niektórych użytkowników Ubuntu 18.04 i bieżącej wersji dokera, za serwerem proxy. Obejściem tego problemu jest usunięcie całej konfiguracji serwera proxy HTTPS, aby pozostawić tylko konfigurację serwera proxy HTTP, aby wymusić pobieranie protokołu HTTP (nie https).

Nie wiem, jaki jest prawdziwy powód.

(tak przy okazji: miałem taki sam problem „uścisku dłoni TLS” z kompozytorem i packagist. Było to spowodowane brakującym plikiem cacert.pem, który domyślnie nie był dostarczany przez Ubuntu. Może ten problem dokera zmierza w tym samym kierunku ?)


3

Mam ten sam problem. Wtedy odpowiedź Azamata Hackimova wskazała mi właściwy kierunek. Moja maszyna działa nieco wolniej, szczególnie podczas uruchamiania, kiedy chcę uruchomić usługę. Dlatego rozpoczyna się krótki limit czasu i zabija moją prośbę.

Oto moje obejście:

docker pull $IMAGE || docker pull $IMAGE ||  docker pull $IMAGE || docker pull $IMAGE

Po prostu młotkuj serwer na żądanie. Zwykle drugi jest dla mnie udany.


Nie jest to ostateczne rozwiązanie, ale dobre jako tymczasowe obejście
Gonzalo Cao

2

Jeśli używasz prywatną rejestru, trzeba umieścić certyfikat że pod /etc/docker/certs.d/ registryname /ca.crt

nazwa rejestru odpowiednio się zmieni

Ponadto zmień rozmiar MTU na 1300, to też zrobiłem, aby rozwiązać błąd. Zarejestruj jeden, jak sądzę, prawdopodobnie już zrobiłeś. Polecenie zmiany MTU

ip link set dev eth0 mtu 1300

Rozmiar MTU należy sprawdzić, aby uniknąć tego błędu, jeśli prędkość Internetu jest naprawdę dobra


To dobra wskazówka, ale brak certyfikatu spowodowałby x509: certificate signed by unknown authoritybłąd TLS handshake timeout.
wisbucky,

0

Dla mnie zadziałało użycie innego interfejsu sieciowego. Zamiast łączyć się przez Ethernet (przewodowy), przełączyłem się na Wi-Fi. Problem rozwiązany.

Nawiasem mówiąc, byłem na nowej instalacji Raspbian Stretch.


0

Żadna z powyższych odpowiedzi nie może rozwiązać mojego problemu, jednak stwierdziłem, że poniżej https://github.com/helm/helm/issues/5220 działa dla mnie!

Po tej zmianie dział IT mojej firmy znalazł rozwiązanie. Użyłem zmiennej środowiskowej https_proxy z https: // url do naszego proxy. Działa to w przypadku większości używanych przez nas narzędzi, ale nie w przypadku steru lub nowszej kostki. Wydaje się, że mają pewne problemy z uzgadnianiem TLS. Przeszliśmy z https: // na http: // url (np. Https_proxy = http: // myproxy ) i teraz wszystko działa dobrze.


0

TLS handshake timeoutBłąd może zostać wyświetlony, jeśli serwer proxy demona dokera nie jest poprawnie skonfigurowany.

# verify docker daemon proxy configuration
/etc/systemd/system/docker.service.d/proxy.conf

# flush changes
sudo systemctl daemon-reload

# restart docker service
sudo systemctl restart docker 

Aby uzyskać więcej informacji, zobacz https://docs.docker.com/config/daemon/systemd/#httphttps-proxy

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.