VPN yeniden bağlandıktan sonra proxy hâlâ eski tünel adresinde mi?

VPN istemcisini yeniden başlatmak yalnızca tünelin geri geldiğini kanıtlar. Proxy hakkında, yani onun üzerinden dışarı çıkması söylenen şey hakkında hiçbir şey söylemez. Squid, tinyproxy ve diğer çoğu yönlendirici, başlangıçta buldukları yerel kaynak adresini bir şey onları yeniden yüklemeye zorlayana kadar tutar. Yeniden bağlanma yeni bir tünel adresi verdiğinde, yönlendirici ya her giden bağlantıda başarısız olur ya da olağan rotanızdan çıkmaya başlar.

Tehlikeli olan ikinci arızadır: tünel ayakta, sayfalar yükleniyor ve yalnızca çıkış adresi yanlış.

Tünelden değil, dinleyiciden başlayın

Oyunda üç adres var ve yeniden bağlanma bunların yalnızca bazılarını hareket ettirir. Dinleyici, tarayıcınızın işaret ettiği yerdir, genellikle 127.0.0.1 veya bir LAN adresi, ve tünelin değişmiş olması onu ilgilendirmez. Giden yerel kaynak, yönlendiricinin bir sonraki atlamayı çevirirken çekirdekten kullanmasını istediği şeydir ve tünel aygıtına bağlıdır. Genel çıkış, bir web sunucusunun kaydettiği şeydir ve birkaç atlama ötedeki çevrilmiş bir adres olabilir.

Genel IP araması yalnızca son soruyu yanıtlar. Bir genel çıkış birkaç iç kaynağı gizleyebildiğinden, yönlendiricinin hangi yerel adrese bağlanması gerektiğini size söyleyemez. Adresi bağlantının sahibinden okuyun: istemcinin durum çıktısı, arabirimin kendisi veya tünelin yaşadığı ad alanı. Adı tünele benzeyen ilk arabirimi almak, ikinci bir profil olduğu anda yanlış yanıt verir.

Konteyner ve ad alanı düzenleri bu varsayımı sessizce kırar. Bir ağ ad alanındaki yönlendirici, başka birinde var olan bir tünele bağlanamaz ve hiçbir yapılandırma düzenlemesi bunu onarmaz.

Herhangi bir şeyi düzenlemeden önce dört denetim

Bunları sırayla yapın. Başarısız olan ilk denetim durduğunuz yerdir, çünkü sonrakiler öncekilerin geçerli olduğunu varsayar.

1. Kullanılan tünelin proxy'nin etrafında kurulduğu profil olduğunu, kendi kendine bağlanan ikinci bir profil olmadığını doğrulayın.
2. O aygıtta şu anda bulunan adresi yazdırın ve çalışan yapılandırmadaki adresle karşılaştırın.
3. Diskteki dosyanın iddia ettiği şeyi değil, yönlendiricinin hangi kaynağı çözdüğünü sorun.
4. Yönlendiriciden gelen trafiğin gerçekten beklediğiniz yönlendirme ve güvenlik duvarı ilkesine tabi olduğunu doğrulayın.

Aygıt adresi kolaydır: ip -4 addr show dev tun0 geçerli olanı yazdırır ve ip -4 route get 1.1.1.1 çekirdeğin o hedef için hangi arabirimi seçeceğini gösterir. Tam adrese bağlanan yönlendirici, adres kaybolduğunda yüksek sesle başarısız olur. Aygıta bağlanan veya varsayılan kaynağa geri düşen yönlendirici çalışmaya ve sızdırmaya devam eder, sessiz sonuç da budur.

Belgeleri çalıştırdığınız sürümle eşleştirin, aramanın ilk sonucuyla değil. Squid'in giden adres yönergesi v7 ve öncesi için belgelenmiştir ve v8 belgeleri yönergenin orada bulunmadığını açıkça söyler, bu yüzden onun etrafında kurulan bir betik bu sınırı aşamaz (bakınız Squid tcp_outgoing_address başvurusu). Herhangi bir şeyi yeniden yüklemeden önce ürünün kendi ayrıştırıcısıyla doğrulayın: squid -k parse hataları bildirir ve çalışan sürece dokunmadan çıkar.

