A Mac VPN utun-interfésze fut, de a forgalom nem megy? Nézze meg az ifconfig kimenetét

Csatlakozott a VPN-hez, lefuttatta az ifconfig parancsot, és talált egy utun4 bejegyzést címmel. A szükséges oldal továbbra is időtúllépést ad. Ez a rés normális: a lista azt bizonyítja, hogy létezik virtuális interfész, azt nem, hogy az Ön kliense birtokolja, hogy az Önt érdeklő útvonal azt választja, vagy hogy a csomagok áthaladnak rajta. Akkor hagytam abba az interfész nevében való bizalmat, miután egy délutánt azzal töltöttem, hogy a rossz alagutat hibáztattam egy laptopon, amelyen már három utun bejegyzés volt, mielőtt bármit telepítettem.

Mit tartalmaz valójában egy utun-sor

Futtassa az ifconfig -a parancsot, ha a teljes képet akarja. Argumentumok nélkül hívva a ifconfig csak az éppen aktív interfészeket nyomtatja, ezért egy el nem indult alagút hiányozhat abból a kimenetből, amelyet az emberek a jegyekbe illesztenek. A ifconfig -l csak a neveket adja vissza, és ez a leggyorsabb módja annak, hogy lássa, megjelent-e új utun a csatlakozás után.

Egyetlen interfész olvasása az a hely, ahol a hasznos részletek élnek. Egy csatlakoztatott alagút általában így néz ki:

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

Három mező hordozza a választ. Az UP és a RUNNING azt jelzi, hogy a rendszermag hajlandó használni az interfészt. A POINTOPOINT és a partner --> címe együtt nem fizikai kapcsolat, hanem egy alagút aláírása. A mtu érték a „csatlakozik, majd megáll” típusú jelentések egész osztályát magyarázza, mert az utun interfészek általában csökkentett MTU-val jönnek fel, 1380-cal több macOS-összeállításban, és a kliens felülírhatja. A mezőlista elég rövid ahhoz, hogy egyszer átfusson az Apple által szállított ifconfig kézikönyvben.

Keresse meg az interfész mögötti folyamatot

Az ifconfig parancsnak nincs fogalma a birtokló alkalmazásról. Két VPN-kliens, egy rendszerszolgáltatás és a múlt heti maradék alagút mind olyan bejegyzéseket állít elő, amelyek ezen a szinten azonosnak tűnnek. A saját Mac-emen az utun0 és utun3 már létezett, mielőtt bármit beállítottam; a Continuity és az iCloud Private Relay is használ alagutakat, és egyik sem az a kapcsolat, amelyet vizsgál.

Azoknál az alagutaknál, amelyek konfigurációt regisztrálnak a rendszerben, a scutil --nc list a leggyorsabb korreláció. Kiírja az összes konfigurációt állapotával és szolgáltatásazonosítójával, a csatlakoztatott pedig így jelölődik:

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

Azok a kliensek, amelyek saját alagútfolyamatot futtatnak konfiguráció regisztrálása helyett, soha nem jelennek meg ott. A Tunnelblick és a parancssorból indított openvpn példány ebbe a csoportba tartozik, ezért ellenőrizze a folyamattáblát is: ps -Ao pid,comm | grep -i openvpn. Amint egy folyamat birtokolja az alagutat, az utun szám azé a folyamaté, és senki másé.

Előbb a címet tesztelje, aztán az útvonalat

Egy interfész használható cím nélkül is futhat. A csak IPv6-os profil csak egy kapcsolat-local fe80:: bejegyzést mutat, és semmit az inet sorban, és az a kliens, amely nem tudott érvényesíteni egy tolt címet, pontosan ugyanezt a formát hagyja maga után. Ha a cél IPv4, és az alagútnak nincs IPv4-címe, az útválasztás kérdése már eldőlt.

