Mac VPN utun Interface ass aktiv, awer den Traffic geet net duerch? ifconfig kontrolléieren

ifconfig weist en utun Numm, Adress an MTU, awer net wéi eng App et besëtzt oder wou d'Pakete higinn. Fënnef Liesen-nëmmen Kontrollen, déi déi richteg Fro beäntweren.

Dir hutt d'VPN verbonnen, ifconfig ausgefouert an eng utun4 Entrée mat enger Adress drop fonnt. D'Site déi Dir gebraucht hutt, leeft nach ëmmer an en Timeout. Dës Lück ass normal: d'Lëscht beweist, datt en virtuelle Interface existéiert, net datt Äre Client en besëtzt, datt de Fait deen Dir braucht en auswielt oder datt Pakete duerch en zirkuléieren. Ech hunn dem Interface sengem Numm opginn ze vertrauen, nodeems ech en Nomëtteg domat verbruecht hunn, de falschen Tunnel op engem Laptop ze beschëllegegen, deen nach dräi utun Entréeën hat, ier ech iwwerhaapt eppes installéiert hunn.

Wat eng utun Zeil tatsächlech enthält

Fëllt ifconfig -a aus, wann Dir d'ganzt Bild wëllt. Ouni Argumenter opgeruff, ifconfig dréckt nëmmen Interfaces déi just elo aktiv sinn, dofir kann en Tunnel deen net gestart ass aus dem Output fehlen, dee Leit an Tiquette pechen. ifconfig -l gëtt just d'Nimm zréck, an dat ass de séiersten Wee fir ze gesinn, ob en neien utun nom Verbannen opgetrueden ass.

Wann Dir een eenzelen Interface liest, fannt Dir den nëtzlechen Detail, an en verbonnen Tunnel gesäit normalerweis esou aus.

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

Dräi Felder droen d'Äntwert. UP an RUNNING soen, datt de Kernel bereet ass den Interface ze benotzen. POINTOPOINT plus d' --> Peer Adress ass d'Signatur vun engem Tunnel an net vun enger physescher Verbindung. Den mtu Wäert erkläert eng ganz Klass vu "verbënnt, dann hänkt" Berichter, well utun Interfaces normalerweis mat enger reduzéierter MTU kommen, 1380 an e puer macOS Builds, an de Client kann se iwwerschreiwen. D'Felderlëscht ass kuerz genuch fir eemol duerchzekucken dem ifconfig Handbuch deen Apple matgëtt.

Fannt de Prozess hannert dem Interface

ifconfig huet keen Konzept vun enger besëtzender Applikatioun. Zwee VPN Clienten, en Systemservice an en Tunnel vun der leschter Woch produzéieren Entréeën déi op dësem Niveau identesch ausgesinn. Op mengem eegene Mac, utun0 bis utun3 existéierten ier ech iwwerhaapt eppes konfiguréiert hunn; Continuity an iCloud Private Relay benotzen och Tunnelen, an keen vun hinnen ass d'Verbindung déi Dir diagnostizéiert.

Fir Tunnelen déi eng Konfiguratioun beim System registréieren, scutil --nc list ass déi séierst Korrelatioun, et dréckt all Konfiguratioun mat hirem Status a Service ID, an eng verbonne gëtt als esou markéiert.

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

Clienten déi hire eegenen Tunnelprozess lafen amplaz eng Konfiguratioun ze registréieren, dauchen do ni op. Tunnelblick an eng Kommandozeil openvpn Instanz falen an déi Grupp, also kontrolléiert och d'Prozesstabelle: ps -Ao pid,comm | grep -i openvpn. Soubal e Prozess den Tunnel besëtzt, gehéiert d'utun Nummer deem Prozess an soss näischt.

Test d'Adress ier Dir d'Route testt

En Interface kann aktiv sinn ouni eng brauchbar Adress. En IPv6-nëmmen Profil weist eng link-lokal fe80:: Entrée an näischt an der inet Zeil, an e Client deen eng gedréckt Adress net konnt uwenden hannerléisst genau déiselwecht Form. Wann Ären Zil IPv4 ass an den Tunnel keng IPv4 Adress huet, ass d'Routing Fro schonn decidéiert.

