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 менен көтөрүлөт, 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 кыймылын байкаңыз. Ар бир кадам башка катмарды жокко чыгарат, ал эми биринчи туура эмес кайткан жер — оңдоо керек болгон жер.

Тектеш макалалар