La utun-interfaco de Mac VPN funkcias, sed la trafiko malsukcesas? Kontrolu ifconfig

ifconfig montras utun-nomon, adreson kaj MTU, sed ne kiu aplikaĵo posedas ĝin aŭ kien iras la pakaĵoj. Kvin nur-legaj kontroloj, kiuj respondas la veran demandon.

Vi konektis la VPN, rulis ifconfig kaj trovis enskribon utun4 kun adreso sur ĝi. La retejo, kiun vi bezonis, ankoraŭ sencas. Tiu manko estas normala: la listo pruvas, ke virtuala interfaco ekzistas, ne ke via kliento posedas ĝin, ke la vojo, kiu gravas al vi, elektas ĝin, aŭ ke pakaĵoj trapasas ĝin. Mi ĉesis fidi la nomon de la interfaco post posttagmezo pasigita kulpigante la malĝustan tunelon sur tekkomputilo, kiu jam havis tri utun-enskribojn antaŭ ol mi instalos ion ajn.

Kion utun-linio efektive enhavas

Rulu ifconfig -a kiam vi volas la tutan bildon. Vokita sen argumentoj, ifconfig presas nur interfacojn, kiuj nun estas aktivaj, kaj tial tunelo, kiu ne startis, povas manki en la eligo, kiun homoj algluas en biletojn. ifconfig -l redonas nur la nomojn, kaj tio estas la plej rapida maniero kontroli, ĉu nova utun aperis post kiam vi konektis.

Legado de unu sola interfaco estas kie loĝas la utilaj detaloj. Konektita tunelo kutime aspektas tiel:

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 kampoj portas la respondon. UP kaj RUNNING diras, ke la kerno pretas uzi la interfacon. POINTOPOINT kun la samtavola adreso --> estas la subskribo de tunelo, ne de fizika ligo. La valoro mtu klarigas tutan klason de raportoj «konektas, poste haltas», ĉar utun-interfacoj kutime leviĝas kun malgrandigita MTU, 1380 en pluraj macOS-konstruoj, kaj la kliento povas ĝin superregi. La kampa listo estas sufiĉe mallonga por tralegi ĝin unufoje en la manlibro pri ifconfig, kiun Apple liveras.

Trovu la procezon malantaŭ la interfaco

ifconfig havas nenian koncepton de posedanta aplikaĵo. Du VPN-klientoj, sistema servo kaj restinta tunelo de la pasinta semajno ĉiuj produktas enskribojn, kiuj ĉe ĉi tiu nivelo aspektas identaj. Sur mia propra Mac, utun0 ĝis utun3 ekzistis antaŭ ol mi agordis ion ajn; Continuity kaj iCloud Private Relay ankaŭ uzas tunelojn, kaj neniu el ili estas la konekto, kiun vi esploras.

Por tuneloj, kiuj registras agordon ĉe la sistemo, scutil --nc list estas la plej rapida korelacio. Ĝi presas ĉiun agordon kun ĝia stato kaj serva ID, kaj konektita unu estas markita tiel:

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

Klientoj, kiuj rulas sian propran tunelan procezon anstataŭ registri agordon, neniam aperas tie. Tunnelblick kaj komandlinia kazo de openvpn apartenas al tiu grupo, do kontrolu ankaŭ la procesan tabelon: ps -Ao pid,comm | grep -i openvpn. Post kiam procezo posedas la tunelon, la utun-numero apartenas al tiu procezo kaj al neniu alia.

Testu la adreson antaŭ ol testi la vojon

Interfaco povas esti aktiva sen uzebla adreso. Profilo nur IPv6 montras ligillokalan enskribon fe80:: kaj nenion en la linio inet, kaj kliento, kiu malsukcesis apliki puŝitan adreson, lasas precize la saman formon. Se via celo estas IPv4 kaj la tunelo havas neniun IPv4-adreson, la demando pri vojigo jam estas solvita.

