Vmesnik utun v VPN-u na Macu je aktiven, a promet ne teče? Preverite ifconfig

Povezali ste VPN, zagnali ifconfig in našli vnos utun4 z naslovom. Spletno mesto, ki ste ga potrebovali, še vedno poteče. Ta vrzel je običajna: seznam dokazuje, da navidezni vmesnik obstaja, ne pa, da ga ima v lasti vaš odjemalec, da ga izbere pot, ki je za vas pomembna, ali da paketi potujejo skozenj. Nehal sem zaupati imenu vmesnika po popoldnevu, ki sem ga porabil za obtoževanje napačnega tunela na prenosniku, ki je imel že tri vnose utun, preden sem karkoli namestil.

Kaj vrstica utun dejansko vsebuje

Zaženite ifconfig -a, ko želite celotno sliko. Klican brez argumentov, ifconfig izpiše samo vmesnike, ki so trenutno aktivni, zato lahko tunel, ki se ni zagnal, manjka v izpisu, ki ga ljudje prilepijo v zahtevke. ifconfig -l vrne samo imena in to je najhitrejši način, da ugotovite, ali se je po povezavi pojavil nov utun.

Branje enega vmesnika je kraj, kjer živi koristna podrobnost, in povezan tunel je običajno videti takole.

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

Tri polja nosijo odgovor. UP in RUNNING povesta, da je jedro pripravljeno uporabiti vmesnik. POINTOPOINT skupaj z --> naslovom partnerja je podpis tunela in ne fizične povezave. mtu vrednost pojasnjuje cel razred poročil »poveže se, nato obstane«, ker vmesniki utun običajno vstanejo z zmanjšanim MTU, 1380 v več gradnjah macOS, in odjemalec ga lahko preglasi. Seznam polj je dovolj kratek, da ga enkrat preletite v priročniku ifconfig, ki ga priloži Apple.

Poiščite proces za vmesnikom

ifconfig ne pozna pojma lastniške aplikacije. Dva odjemalca VPN, sistemska storitev in tunel, ostal od prejšnjega tedna, ustvarijo vnose, ki so na tej ravni videti enako. Na mojem Macu utun0 do utun3 so obstajali že preden sem karkoli nastavil; Continuity in iCloud Private Relay prav tako uporabljata tunele in noben od njih ni povezava, ki jo diagnosticirate.

Za tunele, ki registrirajo konfiguracijo v sistemu, scutil --nc list je najhitrejša korelacija, izpiše vsako konfiguracijo s svojim stanjem in ID-jem storitve, povezana pa je tako označena.

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

Odjemalci, ki vodijo svoj proces tunela, namesto da bi registrirali konfiguracijo, se tam nikoli ne pojavijo. Tunnelblick in openvpn iz ukazne vrstice spadata v to skupino, zato preverite tudi tabelo procesov: ps -Ao pid,comm | grep -i openvpn. Ko proces ima tunel v lasti, številka utun pripada temu procesu in ničemur drugemu.

Preizkusite naslov preden preizkusite pot

Vmesnik je lahko aktiven brez uporabnega naslova. Profil samo z IPv6 prikaže lokalni fe80:: vnos in nič v vrstici inet, odjemalec, ki mu ni uspelo uporabiti potisnjenega naslova, pa pusti popolnoma enako obliko. Če je vaš cilj IPv4 in tunel nima naslova IPv4, je vprašanje usmerjanja že rešeno.

MTU si zasluži ločeno preverjanje, ker napaka ne izgleda kot težava z velikostjo. Izgleda kot povezava, ki se overi in nato utihne, takoj ko se začne velik prenos. Pošljite sondo, ki se ne sme fragmentirati, po velikosti tako, da paket ustreza MTU-ju vmesnika; pri MTU 1400 je koristni tovor 1372 bajtov:

ping -D -s 1372 10.8.0.5

Odgovor pomeni, da paketi te velikosti potujejo skozi tunel. Tišina, medtem ko mali pingi uspejo, kaže na MTU ali na nekaj, kar na poti spusti ICMP, ne pa na preverjanje pristnosti, ki je bilo končano, preden ste sploh dobili vmesnik.

Dokažite, da cilj izbere tunel

Pomembno vprašanje ni, ali utun4 obstaja, ampak ali promet do enega določenega naslova odhaja skozenj. route -n get na to odgovori za en cilj in izpiše prehod ter vmesnik, ki bi ga uporabil:

route -n get 203.0.113.20
  gateway: 10.8.0.5
  interface: utun4

Če ista ukaz sporoči en0, vaša konfiguracija split tunneling dela, kar ji je bilo rečeno, in noben pregled vmesnika tega ne bo spremenil. Uporabite netstat -rn -f inet, ko potrebujete privzeto pot in celotno tabelo v enem pogledu.

Števci odločijo, ali se paketi res premikajo. netstat -ib poroča vsote paketov in bajtov na vmesnik, vključno z vnosi utun; številke so kumulativne, zato jih preberite dvakrat z presledkom in primerjajte:

netstat -ib | grep utun4

Zamrznjeni števci, medtem ko aplikacija še poskuša, pomenijo, da jedro ni nikoli predalo paketa vmesniku. Števci, ki rastejo v obe smeri, medtem ko aplikacija še vedno ne uspe, premaknejo preiskavo na drugi konec tunela.

Ko se utun sploh ne pojavi

Prazen seznam vmesnikov po prijavi, ki je bila videti uspešna, običajno pomeni, da se tunel ni nikoli zagnal, ne pa da ifconfig ga skriva. Preverite stanje odjemalca, nato sistema: Network Extension, ki ni bil nikoli odobren ali ki ga je macOS po posodobitvi izklopil, ne pusti vmesnika. Odobritev je v System Settings pod Login Items & Extensions, in zastarel vnos tam je vreden ponovnega preklopa, preden karkoli znova namestite.

Oštevilčenje utun ni stabilno med ponovnimi povezavami. Lahko dobite utun5 tam, kjer je utun4 obstajal pred desetimi minutami, ker se stari vmesnik razgradi in jedro izda naslednji prosti indeks. Skripte, ki ime zapišejo trdo, se v tistem trenutku tiho zlomijo; namesto tega ujemajte naslov ali pot.

Ohranite bralno stran samo za branje. sudo ifconfig utun4 down prekine tunel, na profilu polnega tunela pa s seboj vzame tudi vašo oddaljeno sejo, kar je slaba menjava, ko ste samo zbirali dokaze. Nič, kar tukaj potrebujete, ne zahteva root: branje zastavic, naslovov in števcev deluje z vašim običajnim uporabnikom.

Naslednjič, ko se bo Mac tunel obnašal slabo, opravite preverjanja po vrsti: potrdite, da se je utun pojavil s ifconfig -l, preberite njegove zastavice, naslove in MTU, pripišite ga procesu, vprašajte route -n get, kateri vmesnik uporablja cilj, nato opazujte netstat -ib pri gibanju. Vsak korak izključi drugo plast in prvi, ki se vrne narobe, je mesto, kamor sodi popravek.