Інтэрфейс utun у VPN на Mac узняты, але трафік не ідзе? Праверце ifconfig

Вы падключылі 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. Кожны крок выключае іншы пласт, і першы, які вяртаецца з памылкай, — гэта месца выпраўлення.