Geliştirme konteyneri VPN'e özel bir ana bilgisayara ulaşamıyor: nereye bakmalı

Özel API masaüstü tarayıcınızda açılıyor ve geliştirme konteynerinde başarısız oluyor. Bu bir çelişki değil ve sorun nadiren VPN'in kendisi. Tarayıcı isteği ile başarısız istek farklı süreçler tarafından, farklı çözümleyiciler, vekil sunucular ve yollarla ve çoğu zaman tamamen farklı ağ ad alanlarından yapıldı. "Dizüstü bilgisayarımda" ifadesi Windows ana bilgisayarı, bir WSL dağıtımı, Docker Desktop sanal makinesi ve o VM'in içindeki bir konteyner olmak üzere dört bağlamı kastedebilir; bunların her biri aynı ana bilgisayar adına farklı yanıt verebilir. Tek bir ayara dokunmadan önce başarısız sürecin hangisini kullandığını öğrenin.

Bir ayarı değiştirmeden önce süreci bulun

VPN istemcisi yerine konteyner motoruyla başlayın. Komut satırının hangi bağlamla konuştuğunu ve bu motorun hangi işletim sisteminde çalıştığını sorun, çünkü bir masaüstü VM'i tarafından yönetilen Linux konteyneri, yerel bir daemon tarafından yönetilenden farklı bir yoldur:

docker context ls
docker info --format '{{.OperatingSystem}} / {{.Name}}'
docker run --rm alpine ip route

Windows'ta wsl -l -v, dağıtımın WSL 2 altında çalışıp çalışmadığını söyler; bu onu kendi sanal anahtarının arkasına yerleştirir. Bu ayrıntı, konteynerin ana bilgisayarın yönlendirme tablosunu paylaşıp paylaşmadığını ya da ana bilgisayara ulaşmak için yönlendirilmiş bir bağlantı noktası veya ana bilgisayar adı gerektiren bir NAT'ın arkasında olup olmadığını belirler.

Bir isteği sabit tutun ve karşılaştırın

Özel ana bilgisayarda zararsız bir uç nokta seçin ve her karşılaştırma için onu kullanın: tarayıcıdan, ana bilgisayar terminalinden, WSL dağıtımından ve konteynerin içinden. Her deneme için dört şey kaydedin: çözümlenen adres, bir vekil sunucunun kullanılıp kullanılmadığı, hata sınıfı ve geçen süre. Ad çözümleme, bağlantı kurma, TLS doğrulaması ve bir HTTP durumu dört farklı sorundur ve bunları "çalışmıyor" diye birleştirmek bir sabahı boşa harcar.

Karşılaştırmayı başarısız olan konteynerin içinde, sessiz bir güvenlik duvarı terminali dakikalarca tutmasın diye bir zaman aşımıyla çalıştırın. Yeni bir konteyner motorun ağ bağlamını yeniden üretir ama uygulama konteynerinin ad alanını, vekil sunucu değişkenlerini veya çözümleyicisini üretmez; bu yüzden gerçek olanın içine docker exec yapmak yetkili testtir ve yan konteyner yalnızca farkın motorda mı konteynerde mi olduğunu yalıtmanın bir yoludur:

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 temel imajı busybox taşır ve curl içermez; kopyalanmış bir tanılama bloğunu başarısız yapan tam da bu tür bir ayrıntıdır: istemcisi olan bir imaj seçin veya aynı çalıştırmanın içine ekleyin. İlgisiz genel sitelerle karşılaştırma hiçbir şeyi yalıtmaz. https://example.com konteynerden çalışıyorsa, konteynerin internet erişimi olduğunu öğrendiniz ve tünel üzerinden özel bir adrese ulaşıp ulaşamayacağı hakkında hiçbir şey öğrenmediniz. Aynı şekilde, yeni bir terminal açmak yalnızca yeni terminalin çalıştığını kanıtlar, başarısız uygulamayla bir çalışma zamanını paylaştığını değil.

Docker Desktop bir VPN ile çalışabilir

