virtualbox guest os przez VPN

Miałem dokładnie ten sam problem i przejrzałem go do rozwiązania, więc chętnie wyjaśnię problem i rozwiązanie szczegółowo.

Bez udziału VPN

Ważne jest, aby zrozumieć konfigurację wymaganą do spełnienia wymagań bez udziału VPN. Ponadto informacje te zakładają, że żadna zapora programowa nie ingeruje, ani na hoście, ani na gościu.

Bez sieci VPN można to zwykle rozwiązać, tworząc dwie karty sieciowe w konfiguracji maszyny wirtualnej.

Pierwszy adapter musi być ustawiony w NATtryb, który umożliwia gościowi dostęp do zasobów sieciowych (w tym Internetu) przez interfejs sieciowy hosta.

Drugi adapter musi być ustawiony na Host-only, co umożliwia dwukierunkową komunikację między hostem a gościem.

Ten adapter jest nieco bardziej skomplikowany w konfiguracji niż pierwszy, ponieważ wymaga zmodyfikowania globalnych preferencji sieci VirtualBox w celu skonfigurowania adaptera samego hosta (uwaga: wymaga to uprawnień administratora).

W VirtualBox przejdź do File -> Preferences -> Network. Kliknij Host-only Networkskartę i kliknij małą +ikonę, aby dodać nowy adapter. Zostaniesz poproszony o podniesienie uprawnień VirtualBox.

