Mac VPN utun sąsaja aktyvi, bet srautas neveikia? Patikrinkite ifconfig

Prisijungėte VPN, paleidote ifconfig, ir radote utun4 įrašą su adresu. Svetainė, kurios jums reikėjo, vis dar baigiasi skirtuoju laiku. Šis tarpas yra normalus: sąrašas įrodo, kad virtuali sąsaja egzistuoja, o ne tai, kad ją valdo jūsų klientas, kad jums svarbus maršrutas ją pasirenka ar kad paketai ja keliauja. Nustojau pasitikėti sąsajos pavadinimu po to, kai visą popietę kaltinau netinkamą tunelį nešiojamajame kompiuteryje, kuriame dar prieš ką nors įdiegiant jau buvo trys utun įrašai.

Ką iš tikrųjų turi utun eilutė

Paleiskite ifconfig -a, kai norite viso vaizdo. Iškviesta be argumentų, ifconfig spausdina tik šiuo metu aktyvias sąsajas, todėl tunelis, kuris nepavyko paleisti, gali trūkti išvestyje, kurią žmonės įklijuoja į bilietus. ifconfig -l grąžina tik pavadinimus, ir tai greičiausias būdas sužinoti, ar po prisijungimo atsirado naujas utun.

Vienos sąsajos skaitymas yra vieta, kurioje slypi naudinga informacija, o prisijungęs tunelis paprastai atrodo taip.

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

Trys laukai neša atsakymą. UP ir RUNNING sako, kad branduolys pasirengęs naudoti sąsają. POINTOPOINT plius --> tarpusavio adresas yra tunelio, o ne fizinės jungties parašas. mtu reikšmė paaiškina visą klasę pranešimų „prisijungia, tada užstringa“, nes utun sąsajos paprastai keliasi su sumažintu MTU, 1380 keliose macOS versijose, ir klientas gali jį viršyti. Laukų sąrašas pakankamai trumpas, kad vieną kartą peržiūrėtumėte Apple pridedamą ifconfig vadovą.

Raskite procesą už sąsajos

ifconfig neturi savininko programėlės sąvokos. Du VPN klientai, sistemos paslauga ir praėjusios savaitės likęs tunelis sukuria įrašus, kurie šiame lygmenyje atrodo identiškai. Mano pačio Mac kompiuteryje utun0 iki utun3 egzistavo prieš tai, kai ką nors sukonfigūravau; Continuity ir iCloud Private Relay taip pat naudoja tunelius, ir nė vienas iš jų nėra ryšys, kurį diagnozuojate.

Tuneliams, kurie registruoja konfigūraciją sistemoje, scutil --nc list yra greičiausia koreliacija, ji spausdina kiekvieną konfigūraciją su jos būsena ir paslaugos ID, o prisijungusi pažymima kaip tokia.

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

Klientai, kurie vykdo savo tunelio procesą, o ne registruoja konfigūraciją, ten niekada nepasireiškia. Tunnelblick ir komandinės eilutės openvpn egzempliorius patenka į tą grupę, todėl patikrinkite ir procesų lentelę: ps -Ao pid,comm | grep -i openvpn. Kai procesas valdo tunelį, utun numeris priklauso tik tam procesui ir niekam kitam.

Patikrinkite adresą prieš tikrindami maršrutą

Sąsaja gali būti aktyvi be tinkamo adreso. Tik IPv6 profilis rodo susietąjį fe80:: įrašą ir nieko inet eilutėje, o klientas, kuriam nepavyko pritaikyti stumiamo adreso, palieka lygiai tokią pačią formą. Jei jūsų paskirties vieta yra IPv4, o tunelis neturi IPv4 adreso, maršrutizavimo klausimas jau išspręstas.