Docker'ın VPN ve ana bilgisayar bağlantısı hakkındaki kendi belgeleri bunu desteklenen bir kurulum olarak tanımlıyor ve dürüst özet, otomatik olarak bozuk olmak yerine çalıştığıdır. Masaüstü VM'inin tasarım gereği ana bilgisayar tünelini atladığını varsaymayın; birçok kurulumda trafik ana bilgisayar tünelini doğru biçimde izler, bu yüzden "Docker VPN'i yok sayar" folkloru kendinden emin ve yanlış tavsiyeler üretir.

Hâlâ önemli olan, kullanılan backend, istemcinin bölünmüş tünel politikası ve VM'in aldığı çözümleyici yapılandırmasıdır. Yolları kurup DNS kurmayan ya da VM'in ulaşamayacağı bir DNS sunucusunu iten bir VPN istemcisi, ana bilgisayar çalışırken konteyner içinde ad çözümleme hatası üretir, çünkü ana bilgisayarın ek bir çözümleyicisi veya önbelleğe alınmış bir yanıtı vardır. Bu, konteyner kılığına girmiş bir çözümleyici sorunudur. Denediğiniz her VPN yeniden bağlantısında varlığını sürdürür, çünkü tünel zaten taşımasını istediğiniz trafiği taşımaktadır.

Adres çakışmaları ve MTU farklı hatalardır

İki hata kendi tanısını hak ediyor çünkü sıklıkla erişim politikasıyla karıştırılır. Birincisi bir adres çakışmasıdır: VPN, bir konteyner ağının varsayılan köprü alt ağıyla çakışan bir aralık iterse, konteynerin o aralık için yolu yerel köprüyü gösterir ve tünele asla ulaşmaz. Tahmin etmek yerine gerçek alt ağları inceleyin:

docker network inspect bridge --format '{{range .IPAM.Config}}{{.Subnet}}{{end}}'
ip route get 10.20.30.40

İkincisi bir MTU sorunudur. Bağlantı kurulur ve TLS tamamlanır ama daha büyük yanıtlar takılırsa, bir yetkilendirme sorunu değil paket boyutu sorunu yaşıyorsunuzdur ve DNS kayıtlarını değiştirmek bunu asla düzeltmez. Herhangi bir şeyi değiştirmeden önce küçük bir istek ve büyük bir istekle test edin ve iki sonucu da kaydedin.

Çakışmanın çözümü, adres planının sahibi tarafından seçilen farklı bir konteyner alt ağı veya kapsamlı bir yoldur. MTU takılmasının çözümü, tünelin veya arayüzün MTU'sunu yolu atlatan bir değere sıkıştırmak veya düşürmektir; kontrol ettiğiniz katmanda uygulanır.

Vekil sunucu yapılandırması makine başına değil süreç başınadır

Bir konteynerin içinde localhost o konteynerin kendi ağ bağlamını adlandırır, bu yüzden ana bilgisayarda çalışan bir vekil sunucuya orada o adla ulaşılamaz. Docker Desktop, ana bilgisayar erişimi için host.docker.internal sağlar ve Linux'ta bunu --add-host=host.docker.internal:host-gateway ile açıkça eklersiniz. Her iki durumda da bu ad size ana bilgisayara bir yol verir; bir vekil sunucu hizmeti oluşturmaz ve onu kullanma yetkisi vermez.

Gerçek ortam için sağlanan vekil sunucu adresini ve bağlantı noktasını kullanın ve onu kimin okuduğunu kontrol edin. Etkileşimli bir kabukta dışa aktarılan değişkenler her düzenleyici eklentisini, dil sunucusunu, derleme aracını ve arka plan daemon'ını otomatik olarak yapılandırmaz. Önemli olan, başarısız isteği yapan süreçtir; bu yüzden terminalinizin ortamını değil, onun ortamını inceleyin.

Son olarak, düzeltmenin kendini açıklamasını sağlayın. Yararlı bir çözüm, yanlış olan sınırı, onu değiştiren ayarı ve artık etkilediği süreç kümesini adlandırır. VPN'i, düzenleyiciyi ve motoru sırayla yeniden başlatmak belirtiyi değiştirebilir, ancak sonraki kişinin kullanabileceği hiçbir şey bırakmaz.