VirtualBox NAT mı köprü mü: VM'in VPN'i nerede biter

Bir sanal makine VPN istemcisi çalıştırdığında iki farklı soru birlikte gelir ve yanıtları farklıdır. Birincisi konuğun içindeki tünelin ana makineyi koruyup korumadığı, ikincisi ana makinedeki tünelin konuğu kapsayıp kapsamadığıdır. Bağdaştırıcı modu ikisini de belirler, VPN yazılımının kendisinden daha fazla. NAT bağdaştırıcısı ana makineyi görünür uç nokta yapar, köprü bağdaştırıcısı ise konuğu kendi adresiyle ağa koyar.

Şifreli oturumu gerçekte kim sonlandırır

Şifreli oturum onu sonlandıran makineye aittir ve istemci VM içinde çalıştığında bu makine konuktur. O tünelden yalnızca konuğun sanal bağdaştırıcısına giren trafik geçer ve hiper yönetici asla kendiliğinden başka bir makineyi konuğun içinden yönlendirmez. Bu yüzden konuk çalışan bir tünel tutabilirken ana makine açık ağda gezinir. Tersi simetrik değildir ve çoğu kılavuzun yanlış anladığı kısım tam da bu asimetridir.

Dış ağın kimin adresini gördüğü, bağdaştırıcı modunun yanıtladığı sorudur. Bu netleştiğinde kapsam bir politika sorunu olmaktan çıkar ve mekanik bir soruya dönüşür. Aşağıdaki her şey bu iki olgudan çıkar.

NAT konuğu ana makineye benzeyene kadar yeniden yazar

NAT ile hiper yönetici konuğun her paketini ilk anahtara ulaşmadan önce ana makinenin adresine yeniden yazar. Bu trafik sonra ana makinenin kendi ağ yığınına verilir, orada ana makinenin yönlendirme tablosunu izler, ana makinedeki bir tünele ait varsayılan yol da buna dahildir. Bu nedenle NAT konuğu hiçbir yapılandırma olmadan ana makinedeki bir tünelle kaplanır, bu da konuktan ana makineye yönünün ima ettiğinin tersidir.

# on the host: adapter mode and NAT DNS behaviour
VBoxManage showvminfo "lab-vm" | grep -i -E "nic|nat"
VBoxManage modifyvm "lab-vm" --natdnshostresolver1 on

Kendi istemcisini çalıştıran konuk o tüneli konuğun içinde sonlandırır ve şifreli trafik aynı yeniden yazmadan çıkar, böylece ana makinenin uygulamaları kendi yolunu ve kendi çıkış adresini korur. VirtualBox bu modda ad çözümlemesini de yönetir ve --natdnshostresolver1 etkin değilse konuğun sorgularını kendi motorundan geçirir. Etkinleştirmek konuğun aramalarını ana makinenin çözümleyicisine verir; bu, ana makinenin kendi görüşü doğru olduğunda çözümlemeyi düzeltir ve aynı ölçüde yalnızca bir tünelin içinde var olabilecek bir çözümleyici de verir. Ayar değişmeden önce VM kapatılmalıdır ve ayar konuğun yazılımına değil bağdaştırıcıya aittir.

Köprü konuğa kendi kiralamasını ve kendi görünürlüğünü verir

Köprü konuğun çerçevelerini fiziksel bölüme aktarır, bu yüzden DHCP ona kiralama verir ve ağ onu ayrı bir ana makine olarak ele alır. Köprülenmiş her konuk kendi varsayılan yoluyla bağımsız bir tünel tutabilir ve ana makinenin tablosu asla değişmez. Bedeli görünürlüktür: konuk yayınlara yanıt verir, komşu tablolarında görünür ve anahtar bağlantı noktası güvenliği ile kablosuz istemci yalıtımına girer. Ana makinedeki bir tünel de bu düzeni kapsamaz, çünkü konuğun çerçeveleri hiçbir zaman ana makinenin yığınından geçmez.

NAT durumundan bu farkı bir ima olarak bırakmak yerine açıkça söylemek gerekir. Köprülenmiş konuk, trafiği bir tünel kullanmak zorunda kaldığında kendi istemcisine ve kendi kimlik bilgilerine ihtiyaç duyar. Konuğun yerel ağa görünmez kalması gereken yerde NAT ya da denetimli yönlendirmeli yalnızca iç ağ daha iyi bir tasarımdır.

Konuk neden ana makinenin ağ geçidi olamaz

Bir konuğun tünelini ana makineye ödünç vermenin iki büyük hiper yöneticide de desteklenen bir anahtarı yoktur. Ana makinenin konuğun tünelinin içine giden bir yolu ve oraya işaret eden bir çeviri kuralı yoktur, bu yüzden konuk ve ana makine trafiği ayrı sahipleri olan ayrı akışlar olarak kalır. Bu yön, bağdaştırıcı modundan bağımsız olarak başarısız olur.

İşleyen alternatifler yönlendirmeler ve vekillerdir. Yerel SSH yönlendirmesi ana makinenin kendi geri döngüsüne bağlanmasını sağlarken konuk akışı tünele taşır, bu da ikinci bir istemci kurmadan TCP hizmetlerini kapsar. Ana makinenin kendi IP trafiğine bunun yerine konuğun tünelini kullandırmak konuğun içinde bir yönlendirici, ayrıca ana makinede açık bir yol ve ana makinede çeviri gerektirir. Bu bir onay kutusu değil küçük bir ağ tasarımıdır ve dönüş yolu için bir plan gerektirir. Konuk yalnızca istemciyi çalıştırmak için varsa istemciyi ana makineye koyun ve fazladan atlamayı kaldırın.

ssh -N -f -L 8080:internal-host.example:80 user@lab-vm

Çözümleyiciler ve yollar sınırı aşmaz

DNS seçeneği alan bağdaştırıcıyı izler, bu yüzden konuk ana makinenin tünel çözümleyicisini devralmaz ve ana makine konuğa itilen sunucuyu asla öğrenmez. İtilen dhcp-option DNS değerleri onları kabul eden arayüz için geçerlidir, bu yüzden istemcisi olmayan köprülenmiş konuk iç adları çözemez. NAT konuğu genellikle hiper yöneticinin DNS işleyişini kullanır ve fark her ortamda tek bir komutta görünür.

# on the host
VBoxManage showvminfo "lab-vm" | grep -i -E "nic|nat"
# inside a Linux guest
ip -4 route
resolvectl status
# inside a Windows guest
Get-DnsClientServerAddress

Herhangi birinin ana makineyi izlediğini varsaymadan önce konuğun içinde çözümleyiciyi ve yolu okuyun. İç adlar orada çözülecekse tünel çözümleyicisini konuğun kendi bağdaştırıcısına ekleyin, sonra yalnızca tünelin arkasında var olan bir adla doğrulayın. Her VM için bağdaştırıcı modunu, tünelin sahibini ve çözümleyicinin kaynağını kaydedin, çünkü bu üç olgu neredeyse her sonraki soruyu yanıtlar. Diğer hiper yöneticiler modların adını değiştirir ve ilkeyi el sürülmemiş bırakır.