Mac-VPN se utun-koppelvlak is op, maar verkeer faal? Kyk na ifconfig

Jy het die VPN gekoppel, ifconfig uitgevoer en 'n utun4-inskrywing met 'n adres daarop gekry. Die webwerf wat jy nodig gehad het, wys steeds 'n tydsversaking. Daardie gaping is normaal: die lys bewys dat 'n virtuele koppelvlak bestaan, nie dat jou kliënt dit besit nie, nie dat die roete wat vir jou saak maak dit kies nie, en nie dat pakkette dit kruis nie. Ek het opgehou om die koppelvlaknaam te vertrou ná 'n middag wat ek die verkeerde tonnel die skuld gegee het op 'n skootrekenaar wat reeds drie utun-inskrywings gehad het voordat ek enigiets geïnstalleer het.

Wat 'n utun-reël eintlik bevat

Voer ifconfig -a uit wanneer jy die volle prentjie wil sien. Sonder enige argumente druk ifconfig net koppelvlakke wat tans op is, en daarom kan 'n tonnel wat nie begin het nie, ontbreek uit die uitset wat mense in kaartjies plak. ifconfig -l gee net die name terug, en dit is die vinnigste manier om te sien of daar ná jou verbinding 'n nuwe utun bygekom het.

Om 'n enkele koppelvlak te lees, is waar die nuttige besonderhede sit. 'n Gekoppelde tonnel lyk gewoonlik so:

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

Drie velde dra die antwoord. UP en RUNNING sê die kern is bereid om die koppelvlak te gebruik. POINTOPOINT plus die --> eweknie-adres is die kenmerk van 'n tonnel eerder as van 'n fisiese skakel. Die mtu-waarde verklaar 'n hele klas verslae van «koppel, dan stop», want utun-koppelvlakke kom gewoonlik met 'n verlaagde MTU op, 1380 in verskeie macOS-boude, en die kliënt kan dit oorheers. Die veldlys is kort genoeg om een keer deur te lees in die ifconfig-handleiding wat Apple lewer.

Vind die proses agter die koppelvlak

ifconfig het geen begrip van 'n eienaarprogram nie. Twee VPN-kliënte, 'n stelseldiens en 'n oorblywende tonnel van verlede week lewer almal inskrywings wat op hierdie vlak identies lyk. Op my eie Mac het utun0 tot en met utun3 bestaan voordat ek enigiets opgestel het; Continuity en iCloud Private Relay gebruik ook tonnels, en nie een van hulle is die verbinding wat jy ontleed nie.

Vir tonnels wat 'n konfigurasie by die stelsel registreer, is scutil --nc list die vinnigste korrelasie. Dit druk elke konfigurasie met sy status en diens-ID, en 'n gekoppelde een word as sodanig gemerk:

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

Kliënte wat hul eie tonnelproses laat loop in plaas daarvan om 'n konfigurasie te registreer, verskyn nooit daar nie. Tunnelblick en 'n opdragreël-instansie van openvpn val in daardie groep, so kyk ook na die prosestabel: ps -Ao pid,comm | grep -i openvpn. Sodra 'n proses die tonnel besit, behoort die utun-nommer aan daardie proses en aan niks anders nie.

Toets die adres voordat jy die roete toets

'n Koppelvlak kan op wees sonder 'n bruikbare adres. 'n Slegs-IPv6-profiel wys 'n skakel-lokale fe80::-inskrywing en niks in die inet-reël nie, en 'n kliënt wat nie daarin geslaag het om 'n gestuurde adres toe te pas nie, laat presies dieselfde vorm. As jou bestemming IPv4 is en die tonnel het geen IPv4-adres nie, is die roetevraag reeds besleg.

MTU verdien 'n aparte toets, want die mislukking lyk nie soos 'n grootteprobleem nie. Dit lyk soos 'n verbinding wat verifieer en dan stil word sodra 'n groot oordrag begin. Stuur 'n peiling wat nie gefragmenteer mag word nie, so groot dat die pakket by die koppelvlak-MTU pas; vir 'n MTU van 1400 is die las 1372 grepe:

ping -D -s 1372 10.8.0.5

'n Antwoord beteken pakkette van daardie grootte beweeg deur die tonnel. Stilte terwyl klein pings slaag, wys na MTU of na iets wat ICMP op die pad laat val, nie na verifikasie nie, want dit het reeds klaar gekom voordat jy enigsins 'n koppelvlak gekry het.

Bewys dat die bestemming die tonnel kies

Die vraag wat saak maak, is nie of utun4 bestaan nie, maar of verkeer na een spesifieke adres dit verlaat. route -n get beantwoord dit vir 'n enkele bestemming en druk die poort en koppelvlak wat dit sou gebruik:

route -n get 203.0.113.20
  gateway: 10.8.0.5
  interface: utun4

As dieselfde opdrag en0 rapporteer, doen jou gesplete-tonnel-konfigurasie wat aan hom gesê is, en geen hoeveelheid koppelvlak-inspeksie sal dit verander nie. Gebruik netstat -rn -f inet wanneer jy die verstekroete en die hele tabel in een oorsig nodig het.

Tellers beslis of pakkette werklik beweeg. netstat -ib rapporteer pakket- en grepetotale per koppelvlak, utun-inskrywings ingesluit; die syfers is opbouend, so lees hulle twee keer met 'n gaping en vergelyk:

netstat -ib | grep utun4

Tellers wat vries terwyl die toepassing aanhou herprobeer, beteken die kern het nooit 'n pakket aan die koppelvlak oorhandig nie. Tellers wat in beide rigtings klim terwyl die toepassing steeds faal, skuif die ondersoek na die verre kant van die tonnel.

Wanneer daar glad geen utun verskyn nie

'n Leë koppelvlaklys ná 'n aanmelding wat suksesvol gelyk het, beteken gewoonlik dat die tonnel nooit begin het nie, nie dat ifconfig dit wegsteek nie. Kyk na die kliënt se eie status, dan na die stelsel se status: 'n netwerkuitbreiding wat nooit goedgekeur is nie, of wat macOS ná 'n opdatering gedeaktiveer het, laat geen koppelvlak oor nie. Die goedkeuring sit in Stelselinstellings onder Login Items & Extensions, en 'n verouderde inskrywing daar is die moeite werd om weer te wissel voordat jy enigiets herinstalleer.

utun-nommering is nie stabiel tussen herverbindings nie. Jy kan utun5 kry waar utun4 tien minute gelede bestaan het, want die ou koppelvlak word afgebreek en die kern deel die volgende vrye indeks uit. Skripte wat 'n naam hardkodeer, breek op daardie oomblik stil; pas eerder op die adres of op die roete.

Hou die leeskant lees-alleen. sudo ifconfig utun4 down onderbreek die tonnel, en op 'n volledige-tonnel-profiel neem dit jou afgeleë sessie saam, wat 'n swak ruil is wanneer jy net bewyse wou insamel. Niks wat jy hier nodig het, vereis root nie: die lees van vlae, adresse en tellers werk alles as jou gewone gebruiker.

Werk die kontroles in volgorde deur die volgende keer dat 'n Mac-tonnel hom misdra: bevestig dat 'n utun met ifconfig -l verskyn het, lees sy vlae, adresse en MTU, skryf dit aan 'n proses toe, vra route -n get watter koppelvlak die bestemming gebruik, en kyk dan hoe netstat -ib beweeg. Elke stap sluit 'n ander laag uit, en die eerste een wat verkeerd terugkom, is waar die oplossing hoort.