MTU meritas apartan kontrolon, ĉar la fiasko ne aspektas kiel problemo pri grandeco. Ĝi aspektas kiel konekto, kiu aŭtentikigas kaj poste silentas tuj kiam granda transdono komenciĝas. Sendu sondilon, kiun oni ne rajtas fragmentigi, dimensionita tiel, ke la pakaĵo kongruu kun la MTU de la interfaco; por MTU de 1400 la utilŝarĝo estas 1372 bajtoj:

ping -D -s 1372 10.8.0.5

Respondo signifas, ke pakaĵoj de tiu grandeco trapasas la tunelon. Silento dum malgrandaj ping-oj sukcesas montras al MTU aŭ al io, kio faligas ICMP sur la vojo, ne al aŭtentikigo, kiu jam finiĝis antaŭ ol vi eĉ ricevis interfacon.

Pruvu, ke la celo elektas la tunelon

La grava demando ne estas, ĉu utun4 ekzistas, sed ĉu trafiko al unu specifa adreso eliras tra ĝi. route -n get respondas tion por unu celo kaj presas la enirejon kaj la interfacon, kiujn ĝi uzus:

route -n get 203.0.113.20
  gateway: 10.8.0.5
  interface: utun4

Se la sama komando raportas en0, via split-tunnel-agordo faras tion, kion oni diris al ĝi, kaj neniu kvanto da interfaca inspektado tion ŝanĝos. Uzu netstat -rn -f inet kiam vi bezonas la defaŭltan vojon kaj la tutan tabelon en unu vido.

Nombriloj decidas, ĉu pakaĵoj efektive moviĝas. netstat -ib raportas pakaĵajn kaj bajtajn sumojn por ĉiu interfaco, inkluzive utun-enskribojn; la nombroj estas akumulaj, do legu ilin dufoje kun paŭzo kaj komparu:

netstat -ib | grep utun4

Frostigitaj nombriloj dum la aplikaĵo daŭre reprovas signifas, ke la kerno neniam transdonis pakaĵon al la interfaco. Nombriloj grimpantaj en ambaŭ direktoj dum la aplikaĵo ankoraŭ malsukcesas movas la esploradon al la malproksima fino de la tunelo.

Kiam neniu utun aperas entute

Malplena interfaca listo post ensaluto, kiu aspektis sukcesa, kutime signifas, ke la tunelo neniam startis, ne ke ifconfig kaŝas ĝin. Kontrolu la staton de la kliento mem, poste tiun de la sistemo: reta etendaĵo, kiu neniam estis aprobita, aŭ kiun macOS malŝaltis post ĝisdatigo, lasas neniun interfacon malantaŭ si. La aprobo loĝas en la Sistemaj Agordoj sub Login Items & Extensions, kaj malnova enskribo tie meritas reŝaltadon antaŭ ol vi reinstalos ion ajn.

utun-numerado ne estas stabila inter rekonektoj. Vi povas ricevi utun5 tie, kie antaŭ dek minutoj ekzistis utun4, ĉar la malnova interfaco estas malkonstruata kaj la kerno disdonas la sekvan liberan indekson. Skriptoj, kiuj malmoligas nomon, rompiĝas silente en tiu momento; kongruigu la adreson aŭ la vojon anstataŭe.

Tenu la legadflankon nur-lega. sudo ifconfig utun4 down interrompas la tunelon, kaj ĉe plentunela profilo ĝi forprenas vian malproksiman seancon, kio estas malbona interŝanĝo kiam vi nur provis kolekti pruvojn. Nenio, kion vi bezonas ĉi tie, postulas root: legado de flagoj, adresoj kaj nombriloj funkcias kiel via normala uzanto.

Uzu la kontrolojn laŭorde la venontan fojon, kiam Mac-tunelo miskondutos: konfirmu, ke utun aperis per ifconfig -l, legu ĝiajn flagojn, adresojn kaj MTU, atribuu ĝin al procezo, demandu route -n get kiun interfacon la celo uzas, kaj poste observu netstat -ib moviĝi. Ĉiu paŝo ekskludas alian tavolon, kaj la unua, kiu revenas malĝuste, estas la loko de la riparo.

Rilataj artikoloj