utun-viðmót VPN á Mac er uppi en umferðin mistekst? Skoðaðu ifconfig

ifconfig sýnir utun-heiti, vistfang og MTU, en ekki hvaða forrit á það né hvert pakkarnir fara. Fimm lestraraðeins athuganir sem svara raunverulegu spurningunni.

Þú tengdir VPN, keyrðir ifconfig og fannst færsla utun4 með vistfangi á. Vefsvæðinu sem þú þurftir á ræðst enn á tíma. Þetta bil er eðlilegt: listinn sannar að sýndarviðmót sé til, ekki að biðlarinn þinn eigi það, að leiðin sem þér er annt um velji það, eða að pakkarnir fari í gegnum það. Ég hætti að treysta viðmótsheitinu eftir síðdegi sem ég eyddi í að kenna röngum göngum um á fartölvu sem hafði þegar þrjár utun-færslur áður en ég setti nokkuð upp.

Hvað utun-lína inniheldur í raun

Keyrðu ifconfig -a þegar þú vilt heildarmyndina. Kallað án viðfangsefna prentar ifconfig aðeins þau viðmót sem eru uppi í augnablikinu, og þess vegna getur göng sem ekki komust í gang vantað í úttakið sem fólk límir í mál. ifconfig -l skilar aðeins heitunum, og það er fljótlegasta leiðin til að sjá hvort nýtt utun birtist eftir að þú tengdirst.

Það er við að lesa eitt viðmót sem gagnlegu smáatriðin búa. Tengd göng líta venjulega svona út:

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

Þrír reitir bera svarið. UP og RUNNING segja að kjarninn sé reiðubúinn að nota viðmótið. POINTOPOINT ásamt vistfangi mótaðilans --> eru undirskrift gagna en ekki líkamlegrar tengingar. Gildið mtu útskýrir heilan flokk skýrslna um «tengist, svo stöðvast», því utun-viðmót koma venjulega upp með minnkuðu MTU, 1380 í nokkrum macOS-útgáfum, og biðlarinn getur hnekkt því. Reitalistinn er nógu stuttur til að líta á hann einu sinni í ifconfig-handbókinni sem Apple gefur út.

Finndu ferlið bak við viðmótið

ifconfig hefur enga hugmynd um eigandforrit. Tveir VPN-biðlarar, kerfisþjónusta og gömul göng frá síðustu viku framleiða öll færslur sem líta eins út á þessu stigi. Á minni eigin Mac voru utun0 til utun3 til staðar áður en ég stillti nokkuð; Continuity og iCloud Private Relay nota líka göng, og ekkert þeirra er tengingin sem þú ert að greina.

Fyrir göng sem skrá stillingu í kerfinu er scutil --nc list fljótlegasta samsvörunin. Það prentar hverja stillingu með stöðu og þjónustukenni, og tengda er merkt svona:

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

Biðlarar sem keyra sitt eigið gagnaferli í stað þess að skrá stillingu birtast þar aldrei. Tunnelblick og openvpn-tilvik af skipanalínunni falla í þann hóp, svo athugaðu líka ferlatöfluna: ps -Ao pid,comm | grep -i openvpn. Þegar ferli á göngin eru utun-númerin þess ferlis og engis annars.

Prófaðu vistfangið áður en þú prófar leiðina

Viðmót getur verið uppi án nothæfs vistfangs. Prófíll með aðeins IPv6 sýnir tengistaðbundið fe80::-færslu og ekkert í inet-línunni, og biðlari sem tókst ekki að beita ýttu vistfangi skilur eftir nákvæmlega sömu mynd. Ef áfangastaðurinn er IPv4 og göngin hafa ekkert IPv4-vistfang er leiðarspurningunni þegar svarað.

MTU á skilið sérstaka athugun, því bilunin lítur ekki út eins og stærðarvandamál. Hún lítur út eins og tenging sem auðkennir sig og þagnar svo um leið og stór flutningur hefst. Sendu rannsókn sem má ekki sundra, að stærð svo pakkinn passi við MTU viðmótsins; fyrir MTU 1400 er nytsemin 1372 bæti:

ping -D -s 1372 10.8.0.5

Svar þýðir að pakkar af þeirri stærð fari í gegnum göngin. Þögn á meðan litlar ping-tilraunir heppnast bendir til MTU eða einhvers sem sleppir ICMP á leiðinni, ekki auðkenningarinnar, sem var þegar lokið áður en þú fékkst viðmót yfirhöfuð.

Sannaðu að áfangastaðurinn velji göngin

Spurningin sem skiptir máli er ekki hvort utun4 sé til, heldur hvort umferð til eins tiltekins vistfangs fari út um það. route -n get svarar því fyrir einn áfangastað og prentar gáttina og viðmótið sem það myndi nota:

route -n get 203.0.113.20
  gateway: 10.8.0.5
  interface: utun4

Ef sama skipun greinir frá en0 gerir split-tunnel-stillingin þín það sem henni var sagt og engin viðmótsathugun breytir því. Notaðu netstat -rn -f inet þegar þú þarft sjálfgefnu leiðina og alla töfluna í einu yfirliti.

Teljarar ráða því hvort pakkarnir hreyfast í raun. netstat -ib greinir frá heildarfjölda pakka og bæta fyrir hvert viðmót, utun-færslur meðtalnar; tölurnar eru uppsafnaðar, svo lestu þær tvisvar með hléi og berðu saman:

netstat -ib | grep utun4

Frosnir teljarar á meðan forritið heldur áfram að reyna þýða að kjarninn afhenti viðmótinu aldrei pakka. Teljarar sem hækka í báðar áttir á meðan forritið mistekst enn færa rannsóknina yfir á hinn enda gagnanna.

Þegar ekkert utun birtist

Tómur viðmótslisti eftir innskráningu sem virtist takast þýðir venjulega að göngin komust aldrei í gang, ekki að ifconfig leyni þeim. Athugaðu stöðu biðlarans sjálfs, svo stöðu kerfisins: netviðbót sem var aldrei samþykkt, eða sem macOS slökkti á eftir uppfærslu, skilur ekkert viðmót eftir. Samþykkið er í Kerfisstillingum undir Login Items & Extensions, og úrelt færsla þar er þess virði að vera endurkveikt áður en þú setur eitthvað upp aftur.

utun-númerun er ekki stöðug milli endurtenginga. Þú getur fengið utun5 þar sem utun4 var fyrir tíu mínútum, því gamla viðmótið er rifið niður og kjarninn úthlutar næsta lausa vísi. Skriftur sem harðkóða heiti brotna hljóðlaust á þeirri stundu; samsvaraðu frekar við vistfangið eða leiðina.

Haltu lestrarhliðinni í aðeins-lestri. sudo ifconfig utun4 down rýfur göngin, og í heildargöngu-prófíl tekur það fjartengingu þína með sér, sem er slæmt skipti þegar þú varst bara að safna sönnunum. Ekkert sem þú þarft hér krefst root: að lesa fána, vistföng og teljara virkar sem venjulegur notandi.

Farðu í gegnum athuganirnar í röð næst þegar Mac-göng hegða sér illa: staðfestu að utun hafi birst með ifconfig -l, lestu fánana, vistföngin og MTU þess, tengdu það ferli, spurðu route -n get hvaða viðmót áfangastaðurinn notar, og fylgstu svo með netstat -ib hreyfast. Hvert skref útilokar annað lag, og það fyrsta sem kemur rangt til baka er þar sem viðgerðin á heima.

Tengdir greinar