VirtualBox NAT arkasında misafir VPN'iniz neden başarısız oluyor?

Sanal makine içindeki tarayıcı çalışıyor ve aynı misafirdeki VPN istemcisi veri taşıyamıyor. Misafirin bağlantısı açıkça var, yani hata VPN'in dış protokolünün gerektirdiği şeyde ve sanal NAT'ın geçireceği şeyde. Sonucu üç koşul belirliyor: hangi süreç VPN'e sahip, dış alışveriş kabloda nasıl görünüyor ve bağdaştırıcı modu düşündüğünüz mod mu. Değiştirebileceğiniz koşulu adlandırmak bütün karardır.

Ağı suçlamadan önce VPN sürecini bulun

Önce VPN'in misafir içinde mi yoksa ana makinede mi çalıştığına karar verin, çünkü iki düzenleme farklı biçimde başarısız olur. Misafir içindeki istemci kendi dış bağlantısını misafir bağdaştırıcısı ve arkasındaki herhangi bir çeviri üzerinden kurar. Ana makine VPN'i misafirin trafiğini ana makine ve hipervizör politikasına göre yakalar; bu, kendi kurallarına sahip ayrı bir yakalama noktasıdır. İkisi aynı anda çalışıp kanıtları karıştırabilir, bu yüzden herhangi birine dokunmadan önce bu trafiği hangisinin taşıması gerektiğini belirleyin.

Başka bir şeyi değiştirmeden önce misafirin bağdaştırıcı modunu şimdi yazın. O tek değer sonraki şeylerin çoğunu açıklar ve daha sonra herkesin size ilk soracağı şey odur.

Dış alışveriş uyumluluğu belirler

VirtualBox ağ kılavuzu burada önemli olan NAT sınırlamalarını listeler: TCP ve UDP dışındaki protokolleri geçirmez, GRE desteklenmiyor olarak belirtilir ve PPTP etkilenen örnek olarak verilir. PPTP, kontrol alışverişi için TCP ve veriler için GRE kullanır, bu nedenle kontrol bağlantısı başarılı olabilirken veri yolu aynı sınırı geçemez. Bunlar iki farklı kanıttır ve yalnızca biri trafik taşımakla ilgilidir. Bir güvenlik duvarı kuralında TCP portu 47'ye izin vermek, IP protokolü 47'ye izin vermekle aynı değildir ve bu ikisi sürekli karıştırılır.

Sınırlamayı NAT kelimesini kullanan her cihaza değil, bu NAT düzenlemesine bağlı tutun. Fiziksel bir yönlendirici GRE'yi şikayetsiz geçirebilirken sanal NAT onu düşürür ve başka bir hipervizör neyi ileteceğine kendisi karar verir. Kuruluş TCP veya UDP içinde onaylanmış bir taşıma sunuyorsa, o yol için onun desteklenen istemcisini ve profilini kullanın. Uyumluluk birkaç gereksinimden biridir ve ne sunucu güvenini ne hesap iznini ne de çalışan özel rotaları tesis eder.

Köprü gerçekte neyi değiştirir

Bir köprü, misafirin MAC adresini çevirinin arkasına saklamak yerine fiziksel segmente verir. Ardından misafir o segmenti hizmet veren herhangi bir DHCP sunucusundan adres alır, o adres için ARP'ye yanıt verir ve yukarı akıştaki anahtara bir port daha olarak görünür. Bu, sanal çeviri yolunu ortadan kaldırır; eski bir tarifin bunu önermesinin tam nedeni budur ve aynı anda üç şeyi daha değiştirir. Adresleme artık hipervizörden değil yerel segmentten geliyor, açığa çıkma misafirin o segmente görünür olduğu anlamına geliyor ve kabul anahtar portuna ve onun politikasına bağlı. Bunların her biri değişikliği reddetmek için bir neden olabilir ve hiçbiri VPN protokolüyle ilgili değildir.

Köprüleme eksik bir eklenti kurmaz, kullanılamayan gizli bir ajan sağlamaz ve bir kimlik doğrulama reddini onarmaz. Eski bir protokolü iyi bir seçim de yapmaz ve operatörün bakımlı bir yedeği varsa karar hipervizörü değiştirmek değil odur. Port yönlendirme tamamen üçüncü bir roldür: gelen bir hizmeti yayınlar ve giden bir istemcinin dış protokolü için hiçbir şey yapmaz.

İki tünel, iki kanıt izi

Misafir VPN'i, herhangi bir iç adres veya özel rota önem kazanmadan önce misafir arayüzünden eşine kadar kullanılabilir bir yola ihtiyaç duyar. Ana makine VPN'i varsa, bu dış alışverişi kendi politikasına göre iletebilir veya engelleyebilir ve misafirin iç tüneli ancak dış olan başarılı olduktan sonra başlar. Hiçbir katmanın kapsamı tek bir bağlı simgeden veya ana makine tarayıcısının genel adresinden okunamaz.

Son değil ilk hata iletisini saklayın, çünkü en erken hatası katmanı adlandırır. Desteklenen bir ağ düzenlemesini her seferinde bir tane değiştirin, aynı misafir profili ve aynı kimlik bilgileriyle, karşılaştırma bir anlam taşısın diye. Hatadan hangi aşamanın kırıldığına karar verin: yerel tümleşme, taşıma, kimlik doğrulama veya tünel kalktıktan sonra kaynak erişimi. Her birinin farklı bir sahibi vardır ve yalnızca biri hipervizör sorusudur.

Hangi koşul sizi gerçekten engelliyor

Artık karar farklı yanıtları olan üç soruya daralıyor. Dış protokol TCP ve UDP'nin dışındaysa kısıtlama NAT modudur ve ileri yol köprü veya onaylanmış TCP/UDP taşımasıdır. Dış alışveriş tamamlanıp veri yolu tamamlanmıyorsa kısıtlama ikinci kanıtta görülenin aynısıdır. Tünel kalkıp kaynaklar yanıt vermiyorsa sorun hipervizörü çoktan geçip yönlendirme veya politikaya ulaşmıştır.

Yanıtı bağdaştırıcı moduyla birlikte yazın, yoksa sonraki kişi aynı öğleden sonrayı tekrarlar. Her düzeltmeden sonra misafir içinde gerçek uygulamayı ve ad çözümlemesini test edin, sonra yeniden bağlanın ve hata politikasını deneyin. Tünelden çalışan bir web sayfası yalnızca web yolunun çalıştığını kanıtlar, bu da o anda hissedilenden daha küçük bir iddiadır.