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

Povezali ste VPN, pokrenuli ifconfig i pronašli unos utun4 sa adresom. Stranica koja vam je trebala i dalje završava istekom vremena. Taj jaz je normalan: spisak dokazuje da virtuelni interfejs postoji, a ne da ga posjeduje vaš klijent, da ga ruta koja vam je važna bira ili da paketi kroz njega prolaze. Prestao sam vjerovati imenu interfejsa nakon popodneva provedenog okrivljavajući pogrešan tunel na laptopu koji je već imao tri utun unosa prije nego što sam bilo šta instalirao.

Šta utun linija 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 uspio da se pokrene može nedostajati u izlazu koji ljudi lijepe u tikete. ifconfig -l vraća samo imena, i to je najbrži način da saznate da li se novi utun pojavio nakon povezivanja.

Čitanje jednog interfejsa je mjesto gdje živi koristan detalj, a povezani 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 da koristi interfejs. POINTOPOINT plus --> adresa partnera je potpis tunela, a ne fizičke veze. mtu vrijednost objašnjava cijelu klasu izvještaja "poveže se, pa stane", jer utun interfejsi obično ustaju sa smanjenim MTU, 1380 u nekoliko macOS verzija, a klijent ga može nadjačati. Lista polja je dovoljno kratka da je jednom pregledate u ifconfig priručniku koji Apple isporučuje.

Pronađite proces iza interfejsa

ifconfig nema pojam aplikacije vlasnika. Dva VPN klijenta, sistemska usluga i tunel zaostao od prošle nedjelje stvaraju unose koji na ovom nivou izgledaju identično. Na mom Macu, utun0 do utun3 postojali su prije nego što sam bilo šta konfigurisao; Continuity i iCloud Private Relay takođe koriste tunele, i nijedan od njih nije veza koju dijagnostikujete.

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

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

Klijenti koji vode sopstveni proces tunela umjesto da registruju konfiguraciju nikada se tamo ne pojavljuju. Tunnelblick i openvpn iz komandne linije spadaju u tu grupu, pa provjerite i tabelu procesa: ps -Ao pid,comm | grep -i openvpn. Kada proces posjeduje tunel, utun broj pripada tom procesu i ničemu drugom.

Provjerite adresu prije rute

Interfejs može biti aktivan bez upotrebljive adrese. Profil samo sa IPv6 prikazuje lokalni fe80:: unos i ništa u inet liniji, a klijent koji nije uspio primijeniti gurnutu adresu ostavlja tačno isti oblik. Ako je vaše odredište IPv4 a tunel nema IPv4 adresu, pitanje rutiranja je već riješeno.

MTU zaslužuje odvojenu provjeru, jer kvar ne izgleda kao problem veličine. Izgleda kao veza koja se autentifikuje i zatim utihne čim počne veliki prenos. Pošaljite probu koja ne smije biti fragmentirana, veličine takve da paket odgovara MTU interfejsa; za MTU od 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 ukazuje na MTU ili na nešto što na putu odbacuje ICMP, a ne na autentifikaciju, koja je već bila završena prije nego što ste uopšte dobili interfejs.

Dokažite da odredište bira tunel

Pitanje koje je važno nije da li utun4 postoji, već da li saobraćaj ka jednoj konkretnoj adresi izlazi kroz njega. route -n get odgovara na to za jedno odredište i ispisuje mrežni prolaz 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 tunneling konfiguracija radi ono što joj je rečeno i nikakav pregled interfejsa to neće promijeniti. Koristite netstat -rn -f inet kada vam trebaju podrazumijevana ruta i cijela tabela u jednom pregledu.

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

netstat -ib | grep utun4

Zamrznuti brojači dok aplikacija nastavlja da pokušava znače da kernel nikada nije predao paket interfejsu. Brojači koji rastu u oba smjera dok aplikacija još uvijek 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 nikada nije pokrenut, a ne da ifconfig ga skriva. Provjerite status klijenta, zatim sistema: Network Extension koji nikada nije odobren ili koji je macOS isključio nakon ažuriranja ne ostavlja interfejs. Odobrenje je u System Settings pod Login Items & Extensions, a zastario unos tamo vrijedi ponovnog prebacivanja prije nego što bilo šta ponovo instalirate.

utun numeracija nije stabilna između ponovnih povezivanja. Možete dobiti utun5 tamo gdje je utun4 postojao prije deset minuta, jer se stari interfejs razgrađuje i kernel dodjeljuje sljedeći slobodan indeks. Skripte koje ime upisuju čvrsto tiho se lome u tom trenutku; umjesto toga 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 nosi sa sobom i vašu udaljenu sesiju, što je loša razmjena kada ste samo skupljali dokaze. Ništa što vam ovdje treba ne zahtijeva root: čitanje zastavica, adresa i brojača radi sa vašim normalnim korisnikom.

Sljedeći put kada se Mac tunel bude loše ponašao, uradite provjere po redu: potvrdite da se utun pojavio sa ifconfig -l, pročitajte njegove zastavice, adrese i MTU, pripišite ga procesu, pitajte route -n get koji interfejs koristi odredište, a zatim gledajte kako netstat -ib se kreće. Svaki korak isključuje drugi sloj, a prvi koji se vrati pogrešno je mjesto gdje popravka pripada.