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-мен көтеріледі, macOS-тың бірнеше құрастырмасында 1380, ал клиент оны басып кетуі мүмкін. Өрістер тізімі қысқа, сондықтан Apple ұсынатын ifconfig нұсқаулығына бір рет көз жүгіртіп шығу жеткілікті.

Интерфейстің артындағы процесті табыңыз

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 оны жасырып тұрған жоқ. Клиенттің өз күйін, содан кейін жүйенің күйін тексеріңіз: ешқашан мақұлданбаған немесе macOS жаңартудан кейін өшірген Network Extension артында интерфейс қалдырмайды. Рұқсат System Settings ішінде, Login Items & Extensions астында тұрады, және ондағы ескірген жазбаны бірдеңені қайта орнатудан бұрын қайта қосуға тұрарлық.

utun нөмірлеуі қайта қосылулар арасында тұрақты емес. Он минут бұрын utun5 болған жерде utun4 алуыңыз мүмкін, өйткені ескі интерфейс бұзылады да, ядро келесі бос индексті береді. Атауын қатты жазып қойған скрипттер сол сәтте үнсіз бұзылады; оның орнына мекенжайға немесе маршрутқа сәйкестендіріңіз.

Оқу жағын тек оқуға арналған күйде ұстаңыз. sudo ifconfig utun4 down туннельді үзеді, ал толық туннель профилінде қашықтағы сессияңызды да алып кетеді, бұл тек дәлел жинап жүргенде нашар айырбас. Мұнда керекті ештеңе root талап етпейді: жалауларды, мекенжайларды және санауыштарды оқу қалыпты пайдаланушыңызбен жұмыс істейді.

Mac туннелі келесі жолы дұрыс істемесе, тексерістерді ретімен орындаңыз: растаңыз, utun шықты ма ifconfig -l арқылы, оның жалауларын, мекенжайларын және MTU-ін оқыңыз, оны процеске теліңіз, route -n get арқылы мақсат қай интерфейсті пайдаланатынын сұраңыз, содан кейін netstat -ib қозғалысын бақылаңыз. Әр қадам түрлі қабатты жоққа шығарады, ал бірінші қате қайтатын қадам — түзету керек жер.