VM'iniz ana makinenin VPN'ini kullanıyor mu? Konuk içinden test edin

Ana makinenin genel IP'sini kontrol edersiniz, VPN görünür ve VM'in korunduğu sonucuna varırsınız. Bu sonuç test tarafından desteklenmez. Bir konuğun kendi yönlendirme tablosu, kendi çözümleyicisi ve kendi arayüzleri vardır, ve ana makinenin çıkış adresi bunlar hakkında hiçbir şey söylemez.

Test konuğun içinde çalışmalı ve neyi ölçtüğünü belirtmelidir.

Ana makinenin tarayıcısından değil, konuğun içinden başlayın

Önce hipervizörün ağ modunu kaydedin: NAT, bridged, host-only veya macvtap. NAT modunda ana makine konuğun trafiğini yönlendirir, bu yüzden ana makinenin tüneli istemcinin rotaları nasıl kurduğuna bağlı olarak geçerli olabilir veya olmayabilir. Bridged modunda konuk fiziksel LAN'da eşit bir katılımcıdır ve ana makinenin tüneli ilgisizdir. Bu iki mod aynı ana makine yapılandırmasından zıt yanıtlar üretir.

Herhangi bir şeyi değiştirmeden önce modu yazın, çünkü sonucun ne anlama gelebileceğini o belirler.

Hedefini bildiğiniz tek bir istek yapın

Gördüğü kaynak adresi bildiren bir hizmete zararsız bir istek gönderin. Ardından konuğun o hedef için kendi yönlendirme kararını kontrol edin: ip route get 203.0.113.5 konuğun kullanacağı arayüzü ve ağ geçidini yazdırır.

Arayüz konuğun normal NIC'i ise trafik konuğun içindeki bir tünelden geçmiyor demektir.

İkinci bir bağdaştırıcı, bir proxy ayarı veya konuk tarafındaki bir VPN istemcisi bir uygulama için yanıtı değiştirip diğeri için değiştirmeyebilir. Kabuktan gelen genel bir isteği değil, gerçekten önemsediğiniz uygulamayı test edin.

Çözümleyiciyi ayrıca kontrol edin

Değişen bir çıkış adresi, o ana makine adını hangi çözümleyicinin işlediğini söylemez. Adı platforma uygun araçla açıkça sorgulayın ve hangi sunucunun yanıt verdiğini not edin. Split DNS, çözümleyici sorusu ile yönlendirme sorusunun farklı yanıtları olduğu anlamına gelir.

Bu ikisi her iki yönde de ayrışabilir ve bu ayrışma çoğu zaman asıl hatadır.

systemd çalıştıran bir ana makinede resolvectl query yanıtın arkasındaki arayüzü ve DNS sunucusunu adlandırır. Daha eski yapılandırmalar sunucuyu dig çıktısında gösterir. Her durumda mesele, yalnızca bir yanıt gelip gelmediği değil, hangi sunucunun yanıt verdiğini görmektir.

Yalnızca başarıyı değil, başarısızlık ilkesini de test edin

Gereksinim tünelin dışına hiçbir trafiğin çıkmamasıysa, başarılı bir istek hiçbir şey kanıtlamaz. İstemcinin desteklediği kontrollü başarısızlık testini kullanın: tüneli desteklenen şekilde durdurun ve konuğun yeni isteğinin engellenip engellenmediğine bakın. Ana makine istemcisinin kill switch'inin her sanal yönlendirme düzenini kapsadığını varsaymayın. Yalnızca belgelenmiş kapsamına güvenebilirsiniz.

Tünel düştüğünde fiziksel NIC'e geri dönen bir konuk, tam olarak NAT modunun izin verdiğini yapıyordur.

Modu ve kapsamı kaydedin

Hipervizörün modunu, konuğun arayüzünü ve rotasını, çözümleyiciyi ve test ettiğiniz uygulamayı yazın. Tarihi ekleyin, çünkü bir anlık görüntü geri yükleme veya hipervizör güncellemesi dördünü de değiştirebilir.

IPv4 tüneli izlediyse bunu söyleyin. İddiayı IPv6'ya, başka bir ad alanına veya başka bir ağdaki başka bir VM'e genişletmeyin.