Rozhranie utun vo VPN na Macu je aktívne, ale prevádzka zlyháva? Skontrolujte ifconfig

Pripojili ste VPN, spustili ifconfig a našli záznam utun4 s adresou. Stránka, ktorú ste potrebovali, stále končí časovým limitom. Táto medzera je normálna: zoznam dokazuje, že virtuálne rozhranie existuje, nie že ho vlastní váš klient, že ho vyberá trasa, ktorá je pre vás dôležitá, ani že ním prechádzajú pakety. Prestal som dôverovať názvu rozhrania po popoludní strávenom obviňovaním nesprávneho tunela na notebooku, ktorý mal už tri záznamy utun predtým, než som čokoľvek nainštaloval.

Čo vlastne riadok utun obsahuje

Spustite ifconfig -a, keď chcete celkový obraz. Volaný bez argumentov, ifconfig vypisuje len rozhrania, ktoré sú práve aktívne, a preto môže tunel, ktorý sa nepodarilo spustiť, chýbať vo výstupe, ktorý ľudia vkladajú do tiketov. ifconfig -l vracia len názvy, a to je najrýchlejší spôsob, ako zistiť, či sa po pripojení objavil nový utun.

Čítanie jedného rozhrania je miesto, kde žije užitočný detail, a pripojený tunel zvyčajne vyzerá 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

Tri polia nesú odpoveď. UP a RUNNING hovoria, že jadro je ochotné rozhranie použiť. POINTOPOINT plus --> adresa partnera je podpis tunela a nie fyzického prepojenia. mtu hodnota vysvetľuje celú triedu hlásení „pripojí sa, potom zamrzne“, pretože rozhrania utun zvyčajne vstávajú so zníženým MTU, 1380 v niekoľkých zostaveniach macOS, a klient ho môže prepísať. Zoznam polí je dosť krátky na to, aby ste ho raz prelistovali v príručke ifconfig, ktorú dodáva Apple.

Nájdite proces za rozhraním

ifconfig nemá pojem vlastníckej aplikácie. Dvaja klienti VPN, systémová služba a tunel zostal z minulého týždňa vytvárajú záznamy, ktoré na tejto úrovni vyzerajú identicky. Na mojom Macu utun0 až utun3 existovali ešte predtým, než som čokoľvek nakonfiguroval; Continuity a iCloud Private Relay tiež používajú tunely a žiadny z nich nie je spojenie, ktoré diagnostikujete.

Pre tunely, ktoré registrujú konfiguráciu v systéme, scutil --nc list je najrýchlejšia korelácia, vypisuje každú konfiguráciu s jej stavom a ID služby, a pripojená je tak označená.

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

Klienti, ktorí prevádzkujú vlastný proces tunela namiesto registrácie konfigurácie, sa tam nikdy neobjavujú. Tunnelblick a openvpn z príkazového riadku patria do tej skupiny, takže skontrolujte aj tabuľku procesov: ps -Ao pid,comm | grep -i openvpn. Keď proces vlastní tunel, číslo utun patrí tomu procesu a ničomu inému.

Otestujte adresu skôr než trasu

Rozhranie môže byť aktívne bez použiteľnej adresy. Profil iba s IPv6 zobrazuje lokálnu fe80:: položku a nič v riadku inet, a klient, ktorému sa nepodarilo použiť vloženú adresu, zanecháva presne ten istý tvar. Ak je váš cieľ IPv4 a tunel nemá adresu IPv4, otázka smerovania je už vyriešená.

MTU si zaslúži samostatnú kontrolu, pretože zlyhanie nevyzerá ako problém s veľkosťou. Vyzerá ako spojenie, ktoré sa autentifikuje a potom stíchne, len čo sa začne veľký prenos. Pošlite sondu, ktorá sa nesmie fragmentovať, s veľkosťou tak, aby paket zodpovedal MTU rozhrania; pri MTU 1400 je užitočné zaťaženie 1372 bajtov:

ping -D -s 1372 10.8.0.5

Odpoveď znamená, že pakety tej veľkosti prechádzajú tunelom. Ticho, kým malé pingy uspejú, poukazuje na MTU alebo na niečo, čo po ceste zahadzuje ICMP, nie na autentifikáciu, ktorá už bola dokončená predtým, než ste vôbec dostali rozhranie.

Dokážte, že cieľ si vyberá tunel

Dôležitá otázka nie je, či utun4 existuje, ale či prevádzka na jednu konkrétnu adresu vychádza cez neho. route -n get odpovedá na to pre jeden cieľ a vypisuje bránu a rozhranie, ktoré by použil:

route -n get 203.0.113.20
  gateway: 10.8.0.5
  interface: utun4

Ak ten istý príkaz hlási en0, vaša konfigurácia split tunneling robí to, čo jej bolo povedané, a žiadna kontrola rozhrania to nezmení. Použite netstat -rn -f inet, keď potrebujete predvolenú trasu a celú tabuľku v jednom pohľade.

Počítadlá rozhodujú, či sa pakety naozaj hýbu. netstat -ib hlási súčty paketov a bajtov pre každé rozhranie vrátane záznamov utun; čísla sú kumulatívne, takže ich prečítajte dvakrát s odstupom a porovnajte:

netstat -ib | grep utun4

Zamrznuté počítadlá, kým aplikácia stále skúša znova, znamenajú, že jadro nikdy neodovzdalo paket rozhraniu. Počítadlá stúpajúce v oboch smeroch, kým aplikácia stále zlyháva, presúvajú vyšetrovanie na druhý koniec tunela.

Keď sa utun vôbec neobjaví

Prázdny zoznam rozhraní po prihlásení, ktoré vyzeralo úspešne, zvyčajne znamená, že tunel sa nikdy nespustil, nie že ifconfig ho skrýva. Skontrolujte stav klienta, potom systému: Network Extension, ktorý nikdy nebol schválený alebo ktorý macOS po aktualizácii vypol, nezanecháva rozhranie. Schválenie je v System Settings v sekcii Login Items & Extensions a zastaraný záznam tam stojí za opätovné prepnutie predtým, než čokoľvek preinštalujete.

Číslovanie utun nie je stabilné medzi opätovnými pripojeniami. Môžete dostať utun5 tam, kde utun4 existoval pred desiatimi minútami, pretože staré rozhranie sa rozoberie a jadro vydá ďalší voľný index. Skripty, ktoré názov zadávajú natvrdo, sa v tej chvíli potichu pokazia; namiesto toho porovnávajte adresu alebo trasu.

Držte stranu čítania iba na čítanie. sudo ifconfig utun4 down prerušuje tunel a v profile plného tunela so sebou vezme aj vašu vzdialenú reláciu, čo je zlá výmena, keď ste len zbierali dôkazy. Nič, čo tu potrebujete, nevyžaduje root: čítanie príznakov, adries a počítadiel funguje pod vaším bežným používateľom.

Kontroly urobte nabudúce v poradí, keď sa tunel na Macu začne správať zle: potvrďte, že sa objavil utun s ifconfig -l, prečítajte jeho príznaky, adresy a MTU, priraďte ho procesu, opýtajte sa route -n get, ktoré rozhranie cieľ používa, a potom sledujte netstat -ib v pohybe. Každý krok vylučuje inú vrstvu a prvý, ktorý sa vráti nesprávne, je miesto, kam patrí oprava.