Wypełnienie Adapterzakładki jest obowiązkowe; powinien wyglądać mniej więcej tak (zignoruj adapter oznaczony #2; jest używany do czegoś niezwiązanego):

Wartości na DHCPkarcie serwera są opcjonalne. Jeśli zamierzasz zakodować na stałe adres IP tego adaptera w konfiguracji sieci gościa, te wartości są niepotrzebne. Jeśli z drugiej strony zamierzasz używać DHCP, wartości mogą wyglądać mniej więcej tak:

Ostatnim krokiem związanym z konfiguracją VirtualBox jest powrót do konfiguracji sieci maszyny wirtualnej i dodanie drugiego adaptera, który odwołuje się do właśnie utworzonego adaptera hosta:

Teraz w systemie operacyjnym gościa sieć musi być skonfigurowana do korzystania z tych dwóch interfejsów sieciowych.

W systemie Debian lub Ubuntu GNU / Linux konfiguracja jest tak prosta, jak modyfikacja, /etc/network/interfacesaby wyglądała następująco:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet dhcp

# The secondary network interface
auto eth1
iface eth1 inet static
     address 192.168.56.101
     netmask 255.255.255.0

(purysta może preferować korzystanie z /etc/network/interfaces.dkatalogu, ale to wykracza poza zakres tego wyjaśnienia)

Zrestartuj usługi sieciowe gościa lub prościej, uruchom ponownie całą maszynę wirtualną gościa i wszystko powinno „po prostu działać”.

W tym momencie można pingować maszynę wirtualną gościa 192.168.56.101i otrzymać odpowiedź (pod warunkiem, że zapora programowa nie zakłóca).

Podobnie, powinno być możliwe pingowanie hosta na 10.0.2.2. Wydaje się, że ten adres IP jest „zakodowany na stałe” w implementacji NAT VirtualBox, lub przynajmniej określony przez jakąś nieoczywistą dyrektywę konfiguracyjną, a niewiele jest informacji na temat jego pochodzenia. Ale niestety „po prostu działa”.

Biorąc pod uwagę tę konfigurację, wszystkie trzy warunki przedstawione w pytaniu są spełnione.

Wpisz: VPN

Ale oto pocieranie. Wprowadzenie VPN powoduje problem z zatrzymaniem pokazu (cóż, w zależności od konkretnej sieci VPN i jej konfiguracji).

Nowoczesne sieci VPN są w stanie dzielić tunelowanie , co jest wymagane, aby wspomniana konfiguracja VirtualBox działała zgodnie z trzema wymaganiami. Z (dobrych) powodów bezpieczeństwa dzielone tunelowanie jest często wyłączone, i to jest właśnie problem w twoim przypadku (i moim).

Kiedy łączysz się z VPN, klient VPN (w moim przypadku Cisco AnyConnect Secure Mobility Client, 3.1.02026) sprawdza tabele routingu komputera hosta, zapamiętuje je, a następnie przesyła je wartościami, które zwykle pochodzą z niektórych centralnie- zarządzana lokalizacja (tzn. nawet przy lokalnych uprawnieniach administratora nie można zastąpić ustawień).

Możesz sam sprawdzić tabele routingu, otwierając command.exe(w systemie Windows):

C:\>route print

Przed połączeniem z VPN tabela routingu zawiera kluczowe wpisy, które pozwalają na prawidłowe działanie konfiguracji VirtualBox. Połączenie z VPN powoduje usunięcie tych wpisów, co uniemożliwia komunikację między hostem a gościem.

(Istnieje wiele innych pozycji, które tutaj pominąłem, ponieważ nie mają one związku z podstawową przyczyną tego zachowania).

Przed połączeniem z VPN:

     192.168.56.0    255.255.255.0         On-link      192.168.56.1    266
     192.168.56.1  255.255.255.255         On-link      192.168.56.1    266
   192.168.56.255  255.255.255.255         On-link      192.168.56.1    266
        224.0.0.0        240.0.0.0         On-link      192.168.56.1    266
  255.255.255.255  255.255.255.255         On-link      192.168.56.1    266

Po połączeniu z VPN:

     192.168.56.1  255.255.255.255         On-link      192.168.56.1    266
        224.0.0.0        240.0.0.0         On-link      192.168.56.1    266
  255.255.255.255  255.255.255.255         On-link      192.168.56.1    266

Klient VPN usuwa następujące linie:

     192.168.56.0    255.255.255.0         On-link      192.168.56.1    266
   192.168.56.255  255.255.255.255         On-link      192.168.56.1    266

Bez tych dwóch ostatnich wpisów host i gość nie mogą się komunikować i jest to dokładnie zamierzone zachowanie, gdy tunelowanie podzielone jest wyłączone w konfiguracji VPN.

Zwykle te dwa polecenia przywracają te trasy:

C:\>route ADD 192.168.56.0 MASK 255.255.255.0 192.168.56.1 METRIC 266
C:\>route ADD 192.168.56.255 MASK 255.255.255.255 192.168.56.1 METRIC 266

Ale klient VPN pozostaje czujny: przechwytuje próby modyfikacji tabeli routingu. Mój klient wydaje się zezwalać na drugie wejście, ale nie na pierwsze. (I może się to czasem pomijać; nie testowałem tego.)

Jeśli Twoja konkretna sieć VPN i towarzysząca jej konfiguracja pozwalają na włączenie tunelowania podzielonego, zazwyczaj jest ona włączana w następujący sposób:

Po rozłączeniu z VPN dobrze zachowani klienci VPN przywrócą tabele routingu, które były na miejscu przed połączeniem. Mój klient VPN wydaje się robić to niezawodnie, co jest korzystne, ponieważ oznacza, że nie trzeba ponownie uruchamiać maszyny wirtualnej gościa, gdy łączę się lub rozłączam z VPN. W takich przypadkach dodatkowy adapter maszyny wirtualnej jest resetowany, ale automatycznie odzyskuje swój adres IP automatycznie i przejrzyście, niemal natychmiast przywracając komunikację między hostem a gościem. Co więcej, podłączenia NFS między hostem a gościem (korzystam z podłączeń CIFS) pozostają połączone podczas operacji łączenia / rozłączania VPN.

W mało prawdopodobnym przypadku, gdy twoja sieć VPN zezwala na dzielone tunelowanie, może to być prosta kwestia włączenia go, w takim przypadku chciałbym usłyszeć od ciebie, czy „wszystko po prostu działa”.

Ben Johnson
źródło

Bardzo dziękuję za wysiłek włożony w tę odpowiedź (obrazy i wszystko). Bardzo pomogło ci to wyjaśnić!

Edenshaw

Dobra robota, Ben! To pomogło mi zrozumieć moje problemy z VPN i pomogło mi jasno przedstawić moją sprawę w moim zgłoszeniu do IT!

Mark Maglana,

Do Twojej dyspozycji mam dostęp do funkcji „Zezwól na dostęp lokalny (LAN)” w AnyConnect i mogę potwierdzić, że zaznaczenie tego pola wyboru nie zapobiega usunięciu tras.

Lqueryvg

virtualbox guest os przez VPN

Odpowiedzi:

Bez udziału VPN

Wpisz: VPN