Mac VPN-i utun-liides on üleval, aga liiklus ei lähe? Kontrolli ifconfig

ifconfig näitab utun-nime, aadressi ja MTU-d, kuid mitte seda, milline rakendus seda hoiab või kuhu paketid lähevad. Viis ainult lugemise kontrolli, mis vastavad tõelisele küsimusele.

Ühendasite VPN-i, käivitasite ifconfig ja leidsite kirje utun4, millel oli aadress. Veebileht, mida vajasite, ei vasta endiselt. See lünk on tavaline: loend tõestab, et virtuaalne liides on olemas, mitte seda, et teie klient seda hoiab, et teid huvitav marsruut selle valib või et paketid seda läbivad. Ma lõpetasin liidese nime usaldamise pärast pärastlõunat, mille veetsin süüdistades valet tunnelit sülearvutis, milles oli juba kolm utun-kirjet enne, kui ma midagi paigaldasin.

Mida utun-rida tegelikult sisaldab

Käivitage ifconfig -a, kui soovite tervet pilti. Ilma argumentideta kutsutuna trükib ifconfig ainult liidesed, mis on praegu üleval, ja seetõttu võib tunnel, mis ei käivitunud, puududa väljundist, mille inimesed piletitesse kleepimiseks kopeerivad. ifconfig -l tagastab ainult nimed ja see on kiireim viis näha, kas pärast ühendamist ilmus uus utun.

Ühe liidese lugemine on koht, kus elavad kasulikud detailid. Ühendatud tunnel näeb tavaliselt välja selline:

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

Kolm välja kannavad vastust. UP ja RUNNING ütlevad, et kernel on valmis liidest kasutama. POINTOPOINT koos vastaspoole aadressiga --> on tunneli, mitte füüsilise lingi allkiri. Väärtus mtu selgitab tervet klassikalist aruannet «ühendub, siis tõmbub kinni», sest utun-liidesed tulevad tavaliselt üles vähendatud MTU-ga, 1380 mitmes macOS-i koostes, ja klient võib selle üle kirjutada. Väljade loend on piisavalt lühike, et see üks kord läbi sirvida Apple'i tarnitavas ifconfigi käsiraamatus.

Leidke liidese taga olev protsess

ifconfig ei tunne mõistet „omav rakendus“. Kaks VPN-kliendi, süsteemiteenus ja eelmisest nädalast järele jäänud tunnel tekitavad kõik kirjed, mis sellel tasandil näivad identsed. Minu enda Macis olid utun0 kuni utun3 olemas enne, kui ma midagi seadistasin; Continuity ja iCloud Private Relay kasutavad samuti tunneleid ja ükski neist ei ole ühendus, mida te uurite.

Tunnelite puhul, mis registreerivad süsteemis konfiguratsiooni, on scutil --nc list kiireim seos. See trükib iga konfiguratsiooni koos oleku ja teenuse ID-ga ning ühendatud oma märgitakse nii:

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

Kliendid, mis käitavad oma tunneliprotsessi selle asemel, et konfiguratsiooni registreerida, ei ilmu sinna kunagi. Tunnelblick ja käsurealt käivitatud openvpn eksemplar kuuluvad sellesse gruppi, seega kontrollige ka protsessitabelit: ps -Ao pid,comm | grep -i openvpn. Kui protsess tunnelit omab, kuulub utun-number sellele protsessile ja mitte kellelegi teisele.

Testige aadressi enne marsruudi testi

Liides võib olla üleval ilma kasutatava aadressita. Ainult IPv6 profiil näitab link-lokaalset kirjet fe80:: ja inet real mitte midagi, ning klient, mis ei suutnud lükatud aadressi rakendada, jätab täpselt sama kuju. Kui teie sihtkoht on IPv4 ja tunnelil pole IPv4 aadressi, on marsruutimise küsimus juba lahendatud.