MTU nusipelno atskiro patikrinimo, nes šis gedimas neatrodo kaip dydžio problema. Jis atrodo kaip ryšys, kuris autentifikuojasi ir tada nutyla, kai tik prasideda didelis perdavimas. Siųskite zondą, kuris neturi būti fragmentuojamas, tokio dydžio, kad paketas atitiktų sąsajos MTU; kai MTU yra 1400, naudingoji apkrova yra 1372 baitai:

ping -D -s 1372 10.8.0.5

Atsakymas reiškia, kad tokio dydžio paketai keliauja tuneliu. Tyla, kai maži pingai pavyksta, nurodo MTU arba kažką, kas kelyje numeta ICMP, o ne autentifikaciją, kuri jau buvo baigta prieš tai, kai gavote sąsają.

Įrodykite, kad paskirties vieta pasirenka tunelį

Svarbus klausimas yra ne tai, ar utun4 egzistuoja, o tai, ar srautas į vieną konkretų adresą išeina per jį. route -n get atsako į tai vienai paskirties vietai ir spausdina tinklų sietuvą bei sąsają, kurią naudotų:

route -n get 203.0.113.20
  gateway: 10.8.0.5
  interface: utun4

Jei ta pati komanda praneša en0, jūsų split tunneling konfigūracija daro tai, kas jai pasakyta, ir joks sąsajos tikrinimas to nepakeis. Naudokite netstat -rn -f inet, kai jums reikia numatytojo maršruto ir visos lentelės viename vaizde.

Skaitikliai nusprendžia, ar paketai tikrai juda. netstat -ib praneša paketų ir baitų sumas pagal sąsają, įskaitant utun įrašus; skaičiai yra kaupiamieji, todėl perskaitykite juos du kartus su pertrauka ir palyginkite:

netstat -ib | grep utun4

Sušalę skaitikliai, kol programėlė vis bando iš naujo, reiškia, kad branduolys niekada neperdavė paketo sąsajai. Skaitikliai, kylantys abiem kryptimis, kol programėlė vis dar nepavyksta, perkelia tyrimą į kitą tunelio galą.

Kai utun visai nepasirodo

Tuščias sąsajų sąrašas po prisijungimo, kuris atrodė sėkmingas, paprastai reiškia, kad tunelis niekada nebuvo paleistas, o ne tai, kad ifconfig jį slepia. Patikrinkite kliento būseną, tada sistemos: Network Extension, kuri niekada nebuvo patvirtinta arba kurią macOS išjungė po atnaujinimo, nepalieka jokios sąsajos. Patvirtinimas yra System Settings, skiltyje Login Items & Extensions, o pasenęs įrašas ten yra vertas perjungimo iš naujo prieš ką nors perinstaliuojant.

utun numeracija nėra stabili per prisijungimus iš naujo. Galite gauti utun5 ten, kur utun4 egzistavo prieš dešimt minučių, nes sena sąsaja išardoma, o branduolys išduoda kitą laisvą indeksą. Skriptai, kurie pavadinimą įrašo kietai, tą akimirką tyliai sugenda; vietoj to derinkite pagal adresą arba maršrutą.

Laikykite skaitymo pusę tik skaitymui. sudo ifconfig utun4 down pertraukia tunelį, o viso tunelio profilyje jis pasiima ir jūsų nuotolinę sesiją, o tai prastas sandoris, kai tik rinkote įrodymus. Niekam, ko jums čia reikia, nereikia root: vėliavų, adresų ir skaitiklių skaitymas veikia su jūsų įprastu naudotoju.

Kitą kartą, kai Mac tunelis elgsis netinkamai, atlikite patikrinimus iš eilės: patvirtinkite, kad atsirado utun su ifconfig -l, perskaitykite jo vėliavas, adresus ir MTU, priskirkite jį procesui, paklauskite route -n get, kurią sąsają naudoja paskirties vieta, tada stebėkite netstat -ib judėjimą. Kiekvienas žingsnis atmeta kitą sluoksnį, o pirmasis, kuris grįžta neteisingai, yra vieta, kurioje turi būti taisymas.