Ndërfaqja utun e VPN-së në Mac është aktive, por trafiku dështon? Kontrollo ifconfig

Lidhët VPN-në, ekzekutuat ifconfig dhe gjetët një hyrje utun4 me një adresë. Faqja që ju duhej ende skadon. Ky hendek është normal: lista provon se ekziston një ndërfaqe virtuale, jo se klienti juaj e zotëron atë, se rruga që ju intereson e zgjedh atë ose se paketat e kalojnë atë. Ndalova së besuari emrin e ndërfaqes pas një pasditeje që e kalova duke fajësuar tunelin e gabuar në një laptop që kishte tashmë tre hyrje utun përpara se të instaloja gjë.

Çfarë përmban në të vërtetë një rresht utun

Ekzekutoni ifconfig -a kur dëshironi pamjen e plotë. I thirrur pa argumente, ifconfig printon vetëm ndërfaqet që janë aktive tani, prandaj një tunel që nuk nisi mund të mungojë në daljen që njerëzit ngjitin në bileta. ifconfig -l kthen vetëm emrat dhe ky është mënyra më e shpejtë për të kuptuar nëse u shfaq një utun i ri pas lidhjes.

Leximi i një ndërfaqeje të vetme është vendi ku jeton detaji i dobishëm, dhe një tunel i lidhur zakonisht duket kështu.

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

Tre fusha e mbajnë përgjigjen. UP dhe RUNNING thonë se kerneli është i gatshëm ta përdorë ndërfaqen. POINTOPOINT plus --> adresa e palës është nënshkrimi i një tuneli dhe jo i një lidhjeje fizike. mtu vlera shpjegon një klasë të tërë raportesh "lidhet, pastaj ngec", sepse ndërfaqet utun zakonisht ngrihen me MTU të reduktuar, 1380 në disa ndërtime macOS, dhe klienti mund ta mbivendosë atë. Lista e fushave është mjaft e shkurtër për t'u shfletuar një herë në manualin e ifconfig që Apple ofron.

Gjeni procesin pas ndërfaqes

ifconfig nuk ka konceptin e një aplikacioni pronar. Dy klientë VPN, një shërbim sistemi dhe një tunel i mbetur nga java e kaluar prodhojnë hyrje që duken identike në këtë nivel. Në Mac-in tim, utun0 deri në utun3 ekzistonin përpara se të konfiguroja gjë; Continuity dhe iCloud Private Relay përdorin gjithashtu tunele dhe asnjëri prej tyre nuk është lidhja që po diagnostikoni.

Për tunelet që regjistrojnë një konfigurim në sistem, scutil --nc list është korrelacioni më i shpejtë, printon çdo konfigurim me statusin dhe ID-në e shërbimit, dhe një i lidhur shënohet si i tillë.

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

Klientët që drejtojnë procesin e tyre të tunelit në vend që të regjistrojnë një konfigurim nuk shfaqen kurrë atje. Tunnelblick dhe një openvpn nga rreshti i komandës bien në atë grup, prandaj kontrolloni edhe tabelën e proceseve: ps -Ao pid,comm | grep -i openvpn. Pasi një proces zotëron tunelin, numri utun i përket atij procesi dhe asgjë tjetër.

Testoni adresën përpara rrugës

Një ndërfaqe mund të jetë aktive pa një adresë të përdorshme. Një profil vetëm IPv6 shfaq një hyrje fe80:: link-local dhe asgjë në rreshtin inet, dhe një klient që nuk arriti të zbatojë një adresë të shtyrë lë saktësisht të njëjtën formë. Nëse destinacioni juaj është IPv4 dhe tuneli nuk ka adresë IPv4, pyetja e rrugëtimit është zgjidhur tashmë.

