Rozhraní utun u Mac VPN je aktivní, ale provoz neprochází? Zkontrolujte ifconfig

ifconfig ukazuje název utun, adresu a MTU, ale ne která aplikace ho vlastní nebo kam pakety jdou. Pět kontrol jen pro čtení, které odpovídají na skutečnou otázku.

Připojili jste VPN, spustili ifconfig a našli záznam utun4 s adresou. Stránka, kterou jste potřebovali, stále nereaguje. Tahle mezera je normální: výpis dokazuje, že virtuální rozhraní existuje, ne že ho vlastní váš klient, že ho vybírá trasa, na které vám záleží, nebo že přes něj procházejí pakety. Přestal jsem věřit názvu rozhraní po odpoledni stráveném obviňováním špatného tunelu na notebooku, který měl tři záznamy utun ještě předtím, než jsem cokoli nainstaloval.

Co vlastně řádek utun obsahuje

Spusťte ifconfig -a, když chcete celý obraz. Zavolaný bez argumentů vypisuje ifconfig jen rozhraní, která jsou právě aktivní, a proto tunel, který se nespustil, může ve výstupu, který lidé vkládají do tiketů, chybět. ifconfig -l vrací jen názvy, a to je nejrychlejší způsob, jak zjistit, jestli se po připojení objevilo nové utun.

Čtení jednoho rozhraní je místo, kde žije užitečný detail. Připojený tunel obvykle vypadá takto:

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

Odpověď nesou tři pole. UP a RUNNING říkají, že jádro je ochotno rozhraní použít. POINTOPOINT spolu s adresou protějšku --> je podpis tunelu, nikoli fyzického spoje. Hodnota mtu vysvětluje celou třídu hlášení „připojí se a pak ztichne“, protože rozhraní utun obvykle naskakují se sníženým MTU, 1380 v několika sestaveních macOS, a klient ho může přepsat. Seznam polí je dost krátký na to, abyste ho jednou prošli v manuálu k ifconfig, který dodává Apple.

Najděte proces za rozhraním

ifconfig nemá ponětí o vlastnící aplikaci. Dva klienti VPN, systémová služba a tunel zbylý z minulého týdne vytvářejí záznamy, které na této úrovni vypadají stejně. Na svém Macu jsem měl utun0 až utun3 ještě předtím, než jsem cokoli nastavil; Continuity a iCloud Private Relay tunely také používají a žádný z nich není spojení, které vyšetřujete.

U tunelů, které registrují konfiguraci v systému, je scutil --nc list nejrychlejší spojení. Vypisuje každou konfiguraci s jejím stavem a ID služby a připojená je označena takto:

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

Klienti, kteří místo registrace konfigurace spouštějí vlastní proces tunelu, se tam nikdy neobjeví. Tunnelblick a instance openvpn z příkazové řádky patří do této skupiny, takže zkontrolujte i tabulku procesů: ps -Ao pid,comm | grep -i openvpn. Jakmile tunel vlastní nějaký proces, číslo utun patří tomu procesu a nikomu jinému.

Otestujte adresu dřív než trasu

Rozhraní může být aktivní bez použitelné adresy. Profil pouze s IPv6 ukazuje link-local záznam fe80:: a v řádku inet nic, a klient, kterému se nepodařilo použít vnucenou adresu, zanechá přesně stejný tvar. Pokud je váš cíl IPv4 a tunel nemá adresu IPv4, otázka směrování je už vyřešená.

MTU si zaslouží samostatnou kontrolu, protože selhání nevypadá jako problém velikosti. Vypadá jako spojení, které se ověří a pak ztichne, jakmile začne velký přenos. Pošlete sondu, která se nesmí fragmentovat, velikostí tak, aby paket odpovídal MTU rozhraní; pro MTU 1400 je užitečné zatížení 1372 bajtů:

ping -D -s 1372 10.8.0.5

Odpověď znamená, že pakety této velikosti tunelem procházejí. Ticho při úspěšných malých pingech ukazuje na MTU nebo na něco, co po cestě zahazuje ICMP, nikoli na autentizaci, která už skončila dřív, než jste rozhraní vůbec dostali.

Dokažte, že cíl volí tunel

Důležitá otázka není, zda utun4 existuje, ale zda přes něj odchází provoz na jednu konkrétní adresu. route -n get to pro jediný cíl zodpoví a vypíše bránu a rozhraní, které by použil:

route -n get 203.0.113.20
  gateway: 10.8.0.5
  interface: utun4

Pokud stejný příkaz hlásí en0, vaše konfigurace rozděleného tunelu dělá, co jí bylo řečeno, a žádné množství inspekce rozhraní to nezmění. Použijte netstat -rn -f inet, když potřebujete výchozí trasu a celou tabulku v jednom pohledu.

Čítače rozhodnou, zda se pakety skutečně hýbou. netstat -ib hlásí součty paketů a bajtů pro každé rozhraní, včetně záznamů utun; čísla jsou kumulativní, takže je přečtěte dvakrát s odstupem a porovnejte:

netstat -ib | grep utun4

Zmrzlé čítače, zatímco aplikace pořád zkouší znovu, znamenají, že jádro rozhraní nikdy nepředalo paket. Čítače rostoucí oběma směry, zatímco aplikace stále selhává, přesouvají vyšetřování na vzdálený konec tunelu.

Když se utun vůbec neobjeví

Prázdný seznam rozhraní po přihlášení, které vypadalo úspěšně, obvykle znamená, že tunel vůbec nezačal, ne že ho ifconfig skrývá. Zkontrolujte stav samotného klienta a pak stav systému: síťové rozšíření, které nebylo nikdy schváleno nebo které macOS po aktualizaci vypnul, po sobě nenechá žádné rozhraní. Schválení žije v Nastavení systému pod Login Items & Extensions a starý záznam tam stojí za to znovu přepnout, než cokoli přeinstalujete.

Číslování utun není mezi opětovnými připojeními stabilní. Můžete dostat utun5 tam, kde před deseti minutami bylo utun4, protože staré rozhraní se zruší a jádro vydá další volný index. Skripty, které jméno zapisují natvrdo, se v tu chvíli tiše rozbijí; párujte raději adresu nebo trasu.

Nechte čtecí stranu jen pro čtení. sudo ifconfig utun4 down přeruší tunel a u profilu plného tunelu vezme s sebou i vaši vzdálenou relaci, což je špatná výměna, když jste jen sbírali důkazy. Nic, co tu potřebujete, nevyžaduje root: čtení příznaků, adres a čítačů funguje jako běžný uživatel.

Až příště bude Mac tunel zlobit, proveďte kontroly popořadě: potvrďte, že se objevilo utun pomocí ifconfig -l, přečtěte jeho příznaky, adresy a MTU, přiřaďte ho procesu, zeptejte se route -n get, které rozhraní cíl používá, a pak sledujte, jak se netstat -ib hýbe. Každý krok vylučuje jinou vrstvu a první, který se vrátí špatně, je místo opravy.

Související články