Mac VPN utun saskarne ir aktīva, bet trafiks neiet? Pārbaudiet ifconfig

Jūs pieslēdzāt VPN, palaidāt ifconfig un atradāt utun4 ierakstu ar adresi. Vietne, kas jums bija vajadzīga, joprojām beidzas ar taimautu. Šī plaisa ir normāla: saraksts pierāda, ka virtuālā saskarne pastāv, nevis to, ka to pārvalda jūsu klients, ka jums svarīgais maršruts to izvēlas vai ka paketes to šķērso. Es pārstāju uzticēties saskarnes nosaukumam pēc tam, kad visu pēcpusdienu vainoju nepareizo tuneli klēpjdatorā, kuram jau pirms jebkā instalēšanas bija trīs utun ieraksti.

Ko patiesībā satur utun rinda

Palaidiet ifconfig -a, kad vēlaties pilnu ainu. Izsaukta bez argumentiem, ifconfig izdrukā tikai saskarnes, kas šobrīd ir aktīvas, tāpēc tunelis, kas neizdevās palaist, var trūkt izvadē, ko cilvēki ielīmē biļetēs. ifconfig -l atgriež tikai nosaukumus, un tas ir ātrākais veids, kā noskaidrot, vai pēc pieslēgšanās parādījās jauns utun.

Vienas saskarnes lasīšana ir vieta, kur slēpjas noderīgā detaļa, un pieslēgts tunelis parasti izskatās šādi.

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

Trīs lauki nes atbildi. UP un RUNNING saka, ka kodols ir gatavs izmantot saskarni. POINTOPOINT plus --> vienaudža adrese ir tuneļa, nevis fiziskas saites paraksts. mtu vērtība izskaidro visu klasi "pieslēdzas, tad iestrēgst" ziņojumu, jo utun saskarnes parasti ceļas ar samazinātu MTU, 1380 vairākās macOS versijās, un klients to var pārsniegt. Lauku saraksts ir pietiekami īss, lai vienreiz pārskatītu Apple pievienoto ifconfig rokasgrāmatu.

Atrodiet saskarnes aizmugurē esošo procesu

ifconfig nav īpašnieka lietotnes jēdziena. Divi VPN klienti, sistēmas pakalpojums un pagājušās nedēļas atlikušais tunelis rada ierakstus, kas šajā līmenī izskatās identiski. Manā Mac datorā utun0 līdz utun3 pastāvēja pirms tam, kad kaut ko konfigurēju; Continuity un iCloud Private Relay arī izmanto tuneļus, un neviens no tiem nav savienojums, kuru jūs diagnosticējat.

Tuneļiem, kas reģistrē konfigurāciju sistēmā, scutil --nc list ir ātrākā korelācija, tā izdrukā katru konfigurāciju ar tās statusu un pakalpojuma ID, un pieslēgtā tiek atzīmēta kā tāda.

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

Klienti, kas vada savu tuneļa procesu, nevis reģistrē konfigurāciju, tur nekad neparādās. Tunnelblick un komandrindas openvpn instance ietilpst šajā grupā, tāpēc pārbaudiet arī procesu tabulu: ps -Ao pid,comm | grep -i openvpn. Kad process pārvalda tuneli, utun numurs pieder tikai šim procesam un nekam citam.

Pārbaudiet adresi pirms maršruta pārbaudes

Saskarne var būt aktīva bez lietojamas adreses. Tikai IPv6 profils rāda saites lokālo fe80:: ierakstu un neko inet rindā, un klients, kuram neizdevās piemērot piespiesto adresi, atstāj tieši tādu pašu formu. Ja jūsu galamērķis ir IPv4 un tunelim nav IPv4 adreses, maršrutēšanas jautājums jau ir izlemts.

