Połącz VPN, a VM deweloperska, która jeszcze minutę temu odpowiadała, milknie. Oczywista historia pisze się sama: tunel przejął trasę, host wysyła teraz ruch gościa do sieci firmowej, a rozwiązaniem jest dodanie trasy statycznej albo przełączenie adaptera w tryb mostu. Ta historia czasem jest prawdziwa. Ale to nie jest zwykła przyczyna, a działanie według niej najpierw zwykle psuje coś innego.

Sieć host-only to sieć programowa należąca do hosta i współdzielona z jego gośćmi, oddzielona od każdego połączenia fizycznego. Nic w interfejsie samego klienta VPN nie zmienia tej sieci, więc zanim jej dotkniesz, ustal, która z czterech warstw naprawdę zawiodła.

Trasa zwykle pozostaje lokalna

Zapytaj jądro, a nie pierwszą stronę tabeli routingu. W Linuksie ip route get 192.168.56.10 podaje dokładną trasę, interfejs i adres źródłowy, które zostałyby użyte, co jest inną odpowiedzią niż odczytanie trasy domyślnej i zgadywanie. Jeśli wynik wskazuje interfejs host-only, tunel w ogóle nie bierze udziału w tej ścieżce.

Dwie rzeczy mogą naprawdę to zepsuć i obie są problemami adresów, a nie VPN. Zdalna podsieć pokrywająca się z prefiksem host-only sprawia, że wygrywa bardziej szczegółowa trasa, a klient VPN instalujący szeroką trasę z niższą metryką może odebrać prefiks. Oba są widoczne w tym samym poleceniu: interfejs wskazany w wyniku będzie tunelem, a poprawka należy do tego, kto jest właścicielem tego planu adresów.

Wybór trasy i dopuszczenie pakietu to dwie różne decyzje

To część, którą model myślowy zwykle pomija. Nawet przy idealnej trasie lokalnej klient VPN może odrzucić pakiet. Wiele klientów stosuje politykę lokalnego dostępu do sieci, która decyduje, które cele są dozwolone poza tunelem, a podłączona podsieć nie aktualizuje tej listy automatycznie.

Dlatego awaria wygląda identycznie jak problem routingu z perspektywy aplikacji, a zupełnie inaczej z perspektywy klienta. Jeśli ip route get wskazuje właściwy interfejs, a połączenie nadal kończy się przekroczeniem czasu, przestań edytować trasy i zamiast tego przeczytaj udokumentowane zachowanie lokalnego dostępu klienta. Niektóre klienty oferują listę dozwolonych dla lokalnych podsieci, inne blokują wszystko, co nie jest tunelem, a jeszcze inne blokują tylko wtedy, gdy włączony jest kill switch.

To rozróżnienie ma znaczenie, bo poprawki nie są wymienne. Dodanie trasy nie zadowoli filtra, a wyłączenie filtra, by dotrzeć do jednego gościa, to znacznie większa decyzja, niż sugeruje objaw.

Gość ma trzy sposoby, by powiedzieć nie

Gość, który potrafi przeglądać internet, niczego nie dowodzi w kwestii usługi, której chcesz. Nasłuch może być w gościu powiązany z 127.0.0.1 i wtedy żadne żądanie z hosta nie dotrze, choćby ścieżka była idealna. Sprawdź to w gościu poleceniem ss -ltn i zajrzyj do kolumny adresu lokalnego, a nie tylko do portu.

Następny jest własny firewall gościa. Obraz deweloperski z restrykcyjnym ustawieniem domyślnym może przyjąć pakiety hosta i odrzucić je na granicy usługi, co daje przekroczenie czasu wyglądające dokładnie jak czarna dziura routingu. Wreszcie jest konfiguracja samej usługi: aplikacja webowa przypisana do konkretnej nazwy hosta albo lista dozwolonych adresów klientów odrzuci żądanie z podsieci host-only, nawet gdy dotrze każdy pakiet.

Przejdź te trzy punkty, zanim pomyślisz o zmianie trybu sieci VM. Każdy jest mniejszą zmianą niż przeprojektowanie połączenia gościa i każdy ma jasny test.

Czym naprawdę jest most i ile kosztuje

Przełączenie adaptera w tryb mostu nie jest naprawą ścieżki host-only. To decyzja o umieszczeniu gościa w innej sieci, zwykle w fizycznej sieci LAN, gdzie staje się widoczny dla wszystkiego innego, co tam żyje. To może być dokładnie to, czego chcesz. Ale to nie jest to, co robiła pierwotna konfiguracja.

Użyj go, gdy gość naprawdę musi być równorzędnym uczestnikiem tej sieci LAN, a ekspozycja jest zatwierdzona. Nie używaj go dlatego, że jedna usługa przestała odpowiadać, ponieważ zmiana może wyprowadzić gościa z izolacji, która czyniła rozwój wobec niego bezpiecznym.

Po każdej zatwierdzonej poprawce testuj w stałej kolejności: nowe żądanie z hosta do gościa, wymagany zasób firmowy przez tunel i zamierzone zachowanie odmowy przy wyłączonym tunelu. Jeśli ostatnie już nie zachodzi, poprawka wykroczyła poza problem.

Sekcja VirtualBox o sieci host-only opisuje interfejs programowy po stronie hosta i to, czym różni się od połączenia mostem, i to jest odniesienie, które warto przeczytać, zanim uzna się oba tryby za wymienne.

Powiązane artykuły