Mac VPN utun интерфејс је активан, али саобраћај не пролази? Проверите 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 је најбржа корелација, исписује сваку конфигурацију са њеним статусом и ID-ом услуге, а повезана је тако означена.

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

Одговор значи да пакети те величине пролазе кроз тунел. Тишина док мали пингови успевају указује на MTU или на нешто што на путу одбацује ICMP, а не на аутентификацију, која је већ била завршена пре него што сте уопште добили интерфејс.

Докажите да одредиште бира тунел

Питање које је важно није да ли utun4 постоји, већ да ли саобраћај ка једној конкретној адреси излази кроз њега. route -n get одговара на то за једно одредиште и исписује мрежни пролаз и интерфејс које би користио:

route -n get 203.0.113.20
  gateway: 10.8.0.5
  interface: utun4

Ако иста команда пријави en0, ваша split tunneling конфигурација ради оно што јој је речено и никакав преглед интерфејса то неће променити. Користите netstat -rn -f inet када вам требају подразумевана рута и цела табела у једном прегледу.

Бројачи одлучују да ли се пакети заиста крећу. netstat -ib пријављује укупне пакете и бајтове по интерфејсу, укључујући utun уносе; бројеви су кумулативни, па их прочитајте двапут са паузом и упоредите:

netstat -ib | grep utun4

Замрзнути бројачи док апликација наставља да покушава значе да кернел никада није предао пакет интерфејсу. Бројачи који расту у оба смера док апликација још увек не успева премештају истрагу на други крај тунела.

Када се utun уопште не појави

Празна листа интерфејса након пријаве која је изгледала успешно обично значи да тунел никада није покренут, а не да ifconfig га скрива. Проверите статус клијента, затим система: Network Extension који никада није одобрен или који је macOS искључио након ажурирања не оставља интерфејс. Одобрење је у System Settings под Login Items & Extensions, а застарео унос тамо вреди поновног пребацивања пре него што било шта поново инсталирате.

utun нумерација није стабилна између поновних повезивања. Можете добити utun5 тамо где је utun4 постојао пре десет минута, јер се стари интерфејс разграђује и кернел додељује следећи слободан индекс. Скрипте које име уписују чврсто тихо се ломе у том тренутку; уместо тога упарујте по адреси или по рути.

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

Следећи пут када се Mac тунел буде лоше понашао, урадите провере по реду: потврдите да се utun појавио са ifconfig -l, прочитајте његове заставице, адресе и MTU, припишите га процесу, питајте route -n get који интерфејс користи одредиште, а затим гледајте како netstat -ib се креће. Сваки корак искључује други слој, а први који се врати погрешно је место где поправка припада.

Повезани чланци