Az MTU külön ellenőrzést érdemel, mert a hiba nem méretproblémának tűnik. Olyan kapcsolatnak tűnik, amely hitelesít, majd elhallgat, amint elkezdődik egy nagy átvitel. Küldjön egy nem töredezhető próbát, akkorára méretezve, hogy a csomag illeszkedjen az interfész MTU-jához; 1400-as MTU esetén a hasznos teher 1372 bájt:

ping -D -s 1372 10.8.0.5

A válasz azt jelenti, hogy az ilyen méretű csomagok áthaladnak az alagúton. A csend, miközben a kis pingek sikerülnek, az MTU-ra vagy valamire mutat, ami eldobja az ICMP-t az úton, nem a hitelesítésre, amely már befejeződött, mielőtt egyáltalán interfészt kapott.

Bizonyítsa, hogy a cél választja az alagutat

A fontos kérdés nem az, hogy létezik-e utun4, hanem hogy az egy adott címre menő forgalom kimegy-e rajta. A route -n get erre egyetlen célra válaszol, és kiírja az átjárót és az interfészt, amelyet használna:

route -n get 203.0.113.20
  gateway: 10.8.0.5
  interface: utun4

Ha ugyanaz a parancs en0 jelent, akkor az osztott alagút konfigurációja azt teszi, amit mondtak neki, és semmilyen interfészvizsgálat nem változtat ezen. Akkor használja a netstat -rn -f inet parancsot, ha az alapértelmezett útvonalra és a teljes táblára egy nézetben van szüksége.

A számlálók döntik el, hogy a csomagok valóban mozognak-e. A netstat -ib interfészenként jelenti a csomag- és bájtszámokat, az utun bejegyzéseket is beleértve; a számok kumulatívak, ezért olvassa el kétszer, közte szünettel, és hasonlítsa össze:

netstat -ib | grep utun4

A befagyott számlálók, miközben az alkalmazás tovább próbálkozik, azt jelentik, hogy a rendszermag soha nem adott át csomagot az interfésznek. A mindkét irányban növekvő számlálók, miközben az alkalmazás még mindig meghiúsul, a vizsgálatot az alagút túlsó végére helyezik át.

Amikor egyáltalán nem jelenik meg utun

Egy sikeresnek tűnő bejelentkezés utáni üres interfészhista általában azt jelenti, hogy az alagút soha nem indult el, nem pedig azt, hogy az ifconfig elrejti. Ellenőrizze magát a klienst, majd a rendszert: egy soha nem jóváhagyott, vagy a macOS frissítés után letiltott hálózati kiterjesztés nem hagy maga után interfészt. A jóváhagyás a Rendszerbeállításokban, a Login Items & Extensions alatt található, és egy ottani elavult bejegyzést érdemes újra átkapcsolni, mielőtt bármit újratelepítene.

Az utun számozása nem stabil az újracsatlakozások között. Kaphat utun5-et ott, ahol tíz perccel korábban utun4 volt, mert a régi interfész lebontódik, és a rendszermag a következő szabad indexet osztja ki. A nevet keményen kódoló szkriptek abban a pillanatban csendben eltörnek; inkább a címre vagy az útvonalra illesszen.

Tartsa az olvasási oldalt csak olvashatóként. A sudo ifconfig utun4 down megszakítja az alagutat, és teljes alagút profil esetén magával viszi a távoli munkamenetét is, ami rossz üzlet, ha csak bizonyítékot gyűjtött. Semmi, amire itt szüksége van, nem igényel rootot: a jelzők, címek és számlálók olvasása normál felhasználóként működik.

Ha legközelebb egy Mac-alagút rosszul viselkedik, végezze el az ellenőrzéseket sorrendben: erősítse meg a ifconfig -l paranccsal, hogy megjelent egy utun, olvassa ki a jelzőit, címeit és MTU-ját, rendelje folyamathoz, kérdezze meg a route -n get parancstól, melyik interfészt használja a cél, majd figyelje, hogyan mozog a netstat -ib. Minden lépés más réteget zár ki, és az első, amely hibásan tér vissza, a javítás helye.