MTU väärib eraldi kontrolli, sest tõrge ei näe välja nagu suuruse probleem. See näeb välja nagu ühendus, mis autendib end ja jääb siis vaikseks niipea, kui algab suur ülekanne. Saatke sond, mida ei tohi fragmenteerida, mõõdetuna nii, et pakett vastaks liidese MTU-le; MTU 1400 korral on kasulik koormus 1372 baiti:

ping -D -s 1372 10.8.0.5

Vastus tähendab, et sellise suurusega paketid läbivad tunneli. Vaikus väikeste pingide õnnestumise ajal viitab MTU-le või millelegi, mis viskab ICMP teel kõrvale, mitte autentimisele, mis oli juba lõppenud enne, kui te üldse liidese saite.

Tõestage, et sihtkoht valib tunneli

Tähtis küsimus pole see, kas utun4 on olemas, vaid kas liiklus ühte konkreetsesse aadressi väljub selle kaudu. route -n get vastab sellele ühe sihtkoha kohta ja trükib lüüsi ja liidese, mida see kasutaks:

route -n get 203.0.113.20
  gateway: 10.8.0.5
  interface: utun4

Kui sama käsk teatab en0, teeb teie split-tunnel konfiguratsioon seda, mida talle öeldi, ja ükski liidese kontroll ei muuda seda. Kasutage netstat -rn -f inet, kui vajate vaikemarsruuti ja tervet tabelit ühes vaates.

Loendurid otsustavad, kas paketid tõesti liiguvad. netstat -ib teatab pakettide ja baitide kogusummad liidese kohta, kaasa arvatud utun-kirjed; numbrid on kumulatiivsed, seega lugege neid kaks korda vahega ja võrrelge:

netstat -ib | grep utun4

Külmunud loendurid, samal ajal kui rakendus jätkab kordamist, tähendavad, et kernel ei andnud liidesele kunagi paketti. Loendurid, mis kasvavad mõlemas suunas, samal ajal kui rakendus ikka ebaõnnestub, viivad uurimise tunneli kaugemasse otsa.

Kui utun ei ilmu üldse

Tühi liideste loend pärast edukana näivat sisselogimist tähendab tavaliselt, et tunnel ei käivitunud kunagi, mitte et ifconfig seda peidab. Kontrollige kliendi enda olekut, seejärel süsteemi oma: võrgulaiendus, mida ei ole kunagi heaks kiidetud või mille macOS pärast värskendust keelas, ei jäta endast liidest maha. Kinnitus asub süsteemiseadetes jaotises Login Items & Extensions, ja sealne vananenud kirje tasub enne millegi uuesti paigaldamist korra uuesti ümber lülitada.

utun-numeratsioon ei ole taasühenduste vahel stabiilne. Võite saada utun5 seal, kus kümme minutit tagasi oli utun4, sest vana liides lammutatakse ja kernel annab järgmise vaba indeksi. Skriptid, mis kõvakodeerivad nime, purunevad sel hetkel vaikselt; sobitage hoopis aadressi või marsruudi järgi.

Hoidke lugemise pool ainult lugemiseks. sudo ifconfig utun4 down katkestab tunneli ja täistunneli profiilil võtab see kaasa ka teie kaugsessiooni, mis on halb vahetus, kui te lihtsalt kogusite tõendeid. Miski siin vajaminev ei nõua root-i: lippude, aadresside ja loendurite lugemine töötab tavalise kasutajana.

Järgmine kord, kui Maci tunnel halvasti käitub, tehke kontrollid järjekorras: kinnitage, et utun ilmus, käsuga ifconfig -l, lugege selle lipud, aadressid ja MTU, siduge see protsessiga, küsige route -n get-lt, millist liidest sihtkoht kasutab, ja jälgige siis, kuidas netstat -ib liigub. Iga samm välistab erineva kihi ja esimene, mis tuleb valesti tagasi, on paranduse koht.

Seotud artiklid