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 хөдөлгөөнийг ажигла. Алхам бүр өөр давхаргыг үгүйсгэдэг бөгөөд хамгийн түрүүнд буруу гарч ирсэн нь засвар хийх ёстой газар юм.