MTU ir pelnījis atsevišķu pārbaudi, jo šī kļūme neizskatās pēc izmēra problēmas. Tā izskatās pēc savienojuma, kas autentificējas un pēc tam apklust, tiklīdz sākas liela pārsūtīšana. Nosūtiet zondi, kuru nedrīkst fragmentēt, tādā izmērā, lai pakete atbilstu saskarnes MTU; ja MTU ir 1400, lietderīgā slodze ir 1372 baiti:

ping -D -s 1372 10.8.0.5

Atbilde nozīmē, ka šāda izmēra paketes šķērso tuneli. Klusums, kamēr mazie pingi izdodas, norāda uz MTU vai uz kaut ko, kas ceļā nomet ICMP, nevis uz autentifikāciju, kas jau bija pabeigta pirms saskarnes iegūšanas.

Pierādiet, ka galamērķis izvēlas tuneli

Svarīgais jautājums nav, vai utun4 pastāv, bet gan, vai trafiks uz vienu konkrētu adresi iziet caur to. route -n get atbild uz to vienam galamērķim un izdrukā vārteju un saskarni, ko tas izmantotu:

route -n get 203.0.113.20
  gateway: 10.8.0.5
  interface: utun4

Ja tā pati komanda ziņo en0, jūsu split tunneling konfigurācija dara to, kas tai teikts, un nekāda saskarnes pārbaude to nemainīs. Izmantojiet netstat -rn -f inet, kad jums vajag noklusējuma maršrutu un visu tabulu vienā skatā.

Skaitītāji izšķir, vai paketes tiešām kustas. netstat -ib ziņo pakešu un baitu kopsummas pa saskarnēm, ieskaitot utun ierakstus; skaitļi ir kumulatīvi, tāpēc nolasiet tos divreiz ar pārtraukumu un salīdziniet:

netstat -ib | grep utun4

Iesaldēti skaitītāji, kamēr lietotne turpina mēģināt, nozīmē, ka kodols nekad nav nodevis paketi saskarnei. Skaitītāji, kas aug abos virzienos, kamēr lietotne joprojām cieš neveiksmi, pārceļ izmeklēšanu uz tuneļa tālo galu.

Kad utun neparādās vispār

Tukšs saskarņu saraksts pēc pieteikšanās, kas izskatījās veiksmīga, parasti nozīmē, ka tunelis nekad nav startējis, nevis to, ka ifconfig to slēpj. Pārbaudiet klienta statusu, pēc tam sistēmas: Network Extension, kas nekad netika apstiprināts vai ko macOS atslēdza pēc atjauninājuma, neatstāj saskarni. Apstiprinājums atrodas System Settings sadaļā Login Items & Extensions, un novecojis ieraksts tur ir pārslēgšanas vērts pirms kaut kā pārinstalēšanas.

utun numerācija nav stabila starp atkārtotām pieslēgšanās reizēm. Jūs varat iegūt utun5 tur, kur utun4 pastāvēja pirms desmit minūtēm, jo vecā saskarne tiek nojaukta un kodols izsniedz nākamo brīvo indeksu. Skripti, kas nosaukumu ieraksta cieti, tajā brīdī klusi salūzt; tā vietā saskaņojiet pēc adreses vai maršruta.

Turiet lasīšanas pusi tikai lasāmā stāvoklī. sudo ifconfig utun4 down pārtrauc tuneli, un pilna tuneļa profilā tas paņem līdzi arī jūsu attālo sesiju, kas ir slikts darījums, ja jūs tikai vācāt pierādījumus. Nekas, kas jums šeit vajadzīgs, neprasa root: karogu, adrešu un skaitītāju lasīšana darbojas ar jūsu parasto lietotāju.

Nākamreiz, kad Mac tunelis uzvedas nepareizi, veiciet pārbaudes pēc kārtas: apstipriniet, ka parādījās utun ar ifconfig -l, izlasiet tā karogus, adreses un MTU, piešķiriet to procesam, pajautājiet route -n get, kuru saskarni izmanto galamērķis, tad vērojiet netstat -ib kustību. Katrs solis izslēdz citu slāni, un pirmais, kas atgriežas nepareizi, ir vieta, kur jāveic labojums.