mitmproxy, DevTools, Gradle: VPN'in arkasındaki üç katman
Loopback asla tünele girmez. Belirtiyi dinleyici, güven deposu veya paket filtresi olarak sınıflandırın ve gerçekten başarısız olan katmanı onarın.
VPN bağlanıyor ve birbiriyle ilgisiz üç araç üç farklı şekilde başarısız oluyor aynı öğleden sonra. mitmproxy istekleri görmeyi bırakıyor, Chrome hata ayıklayıcıyı reddediyor ve Gradle BindException yerel bir soketi bağlarken hata fırlatıyor. Ortak şüphe tünelin localhost'u engellediği yönünde. Bunu yapamaz: 127.0.0.1 çekirdeğin içinde işlenir ve hiçbir zaman bir adaptöre, bırakın ağ geçidini, ulaşmaz.
Üç katman, üç farklı arıza
İstemciyle birlikte değişen şey loopback'e giden yol değil. Bunlar yerel bir proxy, makinenin güven deposu ve bir paket filtresi ve her biri geliştiricinin iş akışının farklı bir parçasını kırıyor. Belirtiyi doğru satıra yerleştirmek teşhisin büyük kısmıdır:
| Symptom | Layer | First check |
|---|---|---|
| Proxy sees no traffic | Local proxy or listener | ss -lntp, or netstat -ano on Windows |
| TLS error in one tool only | Trust store | Which CA bundle does that runtime read? |
| Local bind or connect refused | Packet filter or port owner | Who holds the port, and what rule drops it? |
Bu tür neredeyse her rapor son satırdan başlayıp yukarı çıkar, ki bu terstir. Tünel, loopback trafiğini göremediği kanıtlanabilen tek katmandır, dolayısıyla en az şüpheyi hak eder. Sürecin neyi bağladığıyla başlayın, sonra hangi sertifikalara güvendiğini sorun ve ancak ondan sonra makinedeki politikaya bakın.
Tünelden değil, dinleyiciden başlayın
Bir proxy 127.0.0.1:8080 üzerinde trafik almayı bıraktığında üç şeyden biri olmuştur: hiç başlamamıştır, başka bir port bağlamıştır veya filtre loopback bağlantısını düşürmüştür. Dinleyen soketleri listelemek bunu tek komutla yanıtlar ve iki araç kimin önce olduğu konusunda anlaşamadığında hangi sürecin portu sahiplendiğini de gösterir.
Yol aramasında yerel bir adres aynı şeyi diğer taraftan doğrular. ip route get loopback hedefine doğru loopback aygıtını bildirir, asla tüneli değil; bu da biri çözüm olarak yönlendirme değişikliği önerdiğinde hazır tutulacak yararlı bir cümledir.
Proxy katmanı: ortam yapılandırma değildir
Birçok kurumsal istemci bir HTTP proxy çalıştırır ve uygulamaların onu kullanmasını bekler. Ayar yapmak HTTPS_PROXY bir kabukta onu onurlandıran komut satırı araçlarını düzeltir ve kendi ayar dosyasını okuyan bir araç için hiçbir şey yapmaz. Gradle, Selenium ve gRPC her biri kendi yapılandırmasına başvurur ve tek bir terminalde dışa aktarılan proxy, IDE'nin başlattığı bir daemon için görünmezdir.
Konteyner araçları bunun görünür olduğu olağan yerdir. Bir konteynerin loopback'i kendine aittir, bu yüzden 127.0.0.1 konteyner içinde asla ana makinenin proxy'si anlamına gelmez; ana makine adresi veya ana makine ağı ayarı gerekir. Kabukta çalışıp derlemede başarısız olan düzeltme genellikle bu satırdır, tünel değil.
Güven katmanı: araç başka bir depo okur
Araya girme ikinci değişikliktir ve en yanıltıcı hataları üretir. İstemci denetlenen bağlantılar için kendi sertifikasını sunar, bu yüzden kurumsal köke güvenen bir tarayıcı başarırken gömülü CA deposu olan bir araç başarısız olur. Python'un certifi üzerinden requests'i klasik durumdur: işletim sisteminin deposu doğru olabilir ve istek yine de başarısız olur, çünkü o çalışma zamanı onu asla okumaz. Hata metni araya girmeyi nadiren anar, bu yüzden bu satır yanlışlıkla bozuk uç nokta olarak teşhis edilir.
Uç noktanın gerçekte sunduğu şeyi aracın doğruladığı şeyle karşılaştırın. openssl s_client sunucunun gönderdiği zinciri gösterir; aracın kendi doğrulama çıktısı neye karar verdiğini gösterir. Uyuşmadıklarında, REQUESTS_CA_BUNDLE veya SSL_CERT_FILE o çalışma zamanı için koldur ve kurumsal kök, o çalışma zamanının okuduğu depoda olmalıdır, yalnızca bazı araçların saygı gösterdiği küresel bir yerde değil.
SSL hatasını düzelten bir sürüm değişikliği VPN hakkında değil, güven ve şifre politikası hakkında kanıttır. Bir SOAP istemcisini çalıştıran Python sürüm düşürmesi, gömülü CA deposunu ve varsayılan TLS ayarlarını değiştirdi; ağ yolu hareket etmedi.
Filtre katmanı: o da loopback'i düşürebilir
Üçüncü değişiklik bir paket filtresidir ve bazı ürünler tünele girmeyen trafiği düşüren kurallar kurar. Yerel dinleyiciler de dahil olabilir. Bu, çalışan bir soketi reddedilen veya zaman aşımına uğrayan bir bağlantıya çevirir ve ortaya çıkan hata makinedeki bir politika değil, uygulamadaki bir hata gibi görünür.
Port sahipliği bu katmanın diğer yarısıdır. BindException soketin açılamadığı anlamına gelir, bu da reddedilen bağlantıdan farklı bir başarısızlıktır. Filtreyi suçlamadan önce portu başka bir sürecin tutup tutmadığını kontrol edin, sonra yerel trafiği düşüren bir kural arayın ve ürünün desteklediği en dar izni ekleyin. Aynı hata ayıklama portu için yarışan iki araç, politika engellemesiyle tamamen aynı mesajı üretir ve yalnızca biri güvenlik duvarı değişikliğiyle düzelir.
Chrome'un hata ayıklama portu aynı ailede başarısız olur. Tarayıcı başlar, sürücü DevTools uç noktasına ulaşamaz ve mesaj ağ yerine DevTools'u adlandırır. Ek başlatma bayrakları ve gereksiz bir sürücü yöneticisi hangi sürecin portu sahiplendiğini değiştirir, bu yüzden onları kaldırmak bazen VPN'i onarıyormuş gibi görünür.
Başarısız olan katmanı onarın
Tüneli değil, başarısız olan katmanı onarın. Erişilemeyen bir loopback dinleyicisinin dinleyicisi veya portu düzeltilmelidir. Güvenilmeyen bir sertifika için kurumsal kök, tam o çalışma zamanının baktığı yere kurulmalı ve istisna dar tutulmalıdır. Yerel trafiği düşüren bir filtre için devre dışı bir filtre yerine belirli bir izin kuralı gerekir, çünkü devre dışı bırakmak koruduğu her şeyi de yeniden açar.
VPN'i yeniden bağlamak bu katmanların hiçbirini test etmez. Yalnızca onları bozan değişikliği yeniden çalıştırır, bu yüzden aynı üç arıza her yeniden bağlanmadan sonra geri gelir ve istemciyi etkin olmayan bırakan her yeniden başlatmadan sonra kaybolur.