MTU verdéngt eng separat Kontroll, well de Fehler net wéi e Gréissteproblem ausgesäit. En gesäit aus wéi eng Verbindung déi sech authentifizéiert an dann roueg gëtt soubal en groussen Transfer ufänkt. Schéckt eng Probe déi net fragmentéiert däerf ginn, esou gemooss datt de Paket dem Interface seng MTU entsprécht; fir eng MTU vu 1400 ass d'Payload 1372 Byte:

ping -D -s 1372 10.8.0.5

Eng Äntwert bedeit datt Pakete vun där Gréisst duerch den Tunnel goen. Stille während kleng Pings geléngen, weist op d'MTU oder op eppes wat ICMP um Wee falle léisst, net op d'Authentifikatioun, déi schonn ofgeschloss war ier Dir iwwerhaapt en Interface hat.

Beweist datt den Zil den Tunnel auswielt

D'Fro déi zielt ass net ob utun4 existéiert, mä ob den Traffic zu enger bestëmmter Adress duerch en erausgeet. route -n get äntwert dat fir een eenzelen Zil an dréckt de Gateway an den Interface deen en benotze géif:

route -n get 203.0.113.20
  gateway: 10.8.0.5
  interface: utun4

Wann dee selwechte Kommando en0 mellt, da mécht Är split tunneling Konfiguratioun wat hir gesot gouf, an et ännert näischt wann Dir den Interface nach esou oft ënnersicht. Benotzt netstat -rn -f inet wann Dir d'Standardroute an déi ganz Tabelle an engem Bléck braucht.

Countere entscheeden, ob Pakete wierklech a Beweegung sinn. netstat -ib mellt Paket- an Byte-Totaler pro Interface, utun Entréeën abegraff; d'Zuelen si kumulativ, also liest se zweemol mat enger Paus a vergläicht:

netstat -ib | grep utun4

Countere gefruer wärend d'Applikatioun weider probéiert heescht de Kernel huet ni e Paket un den Interface iwwerginn. Counteren déi a béide Richtungen klammen wärend d'Applikatioun nach ëmmer feelt, verréckelt d'Ënnersichung op dat anert Enn vum Tunnel.

Wann iwwerhaapt keen utun erschéngt

Eng eidel Interface-Lëscht no engem Login dee erfollegräich ausgesinn huet heescht normalerweis de Tunnel ass ni gestart, net datt ifconfig en verstoppt. Kontrolléiert de Status vum Client, dann dee vum System: eng Network Extension déi ni guttgeheescht gouf, oder déi macOS no engem Update deaktivéiert huet, hannerléisst keen Interface. D'Gutt-heeschtung läit an de System Settings ënner Login Items & Extensions, an en ale Entrée do ass et wäert nach eng Kéier ëmzeschalten ier Dir eppes nei installéiert.

D'utun Nummeréierung ass net stabil iwwer Reconnecten. Dir kënnt utun5 kréien wou utun4 virun zéng Minutten existéiert huet, well den ale Interface ofgerappt gëtt an de Kernel den nächsten fräien Index vergëtt. Skripten déi en Numm hardcodéieren briechen an deem Moment stëll; passt amplaz op d'Adress oder op d'Route op.

Hält d'Lies-Säit schreifgeschützt. sudo ifconfig utun4 down ënnerbrach den Tunnel, an op engem Voll-Tunnel Profil hëlt en Är Remote-Sessioun mat, wat en schlechten Tausch ass wann Dir just Beweiser gesammelt hutt. Näischt wat Dir hei braucht erfuerdert root: Fändelen, Adressen a Countere liesen funktionéiert als Ären normale Benotzer.

Schafft d'Kontrollen der Rei no déi nächst Kéier wann en Mac Tunnel sech falsch behëlt: bestätegt mat ifconfig -l datt en utun erschoss, liest seng Fändelen, Adressen an MTU, schreift en engem Prozess zou, freet route -n get wéi en Interface den Zil benotzt, dann beobacht netstat -ib wéi en sech beweegt. All Schrëtt schléisst eng aner Schicht aus, an déi éischt déi falsch zréckkënnt ass wou de Fix gehéiert.

Ähnlech Artikelen