Mac VPN utun interfeysi işləyir, amma trafik getmir? ifconfig yoxlayın

VPN-ə qoşuldunuz, ifconfig işə saldınız və üzərində ünvan olan utun4 girişi tapdınız. Lazım olan sayt hələ də cavab vermir. Bu boşluq normaldır: siyahı virtual interfeysin mövcud olduğunu sübut edir, onu müştərinizin saxladığını, sizi maraqlandıran marşrutun onu seçdiyini və ya paketlərin ondan keçdiyini deyil. Heç nə quraşdırmadan əvvəl noutbukda artıq üç utun girişi olan bir maşında səhv tuneli günahlandırmaqla keçən bir günortadan sonra interfeys adına etibar etməyi dayandırdım.

utun sətrində əslində nə var

Tam mənzərəni görmək istədikdə ifconfig -a işə salın. Arqumentsiz çağırıldıqda ifconfig yalnız hazırda işlək olan interfeysləri çap edir, buna görə başlamayan tunel insanların biletdə yapışdırdığı çıxışdan yox ola bilər. ifconfig -l yalnız adları qaytarır və bu, qoşulduqdan sonra yeni utun görünüb-görünmədiyini anlamağın ən sürətli yoludur.

Bir interfeysi oxumaq faydalı təfərrüatın olduğu yerdir. Qoşulmuş tunel adətən belə görünür:

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

Üç sahə cavabı daşıyır. UP və RUNNING nüvənin interfeysdən istifadə etməyə hazır olduğunu bildirir. POINTOPOINT ilə qarşı tərəf ünvanı --> birlikdə fiziki əlaqə deyil, tunelin imzasıdır. mtu dəyəri «qoşulur, sonra dayanır» tipli hesabatların bütöv bir sinfini izah edir, çünki utun interfeysləri adətən azaldılmış MTU ilə qalxır, bir neçə macOS buraxılışında 1380, və müştəri onu üstələyə bilər. Sahə siyahısı Apple-ın verdiyi ifconfig təlimatında bir dəfə gözdən keçirmək üçün kifayət qədər qısadır.

İnterfeysin arxasındakı prosesi tapın

ifconfig-in sahib tətbiq anlayışı yoxdur. İki VPN müştərisi, bir sistem xidməti və keçən həftədən qalan tunel bu səviyyədə eyni görünən girişlər yaradır. Öz Mac-da heç nə qurmadan əvvəl utun0-dən utun3-ə qədər mövcud idi; Continuity və iCloud Private Relay da tunellərdən istifadə edir və heç biri sizin araşdırdığınız bağlantı deyil.

Sistemdə konfiqurasiya qeydiyyatdan keçirən tunellər üçün scutil --nc list ən sürətli uzlaşdırmadır. O, hər konfiqurasiyanı statusu və xidmət ID-si ilə çap edir, qoşulmuş olan isə belə işarələnir:

scutil --nc list
* (Connected)   5F2A9C10-...   VPN  Work IKEv2

Konfiqurasiya qeydiyyatdan keçirmək əvəzinə öz tunel prosesini işlədən müştərilər orada heç vaxt görünmür. Tunnelblick və əmr sətrindən işləyən openvpn nüsxəsi bu qrupa düşür, ona görə proses cədvəlinə də baxın: ps -Ao pid,comm | grep -i openvpn. Bir proses tunelə sahib olduqdan sonra utun nömrəsi yalnız həmin prosesə aiddir.

Marşrutu yoxlamadan əvvəl ünvanı yoxlayın

İnterfeys işlək, lakin istifadəyə yararlı ünvanı olmaya bilər. Yalnız IPv6 profili link-lokal fe80:: girişi göstərir və inet sətrində heç nə olmur, göndərilən ünvanı tətbiq edə bilməyən müştəri isə tam eyni formanı qoyub gedir. Əgər təyinatınız IPv4-dürsə və tunelin IPv4 ünvanı yoxdursa, marşrut məsələsi artıq həll olunub.

