VMware köprülü konuk, OpenVPN'den sonra ağını kaybetti

Bir saat önce köprülü ve erişilebilir olan bir konuk artık her şeyde zaman aşımına uğruyor ve kimse ayarlarını düzenlemedi. Ana makinede internet tünel üzerinden hâlâ çalışıyor. İki olgu birlikte VPN'den uzağa ve hipervizöre doğru işaret ediyor, çünkü ana makine ile konuk artık aynı yolu kullanmıyor. Bunu tetiklemek için tek bir yeni sanal bağdaştırıcı yeterli.

Konuk değişmedi, köprü değişti

OpenVPN istemcisini Windows'a kurmak, tünel açıldığında hizmetin bağlandığı bir sanal ağ bağdaştırıcısı ekler. İşletim sistemi için bağlantı durumu olan sıradan bir arayüz ve çoğu zaman kendi adresleri gibi görünür. Bu, VMware'in onu köprü adayı olarak görmesi için yeterlidir.

VMnet0 varsayılan olarak Otomatik'e ayarlıdır; bu, hipervizörün her köprü kurduğunda bir ana makine bağdaştırıcısı seçtiği anlamına gelir. Yeni kurulan sanal bağdaştırıcı bu havuza katılır ve seçilirse, konuğun gönderdiği her çerçeve fiziksel anahtar bağlantı noktası yerine bir tünel aygıtına gider.

Köprüyü sabitleyin veya konuğu yönlendirin

İlk dal, konuğun fiziksel LAN'da eşit bir katılımcı olması gerektiğinde doğrudur: köprünün seçmesine izin vermeyi bırakın ve bağdaştırıcıyı açıkça adlandırın. İkinci dal, konuğun kurumsal tüneli kullanması gerektiğinde geçerlidir ve bu durumda köprü hiçbir zaman doğru tasarım değildi, çünkü köprülü bir konuk ana makinenin VPN yolunu devralmaz.

Önce buna karar verin, çünkü iki yanıt farklı işlere götürür. Sırayı tersine çevirmek, hiç köprülenmemesi gereken bir konuğa bağlı, doğru sabitlenmiş bir köprü üretir.

İlk dal için ana makinede Virtual Network Editor'ü açın, VMnet0'ı seçin ve Otomatik'i fiziksel bağdaştırıcıyla değiştirin. Birden çok bağdaştırıcı varsa otomatik ayarlar listesini kullanın ve asla konuk trafiği taşımaması gereken her şeyin işaretini kaldırın: OpenVPN TAP veya Wintun aygıtı ile Hyper-V, WSL, Docker ve loopback bağdaştırıcıları. Dizüstü bilgisayarda hem kablolu hem kablosuz fiziksel bağdaştırıcıyı işaretli bırakın, yoksa kullanıcı bir dahaki sefere dokladığında konuk köprüsünü kaybeder.

Seçimi belirleyen üç koşul

Bir köprünün uygun olup olmadığı konuğun ne için olduğuna bağlıdır. Konuk LAN'da kendi ana makinesi olarak görünecekse, kendi adresi ve kendi gelen erişilebilirliğiyle, köprü doğru modeldir ve sabitleme tüm düzeltmedir. Konuğun yalnızca giden erişime ihtiyacı varsa, yalnızca ana makineye özel veya NAT ağı daha basittir ve bağdaştırıcı değişimlerine karşı bağışıktır.

Konuk, ana makineyle aynı tüneli kullanmak zorundaysa, ne köprü modu ne de sabitlenmiş bir bağdaştırıcı yardımcı olur, çünkü konuğun trafiği hiçbir zaman ana makinenin yönlendirme kararına girmez. Bu durum ana makinede yönlendirilmiş veya çevrilmiş bir yol gerektirir ve bağdaştırıcı seçimi önemsiz hale gelir.

VMware Player'ın arayüzünde ağ düzenleyicisi yoktur, bu yüzden yalnızca Player çalıştıran bir ana makine bu ayarlara ulaşmak için bağımsız düzenleyiciye veya bir Workstation kurulumuna ihtiyaç duyar. Bu kısıt bazen yaklaşımı tek başına belirler.

Sonucu konuğun içinden okuyun

Sanal NIC'i yeniden başlatın veya konuğu yeniden başlatın ki yeniden kiralama istesin. Ardından ana makinenin yapılandırdığını sandığı şeyi değil, gerçekte ne aldığını okuyun.

ipconfig /all
ip addr
ip route

Bu çıktıda iki alanı okuyun ve geri kalanını şimdilik yok sayın. Ağ geçidi LAN yönlendiricisi olmalı ve bağdaştırıcı açıklaması bir tüneli değil VMware Ethernet aygıtını adlandırmalıdır. 169.254.0.0/16 içinde kendine atanmış bir adres, hiçbir DHCP sunucusunun yanıt vermediği anlamına gelir ve bir tünel bağdaştırıcısına kurulan köprü konuk tarafından tam olarak böyle görünür.

Başka bir şeyi değiştirmeden önce bir ayrım daha yapmaya değer. Yönlendiriciye ulaşan ama internete ulaşmayan bir konuğun çalışan bir köprüsü ve yukarı akışta bir sorunu vardır. Tünel aralığında adres alan bir konuk hâlâ yanlış aygıta bağlıdır. TAP bağdaştırıcısını devre dışı bırakmak iki durumun hiçbiri için çözüm değildir, çünkü OpenVPN hizmetinin ona ihtiyacı vardır.