Mac VPN-aren utun interfazea aktibo dago baina trafikoa huts egiten du? Egiaztatu ifconfig

VPN-ra konektatu zinen, ifconfig exekutatu eta helbideren bat zuen utun4 sarrera aurkitu zenuen. Behar zenuen guneak oraindik ez du erantzuten. Hutsune hori normala da: zerrendak interfaze birtual bat badagoela frogatzen du, ez zure bezeroak hura duenik, axola zaizun bideak hura aukeratzen duenik edo paketeak hura zeharkatzen dutenik. Interfazearen izenari sinesteari utzi nion arratsalde bat igaro nuen eta gero, ordenagailu eramangarri batean tunel okerra erruduntzat jo nuenean, hark hiru utun sarrera baitzituen jada ezer instalatu aurretik.

Zer dagoen utun lerro batean benetan

Exekutatu ifconfig -a irudi osoa nahi duzunean. Argumenturik gabe deituta, ifconfig une horretan aktibo dauden interfazeak soilik inprimatzen ditu, eta horregatik hasteari uko egin zion tunel bat falta daiteke jendeak txartelak itsasteko erabiltzen duen irteeran. ifconfig -l izenak soilik itzultzen ditu, eta hori da konektatu ondoren utun berri bat agertu den jakiteko modurik azkarrena.

Interfaze bakarra irakurtzea da xehetasun erabilgarriak bizi diren lekua. Konektatutako tunel batek normalean itxura hau du:

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

Hiru eremuk eramaten dute erantzuna. UP eta RUNNING kernelak interfazea erabiltzeko prest dagoela esaten dute. POINTOPOINT eta parekoaren helbide --> elkarrekin ez dira esteka fisikoa, tunel baten sinadura baizik. mtu balioak «konektatu eta gero gelditu» motako txostenen klase oso bat argitzen du, utun interfazeak MTU murriztuarekin altxatzen baitira normalean, 1380 macOS eraikuntza batzuetan, eta bezeroak gainidatz dezake. Eremu-zerrenda behar bezain laburra da behin gainbegiratzeko Apple-k banatzen duen ifconfig eskuliburuan.

Aurkitu interfazearen atzean dagoen prozesua

ifconfig-ek ez du jabe den aplikazioaren kontzepturik. Bi VPN bezero, sistema-zerbitzu bat eta aurreko asteko tunel hondar bat maila honetan berdinak diruditen sarrerak sortzen dituzte. Nire Mac-ean, utun0 eta utun3 artean baziren ezer konfiguratu aurretik; Continuity-k eta iCloud Private Relay-k ere tunelak erabiltzen dituzte, eta horietako bat ere ez da zu ikertzen ari zaren konexioa.

Sisteman konfigurazio bat erregistratzen duten tunelentzat, scutil --nc list da erlaziorik azkarrena. Konfigurazio bakoitza bere egoerarekin eta zerbitzu-IDarekin inprimatzen du, eta konektatuta dagoena horrela markatzen da:

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

Konfigurazioa erregistratu beharrean beren tunel-prozesua exekutatzen duten bezeroak ez dira inoiz han agertzen. Tunnelblick eta komando-lerroko openvpn instantzia talde horretan sartzen dira, beraz begiratu prozesuen taula ere: ps -Ao pid,comm | grep -i openvpn. Prozesu batek tunela duenean, utun zenbakia prozesu horrena da eta ez beste inorena.

Probatu helbidea bidea probatu aurretik

Interfaze bat aktibo egon daiteke erabilgarria den helbiderik gabe. IPv6 soilik duen profil batek fe80:: estekak lokaleko sarrera erakusten du eta ezer ez inet lerroan, eta bultzatutako helbide bat aplikatu ezin izan zuen bezeroak forma berbera uzten du. Zure helmuga IPv4 bada eta tunelak ez badu IPv4 helbiderik, bideratze-kontua lehendik konponduta dago.