Her tüneli numaralandırın ve eski takasları atın

Yeniden bağlanma bir devirdir ve devirlerin bir sırası olmalıdır. Gözlenen her bağlantıyı, her başarılı kurulumda artan bir sayaç veya zaman damgasıyla etiketleyin, sonra bu etiketi aday yapılandırmanın içine taşıyın. Bir adayın etiketi geçerli olandan daha eskiyse, adayı uygulamak yerine atın, çünkü önceki tünel için yazılmış yavaş bir güncelleme aksi halde geçerli olanın ayarlarının üzerine yazar. Olay patlamalarını birleştirin ki titreyen bağlantı on beş yerine tek bir geçiş üretsin.

İşi dört hamlede düzenleyin: eski çıkış durumunu geçersiz kılın, bağlantı sahibinin tamamlanmayı bildirmesini bekleyin, yalnızca yönetilen parçayı oluşturun, sonra hizmet yöneticisi aracılığıyla doğrulayın ve etkinleştirin. Tüm dosyayı iki adres değerinden yeniden üretmek, dinleyici kısıtlamalarının, kimlik doğrulamanın ve hedef ilkesinin sessizce kaybolduğu yoldur. Kasıtlı bir durdurmaya da saygı gösterin. Kullanıcının kapattığı bir tüneli aramaya devam eden yardımcı bir hata, dayanıklılık değildir.

Açık soketler yeni adresi izlemez

Yönlendiriciyi yeniden yapılandırmak, zaten kurulmuş bağlantılar hakkında hiçbir şey söylemez. Boşalacakları mı ölecekleri mi ürüne bağlıdır, bu yüzden davranışı varsaymak yerine gözlemleyin.

Takastan önce açılan bir soket üzerinden sunulan istek, yeni yapılandırma doğru olsa bile eski yoldan çıkar. Bu önemliyse açıkça karar verin: kısa bir boşaltma penceresine izin verin ve yeni iş almayı durdurun, ya da eski soketleri kapatın ve hataları kabul edin. Sonra yeni bir bağlantıyla test edin ve bu sonucu boşaltma denetiminden ayrı tutun. Kaynağa bağlanma da bir güvenlik sınırı değildir. Trafik olağan rotaya asla dokunmamalıysa, bunu işaretler ve güvenlik duvarı kurallarıyla, DNS ve IPv6 dahil, zorunlu kılın; böylece başarısız bir yeniden yükleme proxy'yi açık bırakmak yerine açıkça kapalı bırakır.

Yeni çıkışı yeni bir istekle kanıtlayın

Önemli olan etkinleştirmeden sonra açılan bir istektir, ping değil ve önceden önbelleğe alınmış bir sayfa da değil. Proxy'den gerçek bir URL isteyin ve uzak ucun bildirdiği çıkış adresini okuyun, sonra sağlayıcı bir tane gösterdiğinde istemcinin tünele dair kendi görüşüyle karşılaştırın.

Ayrıştırmayı, yeniden yüklemeyi ve isteği ayrı komutlar olarak tutun ki bir arıza tek bir adımı göstersin. İlk ikisi başarısız olduklarında hiçbir şeyi değiştirmez, bu yüzden yeniden başlatmadan önce koşarlar.

squid -k parse
sudo squid -k reconfigure
curl -x http://127.0.0.1:3128 -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://example.com

Yeniden yükleme başarısız olursa hizmeti durdurun ve parçayı onarın; eski çıkışla hizmet veren bir proxy kısa bir kesintiden daha kötüdür. Yeniden yükleme başarılı olur ama yeni istek yine de beklenmedik bir yerden çıkarsa, adresleri yeniden düzenlemek yerine yönlendirme denetimine dönün. Doğruladığınız tünel neslini kaydedin, böylece bir sonraki yeniden bağlanmanın karşılaştıracağı somut bir şeyi olsun.