MTU ayrıca yoxlamağa dəyər, çünki nasazlıq ölçü problemi kimi görünmür. O, autentifikasiyadan keçən və böyük ötürmə başlayan kimi susan bağlantı kimi görünür. Parçalanmamalı olan, paketin interfeys MTU-suna uyğun ölçüdə bir zond göndərin; 1400 MTU üçün yük 1372 baytdır:

ping -D -s 1372 10.8.0.5

Cavab həmin ölçüdə paketlərin tuneldən keçdiyini bildirir. Kiçik ping-lər uğurlu olduğu halda səssizlik MTU-ya və ya yolda ICMP-ni atan bir şeyə işarə edir, autentifikasiyaya deyil, çünki o, siz interfeys əldə etməzdən əvvəl artıq tamamlanmışdı.

Təyinatın tuneli seçdiyini sübut edin

Vacib sual utun4-in mövcud olub-olmaması deyil, konkret bir ünvana gedən trafikin ondan keçib-keçməməsidir. route -n get bunu tək bir təyinat üçün cavablandırır və istifadə edəcəyi şlüzü və interfeysi çap edir:

route -n get 203.0.113.20
  gateway: 10.8.0.5
  interface: utun4

Eyni əmr en0 göstərirsə, split-tunnel konfiqurasiyanız ona deyiləni edir və heç bir interfeys yoxlaması bunu dəyişməyəcək. Defolt marşrutu və bütün cədvəli bir görünüşdə lazım olduqda netstat -rn -f inet istifadə edin.

Sayğaclar paketlərin həqiqətən hərəkət edib-etmədiyini həll edir. netstat -ib hər interfeys üzrə paket və bayt cəmlərini, utun girişləri də daxil olmaqla göstərir; rəqəmlər yığımlıdır, ona görə onları fasilə ilə iki dəfə oxuyun və müqayisə edin:

netstat -ib | grep utun4

Tətbiq təkrar cəhd etməyə davam edərkən donmuş sayğaclar nüvənin interfeysə heç vaxt paket vermədiyini bildirir. Tətbiq yenə uğursuz olarkən hər iki istiqamətdə artan sayğaclar araşdırmanı tunelin uzaq ucuna keçirir.

Heç bir utun görünmədikdə

Uğurlu görünən girişdən sonra boş interfeys siyahısı adətən tunelin heç başlamadığını bildirir, ifconfig-in onu gizlətməsini deyil. Əvvəlcə müştərinin öz statusunu, sonra sisteminkini yoxlayın: heç vaxt təsdiqlənməmiş və ya macOS-un yeniləmədən sonra söndürdüyü şəbəkə uzantısı arxasında interfeys qoymur. Təsdiq Sistem Parametrlərində Login Items & Extensions altındadır və oradakı köhnə girişi hər şeyi yenidən quraşdırmadan əvvəl bir dəfə yenidən açıb-bağlamağa dəyər.

utun nömrələnməsi yenidən qoşulmalar arasında sabit deyil. On dəqiqə əvvəl utun4 olan yerdə utun5 ala bilərsiniz, çünki köhnə interfeys sökülür və nüvə növbəti boş indeksi verir. Adı kodda bərkidən skriptlər həmin anda səssizcə sınır; əvəzinə ünvana və ya marşruta uyğunlaşdırın.

Oxuma tərəfini yalnız-oxuma saxlayın. sudo ifconfig utun4 down tuneli kəsir və tam tunel profilində uzaq sessiyanızı da aparır, bu isə yalnız sübut toplamağa çalışarkən pis mübadilədir. Burada lazım olan heç nə root tələb etmir: bayraqları, ünvanları və sayğacları oxumaq adi istifadəçi kimi işləyir.

Mac tuneli növbəti dəfə pis davrandıqda yoxlamaları sıra ilə aparın: ifconfig -l ilə utunun göründüyünü təsdiqləyin, bayraqlarını, ünvanlarını və MTU-nu oxuyun, onu bir prosesə aid edin, route -n get-dən təyinatın hansı interfeysi istifadə etdiyini soruşun, sonra netstat -ib-in hərəkətini izləyin. Hər addım fərqli bir təbəqəni istisna edir və səhv çıxan ilk addım düzəlişin yeri olur.