Mac VPN:n utun-liitäntä on ylhäällä, mutta liikenne ei kulje? Tarkista ifconfig

Yhdistit VPN:n, ajoit ifconfig ja löysit merkinnän utun4, jolla oli osoite. Tarvitsemasi sivusto ei edelleenkään vastaa. Tämä aukko on normaali: listaus todistaa, että virtuaalinen liitäntä on olemassa, ei sitä, että asiakasohjelmasi omistaa sen, että sinulle tärkeä reitti valitsee sen tai että paketit kulkevat sen kautta. Lakkasin luottamasta liitännän nimeen vietettyäni iltapäivän syyttäen väärää tunnelia kannettavassa, jossa oli jo kolme utun-merkintää ennen kuin asensin mitään.

Mitä utun-rivi oikeastaan sisältää

Aja ifconfig -a, kun haluat koko kuvan. Ilman argumentteja kutsuttuna ifconfig tulostaa vain liitännät, jotka ovat juuri nyt ylhäällä, ja siksi tunneli, joka ei käynnistynyt, voi puuttua tulosteesta, jonka ihmiset liittävät tiketteihin. ifconfig -l palauttaa vain nimet, ja se on nopein tapa nähdä, ilmestyikö uusi utun yhdistämisen jälkeen.

Yhden liitännän lukeminen on paikka, jossa hyödylliset yksityiskohdat ovat. Yhdistetty tunneli näyttää yleensä tältä:

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

Kolme kenttää kantaa vastauksen. UP ja RUNNING kertovat, että ydin on valmis käyttämään liitäntää. POINTOPOINT yhdessä vastapuolen osoitteen --> kanssa on tunnelin, ei fyysisen linkin allekirjoitus. Arvo mtu selittää kokonaisen luokan raportteja «yhdistää ja sitten pysähtyy», koska utun-liitännät nousevat yleensä pienennetyllä MTU:lla, 1380 useissa macOS-koonnissa, ja asiakasohjelma voi ohittaa sen. Kenttäluettelo on tarpeeksi lyhyt silmäiltäväksi kerran Applen toimittamassa ifconfig-käsikirjassa.

Etsi liitännän takana oleva prosessi

ifconfig ei tunne omistavaa sovellusta lainkaan. Kaksi VPN-asiakasohjelmaa, järjestelmäpalvelu ja viime viikolta jäänyt tunneli tuottavat kaikki merkintöjä, jotka näyttävät tällä tasolla identtisiltä. Omassa Macissani utun0–utun3 olivat olemassa ennen kuin asetin mitään; myös Continuity ja iCloud Private Relay käyttävät tunneleita, eikä mikään niistä ole se yhteys, jota tutkit.

Tunneleille, jotka rekisteröivät kokoonpanon järjestelmään, scutil --nc list on nopein korrelaatio. Se tulostaa jokaisen kokoonpanon tilan ja palvelutunnuksen kanssa, ja yhdistetty merkitään näin:

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

Asiakasohjelmat, jotka ajavat oman tunneliprosessinsa sen sijaan, että rekisteröisivät kokoonpanon, eivät koskaan näy siellä. Tunnelblick ja komentoriviltä ajettava openvpn-esiintymä kuuluvat tähän ryhmään, joten tarkista myös prosessitaulu: ps -Ao pid,comm | grep -i openvpn. Kun prosessi omistaa tunnelin, utun-numero kuuluu sille prosessille eikä kenellekään muulle.

Testaa osoite ennen kuin testaat reitin

Liitäntä voi olla ylhäällä ilman käyttökelpoista osoitetta. Vain IPv6:n profiili näyttää linkinpaikallisen fe80::-merkinnän eikä mitään inet-rivillä, ja asiakasohjelma, joka ei saanut työnnettyä osoitetta käyttöön, jättää täsmälleen saman muodon. Jos kohteesi on IPv4 eikä tunnelilla ole IPv4-osoitetta, reitityskysymys on jo ratkennut.

