Dev konteyner yalnız VPN ilə əlçatan hosta çatmır: hara baxmalı
Brauzer və konteyner fərqli resolver, proxy və marşrut kontekstlərinə malikdir. Hər hansı VPN parametrini dəyişməzdən əvvəl uğursuz prosesin hansını istifadə etdiyini müəyyən edin.
Şəxsi API masaüstü brauzerinizdə açılır, inkişaf konteynerində isə uğursuz olur. Bu ziddiyyət deyil və nadir hallarda VPN-in özü günahkardır. Brauzer sorğusu ilə uğursuz sorğunu tamamilə fərqli şəbəkə ad məkanlarından, fərqli resolver, proxy və marşrutlarla işləyən müxtəlif proseslər edib. «Mənim noutbukumda» ifadəsi Windows hostunu, WSL distributivini, Docker Desktop virtual maşınını və həmin VM-in içindəki konteyneri bildirə bilər — eyni host adına hər biri fərqli cavab verə bilən dörd kontekst. Bir dənə parametrə toxunmazdan əvvəl uğursuz prosesin hansından istifadə etdiyini tapın.
Parametri dəyişməzdən əvvəl prosesi tapın
VPN müştərisindən deyil, konteyner mühərrikindən başlayın. Əmr sətrinin hansı kontekstlə danışdığını və həmin mühərrikin hansı əməliyyat sistemi üzərində işlədiyini soruşun, çünki masaüstü VM tərəfindən idarə olunan Linux konteyneri lokal demon tərəfindən idarə olunandan fərqli yoldur:
docker context ls
docker info --format '{{.OperatingSystem}} / {{.Name}}'
docker run --rm alpine ip route
Windows-da wsl -l -v distributivin WSL 2 altında işləyib-işləmədiyini göstərir; bu, onu öz virtual açarının arxasına qoyur. Bu detal konteynerin hostun marşrut cədvəlini paylaşdığını, yoxsa hosta çatmaq üçün yönləndirilmiş port və ya host adı tələb edən NAT-ın arxasında oturduğunu müəyyən edir.
Bir sorğunu sabit saxlayın və müqayisə edin
Şəxsi hostda zərərsiz bir son nöqtə seçin və hər müqayisədə ondan istifadə edin: brauzerdən, host terminalından, WSL distributivindən və konteynerin içindən. Hər cəhd üçün dörd şey qeyd edin: həll olunmuş ünvan, proxy istifadə edilib-edilməməsi, uğursuzluq sinfi və keçən vaxt. Ad axtarışı, bağlantının qurulması, TLS yoxlaması və HTTP statusu dörd fərqli problemdir və onları «işləmir» ifadəsində qarışdırmaq bir səhəri məhv edir.
Müqayisəni uğursuz olan konteynerin içində, səssiz firewall terminalı dəqiqələrlə tutmasın deyə taym-aut ilə aparın. Təzə konteyner mühərrikin şəbəkə kontekstini təkrarlayır, amma tətbiq konteynerinin ad məkanını, proxy dəyişənlərini və ya resolverini yox, ona görə də real konteynerə docker exec etmək etibarlı testdir, yan konteyner isə yalnız fərqin mühərrikdə, yoxsa konteynerdə olduğunu təcrid etmək üsuludur:
docker exec -it app /bin/sh -c "getent hosts api.internal; curl -v --max-time 8 https://api.internal/ 2>&1 | tail -20"
docker run --rm --network container:app curlimages/curl:latest -sv --max-time 8 https://api.internal/ 2>&1 | tail -20
alpine əsas imici busybox daşıyır və curl daşımır — bu, kopyalanmış diaqnostik blokun uğursuz olmasına səbəb olan detal növüdür: müştəri olan imic seçin və ya onu həmin işə əlavə edin. Əlaqəsiz ictimai saytlarla müqayisə heç nəyi təcrid etmir. Konteynerdən https://example.com işləyirsə, yalnız konteynerin internetə çıxışı olduğunu öyrəndiniz, tunel vasitəsilə şəxsi ünvana çatıb-çatmadığı barədə isə heç nə. Eyni şəkildə, yeni terminal açmaq yalnız yeni terminalın işlədiyini sübut edir, uğursuz olan tətbiqlə eyni icra mühitini paylaşdığını yox.
Docker Desktop VPN ilə işləyə bilər
Docker-in VPN və host bağlantısı haqqında sənədləşməsi bunu dəstəklənən quraşdırma kimi təsvir edir və dürüst xülasə budur ki, o, avtomatik olaraq sınmır, işləyir. Masaüstü VM-in dizayn olaraq host tunelini yan keçdiyini fərz etməyin; bir çox quraşdırmada trafik hostun tunelini düzgün izləyir, buna görə də «Docker VPN-i nəzərə almır» əfsanəsi arxayın və yanlış məsləhət doğurur.
Hansı backend-in istifadə edildiyi, müştərinin bölünmüş tunel siyasəti və VM-in aldığı resolver konfiqurasiyası hələ də vacibdir. Marşrutları quraşdıran, amma DNS quraşdırmayan və ya VM-in çata bilmədiyi DNS serverini itələyən VPN müştərisi konteynerin içində ad axtarışı uğursuzluğu yaradır, host isə işləyir, çünki hostun əlavə resolveri və ya keşlənmiş cavabı var. Bu, konteyner libası geyinmiş resolver problemidir. O, sınadığınız hər VPN yenidən qoşulmasına dözür, çünki tunel artıq ondan daşımasını istədiyiniz trafiki daşıyır.
Ünvan toqquşmaları və MTU fərqli uğursuzluqlardır
İki uğursuzluq ayrıca diaqnoza layiqdir, çünki onlar tez-tez giriş siyasəti ilə səhv salınır. Birincisi ünvan toqquşmasıdır: VPN konteyner şəbəkəsinin defolt körpü alt şəbəkəsi ilə toqquşan diapazon itələyirsə, konteynerin həmin diapazon üçün marşrutu lokal körpüyə işarə edir və tunelə heç vaxt çatmır. Təxmin etmək əvəzinə real alt şəbəkələri yoxlayın:
docker network inspect bridge --format '{{range .IPAM.Config}}{{.Subnet}}{{end}}'
ip route get 10.20.30.40
İkincisi MTU problemidir. Bağlantı qurulur və TLS tamamlanır, lakin daha böyük cavablar dayanırsa, bu paket ölçüsü problemidir, avtorizasiya problemi deyil və DNS qeydlərini dəyişmək onu heç vaxt düzəltməyəcək. Bir şeyi dəyişməzdən əvvəl kiçik və böyük sorğu ilə sınayın və hər iki nəticəni qeyd edin.
Toqquşmanın həlli ünvan planına sahib olanın seçdiyi fərqli konteyner alt şəbəkəsi və ya məhdud marşrutdur. MTU dayanmasının həlli tunel və ya interfeys MTU-nu yolda davam edən dəyərə sıxmaq və ya azaltmaq, idarə etdiyiniz layda tətbiq etməkdir.
Proxy konfiqurasiyası maşın üzrə deyil, proses üzrədir
Konteynerin içində localhost həmin konteynerin öz şəbəkə kontekstini adlandırır, ona görə hostda işləyən proxy orada bu adla əlçatan deyil. Docker Desktop hosta çıxış üçün host.docker.internal təqdim edir və Linux-da onu --add-host=host.docker.internal:host-gateway ilə açıq şəkildə əlavə edirsiniz. Hər halda bu ad sizə hosta marşrut verir; o, proxy xidməti yaratmır və ondan istifadə etməyə icazə də vermir.
Faktiki mühit üçün verilən proxy ünvanını və portunu istifadə edin və onu kimin oxuduğunu yoxlayın. İnteraktiv qabıqda eksport edilən dəyişənlər hər redaktor genişlənməsini, dil serverini, build alətini və fon demonu avtomatik konfiqurasiya etmir. Vacib olan uğursuz sorğunu edən prosesdir, ona görə terminalınızın deyil, onun mühitini yoxlayın.
Nəhayət, düzəliş özünü izah etsin. Faydalı həll səhv olan sərhədi, onu dəyişən parametri və indi təsirlənən proseslər çoxluğunu adlandırır. VPN-i, redaktoru və mühərriki ardıcıl yenidən başlatmaq simptomu dəyişə bilər, amma növbəti şəxsin istifadə edə biləcəyi heç nə qoymur.