Интерфейс utun на Mac VPN е активен, но трафикът не минава? Проверете ifconfig

ifconfig показва име utun, адрес и MTU, но не кое приложение го притежава и накъде отиват пакетите. Пет проверки само за четене, които отговарят на истинския въпрос.

Свързахте VPN, пуснахте ifconfig и намерихте запис utun4 с адрес върху него. Сайтът, който ви трябваше, все още не отговаря. Тази разлика е нормална: списъкът доказва, че съществува виртуален интерфейс, а не че вашият клиент го притежава, че маршрутът, който ви интересува, го избира или че пакетите минават през него. Спрях да се доверявам на името на интерфейса след един следобед, прекаран в обвиняване на грешния тунел на лаптоп, който вече имаше три записа utun, преди да съм инсталирал каквото и да е.

Какво всъщност съдържа един ред utun

Пуснете ifconfig -a, когато искате цялата картина. Извикан без аргументи, ifconfig отпечатва само интерфейсите, които са активни в момента, и затова тунел, който не е стартирал, може да липсва от изхода, който хората поставят в тикети. ifconfig -l връща само имената и това е най-бързият начин да разберете дали след свързването се е появил нов utun.

Четенето на един интерфейс е мястото, където живеят полезните подробности. Свързан тунел обикновено изглежда така:

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

Три полета носят отговора. UP и RUNNING казват, че ядрото е готово да използва интерфейса. POINTOPOINT плюс адресът на партньора --> е подписът на тунел, а не на физическа връзка. Стойността mtu обяснява цял клас доклади „свързва се, после застива“, защото интерфейсите utun обикновено се вдигат с намален MTU, 1380 в няколко сборки на macOS, и клиентът може да го надхвърли. Списъкът с полета е достатъчно кратък, за да го прегледате веднъж в ръководството за ifconfig, което Apple доставя.

Намерете процеса зад интерфейса

ifconfig няма понятие за притежаващо приложение. Два VPN клиента, системна услуга и остатъчен тунел от миналата седмица създават записи, които на това ниво изглеждат идентични. На моя Mac записите utun0 до utun3 съществуваха, преди да настроя каквото и да е; Continuity и iCloud Private Relay също използват тунели и нито един от тях не е връзката, която изследвате.

За тунелите, които регистрират конфигурация в системата, scutil --nc list е най-бързата връзка. Той отпечатва всяка конфигурация със статуса и идентификатора на услугата ѝ, а свързаната се отбелязва така:

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

Клиентите, които пускат собствен процес за тунела вместо да регистрират конфигурация, никога не се появяват там. Tunnelblick и инстанция на openvpn от командния ред попадат в тази група, затова проверете и таблицата с процеси: ps -Ao pid,comm | grep -i openvpn. Щом даден процес притежава тунела, номерът utun принадлежи на този процес и на никой друг.

Проверете адреса, преди да проверите маршрута

Един интерфейс може да е активен без използваем адрес. Профил само с IPv6 показва запис fe80::, локален за връзката, и нищо в реда inet, а клиент, който не е успял да приложи изпратен адрес, оставя точно същата форма. Ако дестинацията ви е IPv4, а тунелът няма адрес IPv4, въпросът с маршрутизацията вече е решен.

MTU заслужава отделна проверка, защото отказът не изглежда като проблем с размера. Той изглежда като връзка, която се удостоверява и после замлъква, щом започне голям трансфер. Изпратете проба, която не бива да се фрагментира, с размер, при който пакетът съвпада с MTU на интерфейса; при MTU 1400 полезният товар е 1372 байта:

ping -D -s 1372 10.8.0.5

Отговор означава, че пакети с такъв размер преминават през тунела. Тишината, докато малките ping-ове успяват, сочи към MTU или към нещо, което изхвърля ICMP по пътя, а не към удостоверяването, което вече е приключило, преди изобщо да получите интерфейс.

Докажете, че дестинацията избира тунела

Важният въпрос не е дали utun4 съществува, а дали трафикът към един конкретен адрес излиза през него. route -n get отговаря на това за една дестинация и отпечатва шлюза и интерфейса, които би използвал:

route -n get 203.0.113.20
  gateway: 10.8.0.5
  interface: utun4

Ако същата команда съобщи en0, вашата конфигурация на разделен тунел прави това, което ѝ е казано, и никакво количество проверки на интерфейса няма да го промени. Използвайте netstat -rn -f inet, когато ви трябват маршрутът по подразбиране и цялата таблица в един изглед.

Броячите решават дали пакетите наистина се движат. netstat -ib отчита общите бройки пакети и байтове за всеки интерфейс, включително записите utun; числата са натрупващи се, затова ги прочетете два пъти с пауза и сравнете:

netstat -ib | grep utun4

Замръзнали броячи, докато приложението продължава да опитва, означават, че ядрото никога не е предало пакет на интерфейса. Броячи, които растат в двете посоки, докато приложението все още се проваля, преместват разследването към далечния край на тунела.

Когато изобщо не се появи utun

Празен списък с интерфейси след вход, който е изглеждал успешен, обикновено означава, че тунелът не е стартирал, а не че ifconfig го крие. Проверете собствения статус на клиента, после този на системата: мрежово разширение, което никога не е било одобрено или което macOS е изключил след актуализация, не оставя интерфейс след себе си. Одобрението живее в Системни настройки под Login Items & Extensions и един остарял запис там си струва да бъде превключен отново, преди да преинсталирате каквото и да е.

Номерацията на utun не е стабилна между повторните свързвания. Можете да получите utun5 там, където преди десет минути е имало utun4, защото старият интерфейс се разрушава и ядрото дава следващия свободен индекс. Скриптове, които твърдо записват име, се чупят тихо в този момент; съпоставяйте по адреса или по маршрута.

Дръжте страната за четене само за четене. sudo ifconfig utun4 down прекъсва тунела и при профил с пълен тунел отнася със себе си отдалечената ви сесия, което е лоша размяна, когато просто сте събирали доказателства. Нищо нужно тук не изисква root: четенето на флагове, адреси и броячи работи като обикновен потребител.

Следващия път, когато тунел на Mac се държи зле, изпълнете проверките по ред: потвърдете, че се е появил utun с ifconfig -l, прочетете флаговете, адресите и MTU, припишете го на процес, попитайте route -n get кой интерфейс използва дестинацията и после гледайте как се движи netstat -ib. Всяка стъпка изключва различен слой и първата, която се върне грешна, е мястото на поправката.

Подобни статии