MTU meriton një kontroll të veçantë, sepse dështimi nuk duket si problem madhësie. Duket si një lidhje që autentikohet dhe pastaj hesht sapo nis një transferim i madh. Dërgoni një sondë që nuk duhet të fragmentohet, me madhësi të tillë që paketa të përputhet me MTU-në e ndërfaqes; për një MTU prej 1400, ngarkesa është 1372 bajt:

ping -D -s 1372 10.8.0.5

Një përgjigje do të thotë se paketat e asaj madhësie kalojnë nëpër tunel. Heshtja ndërsa ping-et e vogla ia dalin tregon MTU-në ose diçka që hedh ICMP në rrugë, jo autentikimin, i cili ishte përfunduar përpara se të merrnit fare një ndërfaqe.

Provoni se destinacioni zgjedh tunelin

Pyetja që ka rëndësi nuk është nëse utun4 ekziston, por nëse trafiku drejt një adrese të caktuar del përmes tij. route -n get i përgjigjet kësaj për një destinacion dhe printon gateway-in dhe ndërfaqen që do të përdorte:

route -n get 203.0.113.20
  gateway: 10.8.0.5
  interface: utun4

Nëse i njëjti komandë raporton en0, konfigurimi juaj split tunneling po bën atë që i është thënë dhe asnjë inspektim i ndërfaqes nuk do ta ndryshojë. Përdorni netstat -rn -f inet kur ju nevojitet rruga e paracaktuar dhe e gjithë tabela në një pamje.

Numëruesit vendosin nëse paketat lëvizin vërtet. netstat -ib raporton totalet e paketave dhe bajteve për ndërfaqe, duke përfshirë hyrjet utun; numrat janë kumulativë, prandaj lexojini dy herë me një hendek dhe krahasoni:

netstat -ib | grep utun4

Numërues të ngrirë ndërsa aplikacioni vazhdon të provojë do të thotë që kerneli nuk i ka dorëzuar kurrë një paketë ndërfaqes. Numëruesit që rriten në të dy drejtimet ndërsa aplikacioni ende dështon e zhvendosin hetimin në skajin tjetër të tunelit.

Kur nuk shfaqet fare utun

Një listë e zbrazët ndërfaqesh pas një hyrjeje që dukej e suksesshme zakonisht do të thotë që tuneli nuk nisi kurrë, jo se ifconfig po e fsheh. Kontrolloni statusin e klientit, pastaj atë të sistemit: një Network Extension që nuk u miratua kurrë, ose që macOS e çaktivizoi pas një përditësimi, nuk lë ndërfaqe pas. Miratimi është në System Settings te Login Items & Extensions, dhe një hyrje e vjetër atje ia vlen të rikalohet përpara se të riinstaloni gjë.

Numërimi utun nuk është i qëndrueshëm midis rilidhjeve. Mund të merrni utun5 atje ku utun4 ekzistonte dhjetë minuta më parë, sepse ndërfaqja e vjetër çmontohet dhe kerneli jep indeksin tjetër të lirë. Skriptet që e shkruajnë emrin në mënyrë të ngurtë prishen në heshtje në atë moment; përputhni në vend të kësaj me adresën ose me rrugën.

Mbajeni anën e leximit vetëm-lexim. sudo ifconfig utun4 down ndërpret tunelin, dhe në një profil tuneli të plotë merr me vete edhe sesionin tuaj të largët, që është një shkëmbim i keq kur thjesht po mblidhnit prova. Asgjë nga ato që ju nevojiten këtu nuk kërkon root: leximi i flamujve, adresave dhe numëruesve funksionon me përdoruesin tuaj normal.

Bëni kontrollet me radhë herën tjetër që një tunel Mac sillet keq: konfirmoni se u shfaq një utun me ifconfig -l, lexoni flamujt, adresat dhe MTU-në e tij, ia atribuoni një procesi, pyesni route -n get cilën ndërfaqe përdor destinacioni, pastaj shikoni netstat -ib duke lëvizur. Çdo hap përjashton një shtresë tjetër, dhe i pari që kthehet gabim është vendi ku duhet rregullimi.