utun interfejs Mac VPN-a je aktivan, ali saobraćaj ne prolazi? Provjerite ifconfig

ifconfig prikazuje utun ime, adresu i MTU, ali ne koja ga aplikacija drži ni kuda paketi idu. Pet provjera samo za čitanje koje odgovaraju na pravo pitanje.

Povezali ste VPN, pokrenuli ifconfig i našli unos utun4 s adresom na njemu. Stranica koja vam je trebala još uvijek ne odgovara. Ta praznina je normalna: popis dokazuje da virtuelni interfejs postoji, a ne da ga vaš klijent posjeduje, da ruta koja vas zanima bira njega ili da paketi prolaze kroz njega. Prestao sam vjerovati imenu interfejsa nakon popodneva provedenog u okrivljavanju pogrešnog tunela na laptopu koji je već imao tri utun unosa prije nego što sam išta instalirao.

Šta utun red zapravo sadrži

Pokrenite ifconfig -a kada želite cijelu sliku. Pozvan bez argumenata, ifconfig ispisuje samo interfejse koji su trenutno aktivni, zbog čega tunel koji nije startovao može nedostajati u izlazu koji ljudi lijepe u tikete. ifconfig -l vraća samo imena, a to je najbrži način da vidite je li se novi utun pojavio nakon povezivanja.

Čitanje jednog interfejsa je mjesto gdje žive korisni detalji. Povezan tunel obično izgleda ovako:

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 polja nose odgovor. UP i RUNNING kažu da je kernel spreman koristiti interfejs. POINTOPOINT plus adresa sagovornika --> potpis je tunela, a ne fizičke veze. Vrijednost mtu objašnjava cijelu klasu izvještaja „poveže se, pa stane“, jer se utun interfejsi obično dižu sa smanjenim MTU, 1380 u nekoliko macOS buildova, a klijent ga može nadjačati. Lista polja je dovoljno kratka da je jednom pregledate u priručniku za ifconfig koji Apple isporučuje.

Pronađite proces iza interfejsa

ifconfig nema pojam aplikacije koja ga posjeduje. Dva VPN klijenta, sistemska usluga i zaostali tunel od prošle sedmice svi proizvode unose koji na ovom nivou izgledaju identično. Na mom Macu su utun0 do utun3 postojali prije nego što sam išta podesio; Continuity i iCloud Private Relay takođe koriste tunele, a nijedan od njih nije veza koju ispitujete.

Za tunele koji registruju konfiguraciju u sistemu, scutil --nc list je najbrža veza. Ispisuje svaku konfiguraciju s njenim statusom i ID-om usluge, a povezana je označena tako:

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

Klijenti koji pokreću vlastiti proces tunela umjesto registracije konfiguracije nikad se ne pojavljuju tamo. Tunnelblick i instanca openvpn iz komandne linije spadaju u tu grupu, pa provjerite i tablicu procesa: ps -Ao pid,comm | grep -i openvpn. Kad proces posjeduje tunel, utun broj pripada tom procesu i nikome drugom.

Provjerite adresu prije nego rutu

Interfejs može biti aktivan bez upotrebljive adrese. Profil samo s IPv6 prikazuje link-local unos fe80:: i ništa u redu inet, a klijent koji nije uspio primijeniti poslanu adresu ostavlja potpuno isti oblik. Ako je vaše odredište IPv4, a tunel nema IPv4 adresu, pitanje rutiranja je već riješeno.

MTU zaslužuje zasebnu provjeru, jer kvar ne izgleda kao problem veličine. Izgleda kao veza koja se autentifikuje i onda utihne čim počne veliki prenos. Pošaljite probu koja se ne smije fragmentirati, veličine tako da paket odgovara MTU-u interfejsa; za MTU 1400 korisni teret je 1372 bajta:

ping -D -s 1372 10.8.0.5

Odgovor znači da paketi te veličine prolaze kroz tunel. Tišina dok mali pingovi uspijevaju upućuje na MTU ili na nešto što odbacuje ICMP na putu, a ne na autentifikaciju, koja je već završila prije nego što ste uopšte dobili interfejs.

Dokažite da odredište bira tunel

Bitno pitanje nije postoji li utun4, već izlazi li saobraćaj prema jednoj konkretnoj adresi kroz njega. route -n get odgovara na to za jedno odredište i ispisuje gateway i interfejs koje bi koristio:

route -n get 203.0.113.20
  gateway: 10.8.0.5
  interface: utun4

Ako ista komanda prijavi en0, vaša split-tunnel konfiguracija radi ono što joj je rečeno i nikakva provjera interfejsa to neće promijeniti. Koristite netstat -rn -f inet kada vam trebaju zadana ruta i cijela tablica u jednom pregledu.

Brojači odlučuju kreću li se paketi zaista. netstat -ib prijavljuje ukupne brojeve paketa i bajtova po interfejsu, uključujući utun unose; brojevi su kumulativni, pa ih pročitajte dvaput s pauzom i uporedite:

netstat -ib | grep utun4

Zamrznuti brojači dok aplikacija stalno pokušava znače da kernel nikad nije predao paket interfejsu. Brojači koji rastu u oba smjera dok aplikacija još ne uspijeva premještaju istragu na drugi kraj tunela.

Kada se utun uopšte ne pojavi

Prazna lista interfejsa nakon prijave koja je izgledala uspješno obično znači da tunel nikad nije startovao, a ne da ga ifconfig skriva. Provjerite status samog klijenta, pa status sistema: mrežno proširenje koje nikad nije odobreno ili koje je macOS onemogućio nakon ažuriranja ne ostavlja interfejs za sobom. Odobrenje se nalazi u sistemskim postavkama pod Login Items & Extensions, a zastarjeli unos tamo vrijedi ponovo prebaciti prije nego što bilo šta reinstalirate.

utun numeracija nije stabilna između ponovnih povezivanja. Možete dobiti utun5 gdje je prije deset minuta bio utun4, jer se stari interfejs ruši i kernel daje sljedeći slobodan indeks. Skripte koje hardkodiraju ime tiho se lome u tom trenutku; uparujte po adresi ili po ruti.

Držite stranu za čitanje samo za čitanje. sudo ifconfig utun4 down prekida tunel, a na profilu punog tunela odnosi i vašu udaljenu sesiju, što je loša razmjena kad ste samo skupljali dokaze. Ništa što vam ovdje treba ne zahtijeva root: čitanje zastavica, adresa i brojača radi kao običan korisnik.

Sljedeći put kad se Mac tunel loše ponaša, izvedite provjere po redu: potvrdite da se utun pojavio pomoću ifconfig -l, pročitajte njegove zastavice, adrese i MTU, pripišite ga procesu, pitajte route -n get koji interfejs odredište koristi, pa gledajte kako se netstat -ib kreće. Svaki korak isključuje drugi sloj, a prvi koji se vrati pogrešan je mjesto popravke.

Povezani članci