MTU ansaitsee erillisen tarkistuksen, koska vika ei näytä koon ongelmalta. Se näyttää yhteydeltä, joka todennetaan ja vaikenee heti, kun suuri siirto alkaa. Lähetä koetin, jota ei saa pirstoa, mitoitettuna niin, että paketti vastaa liitännän MTU:ta; kun MTU on 1400, hyötykuorma on 1372 tavua:

ping -D -s 1372 10.8.0.5

Vastaus tarkoittaa, että tuon kokoiset paketit kulkevat tunnelin läpi. Hiljaisuus pienten pingien onnistuessa viittaa MTU:hun tai johonkin, joka pudottaa ICMP:n matkalla, ei todennukseen, joka oli jo päättynyt ennen kuin sait liitännän.

Todista, että kohde valitsee tunnelin

Tärkeä kysymys ei ole, onko utun4 olemassa, vaan kulkeeko liikenne yhteen tiettyyn osoitteeseen sen kautta. route -n get vastaa siihen yhdelle kohteelle ja tulostaa yhdyskäytävän ja liitännän, jota se käyttäisi:

route -n get 203.0.113.20
  gateway: 10.8.0.5
  interface: utun4

Jos sama komento raportoi en0, split-tunnel-kokoonpanosi tekee niin kuin sille on sanottu, eikä mikään määrä liitäntöjen tutkimista muuta sitä. Käytä netstat -rn -f inet, kun tarvitset oletusreitin ja koko taulukon yhdessä näkymässä.

Laskurit ratkaisevat, liikkuvatko paketit todella. netstat -ib raportoi paketti- ja tavumäärät liitäntää kohden, utun-merkinnät mukaan lukien; luvut ovat kumulatiivisia, joten lue ne kahdesti väliä pitäen ja vertaa:

netstat -ib | grep utun4

Jäätyneet laskurit sovelluksen yhä yrittäessä tarkoittavat, että ydin ei koskaan luovuttanut pakettia liitännälle. Laskurit, jotka kasvavat molempiin suuntiin sovelluksen yhä epäonnistuessa, siirtävät tutkinnan tunnelin toiseen päähän.

Kun utun ei ilmesty lainkaan

Tyhjä liitäntäluettelo onnistuneelta näyttäneen kirjautumisen jälkeen tarkoittaa yleensä, ettei tunneli koskaan käynnistynyt, ei sitä, että ifconfig piilottaisi sen. Tarkista asiakasohjelman oma tila ja sitten järjestelmän tila: verkkolaajennus, jota ei koskaan hyväksytty tai jonka macOS poisti käytöstä päivityksen jälkeen, ei jätä jälkeensä liitäntää. Hyväksyntä on Järjestelmäasetuksissa kohdassa Login Items & Extensions, ja vanhentunut merkintä siellä kannattaa kytkeä uudelleen ennen kuin asennat mitään uudelleen.

utun-numerointi ei ole vakaa uudelleenyhdistämisten välillä. Voit saada utun5, missä kymmenen minuuttia sitten oli utun4, koska vanha liitäntä puretaan ja ydin jakaa seuraavan vapaan indeksin. Skriptit, jotka kovakoodaavat nimen, hajoavat sillä hetkellä hiljaa; täsmäytä sen sijaan osoitteen tai reitin perusteella.

Pidä lukupuoli vain luettavana. sudo ifconfig utun4 down katkaisee tunnelin, ja täystunnelin profiilissa se vie etäistuntosi mukanaan, mikä on huono vaihtokauppa, kun olit vain keräämässä todisteita. Mikään tarvitsemasi ei vaadi rootia: lippujen, osoitteiden ja laskurien lukeminen toimii tavallisena käyttäjänä.

Käy tarkistukset järjestyksessä seuraavan kerran, kun Mac-tunneli käyttäytyy huonosti: varmista ifconfig -l-komennolla, että utun ilmestyi, lue sen liput, osoitteet ja MTU, liitä se prosessiin, kysy route -n get-komennolta, mitä liitäntää kohde käyttää, ja seuraa sitten, miten netstat -ib liikkuu. Jokainen vaihe sulkee pois eri kerroksen, ja ensimmäinen väärin palaava on korjauksen paikka.