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