Interfejs utun VPN na Macu aktywny, ale ruch nie przechodzi? Sprawdź ifconfig

Połączyłeś VPN, uruchomiłeś ifconfig i znalazłeś wpis utun4 z adresem. Strona, której potrzebowałeś, nadal kończy się przekroczeniem czasu. Ta luka jest normalna: lista dowodzi, że istnieje interfejs wirtualny, a nie że posiada go twój klient, że wybiera go trasa, która cię interesuje, ani że pakiety przez niego przechodzą. Przestałem ufać nazwie interfejsu po popołudniu spędzonym na obwinianiu niewłaściwego tunelu na laptopie, który miał już trzy wpisy utun, zanim cokolwiek zainstalowałem.

Co naprawdę zawiera wiersz utun

Uruchom ifconfig -a, gdy chcesz pełny obraz. Wywołane bez argumentów, ifconfig wypisuje tylko interfejsy, które są teraz aktywne, dlatego tunel, który nie wystartował, może brakować w danych wyjściowych, które ludzie wklejają do zgłoszeń. ifconfig -l zwraca tylko nazwy i to najszybszy sposób, by sprawdzić, czy po połączeniu pojawił się nowy utun.

Odczyt jednego interfejsu to miejsce, w którym mieszka przydatny szczegół, a połączony tunel zwykle wygląda tak.

utun4: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
    inet 10.8.0.6 --> 10.8.0.5 netmask 0xffffffff
    inet6 fe80::ce81:b1c:bd2c:69e%utun4 prefixlen 64 scopeid 0x15

Trzy pola niosą odpowiedź. UP i RUNNING mówią, że jądro jest gotowe użyć interfejsu. POINTOPOINT plus --> adres peera jest sygnaturą tunelu, a nie łącza fizycznego. mtu wartość wyjaśnia całą klasę zgłoszeń „łączy się, potem zastyga”, bo interfejsy utun zwykle wstają z obniżonym MTU, 1380 w kilku kompilacjach macOS, a klient może go nadpisać. Lista pól jest dość krótka, by przejrzeć ją raz w podręczniku ifconfig dostarczanym przez Apple.

Znajdź proces za interfejsem

ifconfig nie ma pojęcia aplikacji-właściciela. Dwa klienty VPN, usługa systemowa i tunel pozostały z zeszłego tygodnia tworzą wpisy, które na tym poziomie wyglądają identycznie. Na moim Macu utun0 do utun3 istniały, zanim cokolwiek skonfigurowałem; Continuity i iCloud Private Relay też używają tuneli i żaden z nich nie jest połączeniem, które diagnozujesz.

Dla tuneli, które rejestrują konfigurację w systemie, scutil --nc list jest najszybszą korelacją, wypisuje każdą konfigurację ze statusem i identyfikatorem usługi, a połączona jest tak oznaczona.

scutil --nc list
* (Connected)   5F2A9C10-...   VPN  Work IKEv2

Klienty, które prowadzą własny proces tunelu zamiast rejestrować konfigurację, nigdy się tam nie pojawiają. Tunnelblick i openvpn z linii poleceń należą do tej grupy, więc sprawdź też tabelę procesów: ps -Ao pid,comm | grep -i openvpn. Gdy proces posiada tunel, numer utun należy do tego procesu i do niczego innego.

Sprawdź adres, zanim sprawdzisz trasę

Interfejs może być aktywny bez użytecznego adresu. Profil tylko IPv6 pokazuje lokalny fe80:: wpis i nic w wierszu inet, a klient, któremu nie udało się zastosować wypchniętego adresu, zostawia dokładnie ten sam kształt. Jeśli twoim celem jest IPv4, a tunel nie ma adresu IPv4, kwestia routingu jest już rozstrzygnięta.

MTU zasługuje na osobną kontrolę, bo ta awaria nie wygląda na problem z rozmiarem. Wygląda jak połączenie, które się uwierzytelnia, a potem cichnie, gdy tylko zacznie się duży transfer. Wyślij sondę, której nie wolno fragmentować, o rozmiarze tak dobranym, by pakiet pasował do MTU interfejsu; przy MTU 1400 ładunek to 1372 bajty:

ping -D -s 1372 10.8.0.5

Odpowiedź oznacza, że pakiety tego rozmiaru przechodzą przez tunel. Cisza, gdy małe pingi się udają, wskazuje na MTU albo na coś, co po drodze zrzuca ICMP, a nie na uwierzytelnianie, które zakończyło się, zanim w ogóle dostałeś interfejs.

Udowodnij, że cel wybiera tunel

Pytanie, które się liczy, nie brzmi, czy utun4 istnieje, ale czy ruch do jednego konkretnego adresu wychodzi przez niego. route -n get odpowiada na to dla jednego celu i wypisuje bramę oraz interfejs, którego by użył:

route -n get 203.0.113.20
  gateway: 10.8.0.5
  interface: utun4

Jeśli ta sama komenda zgłasza en0, twoja konfiguracja split tunneling robi to, co jej kazano, i żadne oględziny interfejsu tego nie zmienią. Użyj netstat -rn -f inet, gdy potrzebujesz trasy domyślnej i całej tabeli w jednym widoku.

Liczniki rozstrzygają, czy pakiety naprawdę się ruszają. netstat -ib raportuje sumy pakietów i bajtów na interfejs, w tym wpisy utun; liczby są narastające, więc odczytaj je dwa razy z przerwą i porównaj:

netstat -ib | grep utun4

Zamrożone liczniki, gdy aplikacja wciąż ponawia próby, oznaczają, że jądro nigdy nie przekazało pakietu interfejsowi. Liczniki rosnące w obu kierunkach, gdy aplikacja nadal zawodzi, przenoszą śledztwo na drugi koniec tunelu.

Gdy utun w ogóle się nie pojawia

Pusta lista interfejsów po logowaniu, które wyglądało na udane, zwykle oznacza, że tunel nigdy nie wystartował, a nie że ifconfig go ukrywa. Sprawdź status klienta, potem systemu: Network Extension, który nigdy nie został zatwierdzony albo który macOS wyłączył po aktualizacji, nie zostawia interfejsu. Zatwierdzenie jest w Ustawieniach systemowych pod Elementy logowania i rozszerzenia, a nieaktualny wpis tam wart jest ponownego przełączenia, zanim cokolwiek przeinstalujesz.

Numeracja utun nie jest stabilna między ponownymi połączeniami. Możesz dostać utun5 tam, gdzie utun4 istniał dziesięć minut temu, bo stary interfejs jest rozbierany, a jądro wydaje następny wolny indeks. Skrypty, które zapisują nazwę na sztywno, psują się wtedy po cichu; dopasowuj zamiast tego adres albo trasę.

Trzymaj stronę odczytu tylko do odczytu. sudo ifconfig utun4 down przerywa tunel, a w profilu pełnego tunelu zabiera ze sobą twoją sesję zdalną, co jest kiepskim interesem, gdy tylko zbierałeś dowody. Nic z tego, czego tu potrzebujesz, nie wymaga roota: czytanie flag, adresów i liczników działa na zwykłym użytkowniku.

Następnym razem, gdy tunel na Macu się zbuntuje, wykonaj kontrole po kolei: potwierdź, że pojawił się utun przez ifconfig -l, odczytaj flagi, adresy i MTU, przypisz go do procesu, zapytaj route -n get, którego interfejsu używa cel, a potem obserwuj netstat -ib w ruchu. Każdy krok wyklucza inną warstwę, a pierwszy, który wróci błędnie, jest miejscem na poprawkę.