VPN açık ve localhost çalışmıyor: ad, proxy yoksa bind mi?

Geliştirme sunucunuz bir dakika önce yanıt verdi, şimdi tünel açılınca istek hiç yazmadığınız bir ana makine adıyla zaman aşımına uğruyor. Neredeyse her durumu iki mekanizma açıklıyor ve dışarıdan ikisi aynı görünüyor. Arama soneki kısa bir adı kurumsal ada çevirirken, proxy geri döngü trafiğini ona ulaşamayan bir ana makineye gönderir. İkisini ayırmak tek bir sorguya mal olur ve yazmak üzere olduğunuz güvenlik duvarı kuralını kurtarır.

localhost kurumsal bölgeye çözümlendiğinde

Tünel açıkken adın neye çözümlendiğini kontrol edin, sonra tünel kapalıyken aynı sorguyu çalıştırın ve iki yanıtı karşılaştırın. İpucu, 127.0.0.1 beklediğiniz yerde kurumsal aralıkta bir adres olmasıdır. localhost.mycompany.corp gibi bir kayıt, istemci o soneki arama listesine eklediği anda geri döngü girdisini yener, ve istek o bağlantı noktasında hiçbir şeyin dinlemediği özel bir ana makineye gider. Arama listesini tahmin etmek yerine okuyun, çünkü istemci birden fazla alan adı ekleyebilir ve hangi adayın önce deneneceğine sıra karar verir:

getent hosts localhost
resolvectl domain
ss -ltnp | grep 8080

Ana makine adını uygulamada, veritabanı istemcisinde veya not defteri URL'sinde gerçek adresle değiştirin, sonra isteği yineleyin. Hata kaybolursa adlandırma sorununuz vardı ve tünel yalnızca tetikleyiciydi. Sürerse sıradaki şüpheli dinleyici veya yoldur ve ad yalnızca yanlış bir izdi.

Geri döngüyü yakalayan proxy ayarları

Tünel açılırken uygulanan sistem proxy'si 127.0.0.1 adresine giden isteği kabul eder ve ne demek istediğinizi bilmeyen uzak bir proxy'ye iletir. Boş istisna listesi yerel bir isteği uzak bir isteğe dönüştürür ve hata iletisi bunu nadiren söyler. Geri döngü adreslerini tek bir komut için değil tüm oturum için istisna listesine ekleyin, sonra ağ hakkında bir sonuca varmadan önce aracın buna uyduğunu doğrulayın.

Uygulama çatıları kendi ortam değişkenlerini ve bazen kendi yapılandırma dosyalarını okur, bu yüzden bir araç için çalışan istisna sonraki için hiçbir şey kanıtlamaz. Tarayıcılar bir ayrıntı ekler: Chromium tabanlı tarayıcılar geri döngü için proxy'yi örtük olarak atlar ve istisna belirteci bu davranışı kaldırabilir. İşletim sistemi ayarının tüm hikâye olduğunu varsaymak yerine gerçek proxy kararını denetleyin. Kabuktan başlatılan her şey için iki komut bunu belirler:

curl --noproxy '*' http://127.0.0.1:8080/health
NO_PROXY=localhost,127.0.0.1,::1 your-tool

bind adresi kimin bağlanabileceğine karar verir

127.0.0.1 üzerinde başlatılan sunucu yalnızca o makineden bağlantı kabul eder, bu genellikle geliştirme için doğru varsayılandır. 0.0.0.0 üzerindeki sunucu VPN bağdaştırıcısı dahil her arayüzde yanıt verir, bu çoğu insanın amaçladığından daha fazla açıklıktır. Gerçek geri döngü adresi başarısız olduğunda her şeyden önce bind ayarını denetleyin.

Dinleyen soketi inceleyin ve yalnızca bağlantı noktasını değil bağlı olduğu adresi not edin. Başka bir aygıt ya da kapsayıcı hizmete tünel üzerinden ulaşacaksa kullanacağı belirli arayüze bağlayın ve o bağlantı noktasına bilinçli olarak izin verin. Yalnızca kendi makineniz gerekiyorsa dar bind'i koruyun ve sunucuyu genişletmek yerine istemciyi düzeltin. Bağlantı noktası yönlendirme ya da bir tünel katmanı ikisini köprüleyebilir, ama her biri sonradan kendi hata ayıklamasını gerektiren bir bileşen ekler.

Hata ayıklama aracının LAN beklediği yer

Hata ayıklama araçları tünelin sessizce bozduğu varsayımlar taşır. Telefon hata ayıklama köprüsü VPN aygıtın alt ağını yakaladığında aygıtını kaybeder, bu yüzden LAN adresi veya kabloyla yeniden bağlanmak çakışmayı önler. Tarayıcı otomasyon merkezi yalnızca proxy üzerinden erişilebildiğinde veya yerel bir güvenlik duvarı denetim bağlantı noktasını düşürdüğünde zaman aşımına uğrar. Uzak hata ayıklayıcı, istemcinin yolu yeniden yazdığı yerde yetki yükseltme ve geri döngü adresi isteyebilir.

Denetim bağlantı noktasını ve veri bağlantı noktasını ayrı ayrı belirleyin, çünkü çoğu zaman biri hayatta kalırken diğeri kalmaz. Sonra düzeltmenin aracın yapılandırmasına mı, o alt ağ için bir yola mı yoksa bölünmüş tünel kuralına ait olduğuna karar verin. hosts dosyasını her geliştirici makinesinde düzenlemek en kötü ölçeklenir ve ilk unutulur. Profille birlikte yaşayan ve tünelin sahibi olan herkesin gözden geçirebileceği ayarı tercih edin.

Başarısız olan ilk aşamada durun

Üç aşamada inin: adı çözümleyin, gerçek adrese bir soket açın, sonra aracın kendi bağlantısını kurmasına izin verin. Her aşama bir katmanı ortadan kaldırır, böylece ilk başarısızlık düzeltilecek katmanı adlandırır ve sonrasındaki her şey test edilmeden kalır. Bir şeyi değiştirmeden önce sonucu yazın, çünkü ölçümden önce uygulanan bir düzeltme şanstan ayırt edilemez. İlk deneme başarısız olup tekrar işe yararsa, araç başladığında tünel muhtemelen hazır değildi.

Sabit beklemeyi yolu bekleyen sınırlı bir hazırlık denetimiyle değiştirin ve başarısız aşamayı günlükte tutun ki sonraki kişi nerede durduğunu görsün. Kendiliğinden düzelen bir araç onarılmış değildir, şanslıdır ve şans başkasının makinesinde tükenir. Tüneli en son değiştirin ve yalnızca gerçekten başarısız olan aşama için. Bu sıra aynı zamanda çalışan bir derlemeye dönüşün en kısa yoludur, çünkü hiç dahil olmayan bir bileşeni yeniden inşa etmenizi engeller.