De utun-ynterface fan Mac VPN is oan, mar ferkear mislearret? Kontrollearje ifconfig

Jo hawwe de VPN ferbûn, ifconfig útfiere litten en in ynskriuwing utun4 mei in adres dêrop fûn. De side dy't jo nedich hienen, draait noch altyd yn in time-out. Dat gat is normaal: de list bewiist dat in firtuele ynterface bestiet, net dat jo klant dy hat, dat de rûte dy't jo oanbelanget dyselde kiest of dat pakketten der trochhinne geane. Ik bin opholden mei it fertrouwen fan de ynterfacenamme nei't ik in middei trochbrocht hie mei it beskuldigjen fan de ferkearde tunnel op in laptop dy't al trije utun-ynskriuwings hie foardat ik wat ynstallearre.

Wat in utun-rige eins befettet

Fiere ifconfig -a út as jo it hiele byld wolle. Sûnder arguminten printe ifconfig allinnich ynterfaces dy't no oan binne, en dêrom kin in tunnel dy't net starte mist yn de útfier dy't minsken yn tickets plakke. ifconfig -l jout allinnich de nammen werom, en dat is de fluchste manier om te sjen oft der nei jo ferbining in nije utun ferskynde.

It lêzen fan ien ynterface is wêr't de nijsgjirrige details binne. In ferbûne tunnel sjocht der meastentiids sa út:

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

Trije fjilden drage it antwurd. UP en RUNNING sizze dat de kearn ree is om de ynterface te brûken. POINTOPOINT tegearre mei it adres fan de oare kant --> is de hantekening fan in tunnel en net fan in fysike ferbining. De wearde mtu ferklearret in hiele klasse rapporten «ferbynt, dan stiet stil», omdat utun-ynterfaces meastentiids omheech komme mei in ferlege MTU, 1380 yn ferskate macOS-builts, en de klant kin dy oerskriuwe. De fjildlist is koart genôch om ien kear troch te nimmen yn it ifconfig-hânboek dat Apple leveret.

Fyn it proses efter de ynterface

ifconfig hat gjin begryp fan in eigener-applikaasje. Twa VPN-klanten, in systeemtsjinst en in oerbliuwende tunnel fan ferline wike meitsje allegear ynskriuwings dy't op dit nivo identyk lykje. Op myn eigen Mac bestie utun0 oant utun3 al foardat ik wat ynstelde; Continuity en iCloud Private Relay brûke ek tunnels, en gjinien fan har is de ferbining dy't jo ûndersykje.

Foar tunnels dy't in konfiguraasje by it systeem registrearje, is scutil --nc list de fluchste korrelaasje. It printet elke konfiguraasje mei status en tsjinst-ID, en in ferbûne wurdt sa markearre:

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

Klanten dy't har eigen tunnelproses rinne litte yn stee fan in konfiguraasje te registrearjen, ferskine dêr nea. Tunnelblick en in openvpn-eksimplaar fan de kommandorigel falle yn dy groep, dus kontrolearje ek de prosestabel: ps -Ao pid,comm | grep -i openvpn. Sadree't in proses de tunnel hat, heart it utun-nûmer by dat proses en by nimmen oars.

Test it adres foardat jo de rûte test

In ynterface kin oan wêze sûnder in brûkber adres. In profyl mei allinnich IPv6 lit in link-lokale fe80::-ynskriuwing sjen en neat yn 'e inet-rige, en in klant dy't in tawijd adres net tapasse koe, lit krekt deselde foarm efter. As jo bestimming IPv4 is en de tunnel hat gjin IPv4-adres, dan is de routingfraach al beslein.

MTU fertsjinnet in aparte kontrôle, want de flater liket net op in grutteprobleem. It liket op in ferbining dy't autentisearret en dan stil wurdt sadree't in grutte oerdracht begjint. Stjoer in probe dy't net fragmintearre wurde mei, sa grut dat it pakket by de MTU fan de ynterface past; by in MTU fan 1400 is de lading 1372 byte:

ping -D -s 1372 10.8.0.5

In antwurd betsjut dat pakketten fan dy grutte troch de tunnel geane. Stilte wylst lytse pings slagje wiist op MTU of op eat dat ICMP ûnderweis weilittet, net op autentikaasje, dy't al klear wie foardat jo ea in ynterface krigen.

Bewiisje dat de bestimming de tunnel kiest

De fraach dy't telt is net oft utun4 bestiet, mar oft ferkear nei ien bepaald adres der trochhinne fuortgiet. route -n get beantwurdet dat foar ien bestimming en printet de gateway en de ynterface dy't it brûke soe:

route -n get 203.0.113.20
  gateway: 10.8.0.5
  interface: utun4

As itselde kommando en0 meldt, docht jo split-tunnelkonfiguraasje wat der sein is en gjin inkelde ynterface-ynspeksje sil dat feroarje. Brûk netstat -rn -f inet as jo de standertrûte en de hiele tabel yn ien oersjoch nedich hawwe.

Tellers bepale oft pakketten echt bewege. netstat -ib meldt pakket- en bytetotalen per ynterface, utun-ynskriuwings ynbegrepen; de sifers binne kumulatyt, dus lês se twa kear mei in skoft en fergelykje:

netstat -ib | grep utun4

Beferzen tellers wylst de applikaasje trochgiet mei opnij besykjen betsjutte dat de kearn nea in pakket oan de ynterface jûn hat. Tellers dy't yn beide rjochtingen omheech geane wylst de applikaasje noch mislearret, ferpleatse it ûndersyk nei de oare ein fan de tunnel.

As der hielendal gjin utun ferskynt

In lege ynterfacelist nei in oanmelding dy't slagge like betsjut meastentiids dat de tunnel nea starte, net dat ifconfig him ferberget. Kontrolearje de status fan de klant sels, dan dy fan it systeem: in netwurkútwreiding dy't nea goedkard is of dy't macOS nei in update útskeakele hat, lit gjin ynterface efter. De goedkarring sit yn Systeemynstellings ûnder Login Items & Extensions, en in ferâldere ynskriuwing dêr is it wurdich om wer omskeakele te wurden foardat jo wat opnij ynstallearje.

utun-nûmering is net stabyl tusken werferbiningen. Jo kinne utun5 krije wêr't tsien minuten lyn utun4 wie, omdat de âlde ynterface ôfbrutsen wurdt en de kearn de folgjende frije yndeks jout. Skripts dy't in namme hurd kodearje, brekke op dat stuit stil; ferwiderje ynstee op it adres of op de rûte.

Hâld de lêzkant allinnich-lêzen. sudo ifconfig utun4 down ûnderbrekt de tunnel, en op in folsleine-tunnelprofyl nimt it jo ôfstânsessy mei, wat in minne ruil is as jo allinnich bewiis sammele. Neat fan wat jo hjir nedich hawwe freget root: flags, adressen en tellers lêze wurket as jo gewoane brûker.

Wurket de kontrôles op folchoarder ôf de folgjende kear dat in Mac-tunnel him misdraacht: befêstigje dat der in utun ferskynde mei ifconfig -l, lês syn flags, adressen en MTU, ferbyn it oan in proses, freegje route -n get hokker ynterface de bestimming brûkt, en sjoch dan hoe't netstat -ib beweecht. Elke stap slût in oare laach út, en de earste dy't ferkeard weromkomt is wêr't de repaaraasje heart.