MTU-k aparteko proba merezi du, hutsegiteak ez baitu tamaina-arazo itxurarik. Konexio batek autentifikatu eta gero isiltzen den itxura du, transferentzia handi bat hasteko orduan. Bidali zatitu ezin den zunda bat, paketea interfazearen MTU-ra egokituta; 1400eko MTU baterako karga erabilgarria 1372 byte dira:

ping -D -s 1372 10.8.0.5

Erantzunak tamaina horretako paketeek tunela zeharkatzen dutela esan nahi du. Ping txikiek asmatzen duten bitartean isiltasunak MTU-ra edo bidean ICMP botatzen duen zerbaiti egiten dio seinalea, ez autentifikazioari, hori oraindik amaitua baitzen interfazerik ere izan baino lehen.

Froga ezazu helmugak tunela aukeratzen duela

Garrantzitsua ez da ea utun4 badagoen, baizik eta helbide zehatz batera doan trafikoak hura uzten duen. route -n get-ek helmuga bakar baterako erantzuten du eta erabiliko lukeen atea eta interfazea inprimatzen ditu:

route -n get 203.0.113.20
  gateway: 10.8.0.5
  interface: utun4

Komando berak en0 ematen badu, zure split-tunnel konfigurazioak esan zitzaiona egiten du eta interfaze-ikuskapenak ez du hori aldatuko. Erabili netstat -rn -f inet bide lehenetsia eta taula osoa begirada bakarrean behar dituzunean.

Kontagailuek erabakitzen dute paketeak benetan mugitzen diren. netstat -ib-ek interfaze bakoitzeko pakete eta byte guztizkoak ematen ditu, utun sarrerak barne; zenbakiak metagarriak dira, beraz irakurri bitan tarte batekin eta konparatu:

netstat -ib | grep utun4

Aplikazioak berriro saiatzen jarraitzen duen bitartean izoztuta dauden kontagailuek kernelak inoiz interfazeari paketerik eman ez ziola esan nahi dute. Aplikazioak huts egiten jarraitzen duen bitartean bi noranzkoetan igotzen diren kontagailuek ikerketa tunelaren beste muturrera eramaten dute.

Inolako utun-ik ez denean agertzen

Saio-hasiera arrakastatsua zirudienaren ondoren zerrenda hutsa egoteak tunela inoiz abiatu ez zela esan nahi du normalean, ez ifconfig-ek ezkutatzen duela. Begiratu bezeroaren beraren egoera, gero sistemarena: inoiz onartu ez zen edo macOS-ek eguneratze baten ondoren desgaitu zuen sare-luzapen batek ez du interfazerik uzten. Onarpena Sistemaren Ezarpenetan dago, Login Items & Extensions atalean, eta hango sarrera zaharkitu bat merezi du berriz aldatzea ezer berriro instalatu aurretik.

utun zenbakitzea ez da egonkorra berriz konektatzen denean. Duela hamar minutu utun4 zegoen lekuan utun5 lor dezakezu, interfaze zaharra botatzen baita eta kernelak hurrengo indize librea ematen baitu. Izena gogorrean kodetzen duten script-ak isil-isilik hausten dira une horretan; konparatu helbidea edo bidea horren ordez.

Eduki irakurketa-aldea irakurtzeko soilik. sudo ifconfig utun4 down-ek tunela eteten du, eta tunel osoko profilean urruneko saioa ere eraman ohi du, eta hori truke txarra da frogak biltzen ari zinen bitartean. Hemen behar duzun ezerk ez du root behar: banderak, helbideak eta kontagailuak irakurtzea zure erabiltzaile arruntarekin funtzionatzen du.

Hurrengoan Mac tunelak gaizki jokatzen duenean, egin probak ordenan: egiaztatu utun bat agertu dela ifconfig -l-rekin, irakurri haren banderak, helbideak eta MTU, esleitu prozesu bati, galdetu route -n get-ri helmugak zein interfaze erabiltzen duen, eta gero begiratu netstat -ib nola mugitzen den. Urrats bakoitzak geruza ezberdin bat baztertzen du, eta oker itzultzen den lehena da konponketaren lekua.