Maszyna Vagrant VM znika po połączeniu VPN: czyja trasa się zepsuła

Maszyna odpowiadała minutę temu, VPN się połączył i teraz ten sam adres kończy się przekroczeniem czasu. Trzy usterki dają ten objaw i mieszkają na różnych maszynach. Host może stracić trasę do sieci prywatnej, zakres NAT gościa może kolidować z zakresem, który tunel teraz ogłasza, albo pełny tunel może przejąć własność każdej trasy na hoście. Ustal, która z nich wystąpiła, zanim zmienisz jakąkolwiek konfigurację, bo każda naprawa mieszka gdzie indziej.

Patrz na trasę, nie na maszynę

Spójrz na decyzję routingu hosta dla adresu gościa, gdy tunel jest podniesiony. Trasa, która nadal wskazuje na adapter tylko-host, nie jest problemem. Trasa, która teraz wskazuje na adapter VPN, jest problemem, i to klient ją zmienił, nie ty. To, że adapter zachowuje swój adres, mówi, że interfejs przetrwał, co jest innym faktem niż przetrwanie ścieżki.

Sesja SSH, która pada dokładnie w momencie połączenia, jest oczekiwanym zachowaniem. Klient recyklinguje adaptery i instaluje trasy, więc połączenie umiera na kilka sekund. Usterką jest połączenie, które nigdy nie wraca, nie to, które tylko mrugnęło.

Przechwyć tabelę przed tunelem i jeszcze raz po nim, a potem porównaj oba wyjścia. Różnica jest diagnozą, a zarazem dowodem, o który poprosi właściciel sieci.

ip -4 route get 192.168.56.10
ip -brief addr show
ip route show table main | head -20

Odczytaj tabelę hosta przed i po

W Linuksie pierwszeństwo między nakładającymi się trasami wynika z długości prefiksu i metryki, więc bardziej szczegółowa trasa VPN wygrywa, nawet gdy jest błędna. W Windows o remisie decyduje metryka interfejsu, a adapter tunelu zwykle przychodzi z niższą metryką niż wirtualny. W obu przypadkach widoczny objaw jest identyczny: pakiety wychodzą przez adapter tunelu i znikają.

Wypisz adaptery i ich metryki obok trasy dla prefiksu gościa. Ta para wyjść odpowiada na pytanie o własność jednym spojrzeniem.

Get-NetAdapter | Select-Object Name, InterfaceIndex, InterfaceMetric
Get-NetRoute -DestinationPrefix 192.168.56.0/24
route print -4 | Select-String '192.168.56'

Jeśli trasa się zmieniła, a metryka adaptera nie, klient zainstalował konkurencyjną trasę. Jeśli metryka się zmieniła, klient przestawił adaptery. Oba da się naprawić, i naprawia się je w różnych miejscach.

Gdy zakres NAT gościa jest kolizją

VirtualBox NAT domyślnie używa 10.0.2.0/24, a tunel, który wypycha ten sam zakres, sprawia, że gość wysyła ten ruch do swojej bramy NAT zamiast do rzeczywistego celu. Pakiet nigdy nie opuszcza hosta, więc żaden log zapory po drugiej stronie go nie pokaże. Docker Machine ma tę samą klasę konfliktu w swoim planie tylko-host, a zmiana tego planu może wymagać odtworzenia maszyny wraz z jej certyfikatami.

Wybierz zamiennik, wypisując, co tunel już ogłasza, potem czego używa sieć biurowa, a potem co zgłosił każdy wirtualny adapter na tym hoście. Routing psuje nakładanie się, a podobieństwo nie ma znaczenia. Jeden zakres może leżeć całkowicie wewnątrz innego, choć na pierwszy rzut oka wcale nie wyglądają podobnie.

Ustaw nowy zakres przy tworzeniu maszyny albo zmień go i przeładuj, a potem ponownie przetestuj zawodne połączenie z gościa. Liczy się tabela samego gościa.

VBoxManage modifyvm devbox --natnet1 10.77.0.0/24
vagrant reload devbox --provision
vagrant ssh devbox -c 'ip route get 10.20.0.15'

Przywróć ścieżkę, nie walcząc z klientem

Każda platforma daje sposób, by znów wysunąć prefiks tylko-host na pierwszy plan. W macOS trasa statyczna do interfejsu tylko-host działa do następnego połączenia. W Windows niższa metryka interfejsu na adapterze wirtualnym utrzymuje go jako preferowany. W Linuksie operacja zamiany obejmuje jeden prefiks. Wszystkie trzy są obejściami, bo klient, który znów egzekwuje swoje trasy, je cofnie.

Oskryptuj sprawdzanie zamiast ślepego ponownego łączenia przy starcie. Mały skrypt, który po każdym połączeniu wypisuje trasę dla prefiksu gościa, zamienia zagadkę w wiersz w logu.

Jeśli profil to pełny tunel, poproś właściciela sieci o tunelowanie dzielone albo udokumentowany wyjątek. Ciche dodawanie tras omijających politykę bezpieczeństwa nie jest naprawą, to drugi problem, który przyjdzie później z audytorem.

Sprawdź naprawę po obu stronach

Po zmianie zweryfikuj trzy ścieżki: host do gościa, gość do hosta firmowego i gość do internetu. Naprawa, która przywraca jedną i psuje inną, jest zmianą konfiguracji przebraną za remont. Przechwyć te same wyjścia, które zebrałeś przed zmianą, żeby porównanie było jak z jak.

Zapisz interfejs, metrykę i trasę, które się zmieniły, razem z czasem, żeby następny przypadek był wyszukaniem, a nie odbudową. Ta notatka jest warta więcej niż długi wątek zgłoszenia.

ip -4 route get 192.168.56.10
traceroute -n -m 4 10.20.0.15
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

Gdy host znów dociera do gościa, a gość dociera do LAN-u, przywróciłeś ścieżkę, od której zacząłeś. Gdy działa tylko jedno z tych, pozostała usterka jest na terenie drugiego właściciela, a różnica mówi ci, na którym.