Mac VPN का utun इंटरफ़ेस चालू है पर ट्रैफ़िक फ़ेल हो रहा है? ifconfig देखें

आपने VPN जोड़ा, ifconfig चलाया और उस पर पता लिए एक utun4 प्रविष्टि मिली। जिस साइट की ज़रूरत थी वह अब भी समय-समाप्त हो रही है। यह अंतर सामान्य है: सूची साबित करती है कि एक आभासी इंटरफ़ेस मौजूद है, यह नहीं कि आपका क्लाइंट उसे रखता है, आपके लिए अहम रूट उसे चुनता है, या पैकेट उससे गुज़रते हैं। कुछ भी इंस्टॉल करने से पहले ही जिस लैपटॉप में तीन utun प्रविष्टियाँ थीं, उस पर गलत सुरंग को दोष देने में एक दोपहर बिताने के बाद मैंने इंटरफ़ेस के नाम पर भरोसा करना छोड़ दिया।

utun पंक्ति में असल में क्या होता है

पूरी तस्वीर चाहिए तो ifconfig -a चलाएँ। बिना तर्क के बुलाए जाने पर ifconfig केवल वे इंटरफ़ेस छापता है जो इस समय चालू हैं, इसलिए जो सुरंग शुरू नहीं हुई वह उस आउटपुट से गायब हो सकती है जो लोग टिकट में चिपकाते हैं। ifconfig -l केवल नाम लौटाता है, और जुड़ने के बाद नया utun आया या नहीं, यह जानने का यह सबसे तेज़ तरीका है।

एक इंटरफ़ेस पढ़ना ही वह जगह है जहाँ काम की बारीकियाँ रहती हैं। जुड़ी हुई सुरंग आम तौर पर ऐसी दिखती है:

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

तीन फ़ील्ड जवाब लाते हैं। UP और RUNNING कहते हैं कि कर्नेल इंटरफ़ेस इस्तेमाल करने को तैयार है। POINTOPOINT और साथी का पता --> मिलकर भौतिक कड़ी नहीं, सुरंग की पहचान हैं। mtu मान «जुड़ता है, फिर अटक जाता है» वाली पूरी श्रेणी की रिपोर्टें समझाता है, क्योंकि utun इंटरफ़ेस आम तौर पर घटे हुए MTU के साथ उठते हैं, कई macOS बिल्ड में 1380, और क्लाइंट उसे बदल सकता है। फ़ील्ड की सूची इतनी छोटी है कि Apple जो ifconfig मैनुअल देता है उसमें एक बार नज़र डाली जा सके।

इंटरफ़ेस के पीछे की प्रक्रिया खोजें

ifconfig को मालिक ऐप की कोई अवधारणा नहीं है। दो VPN क्लाइंट, एक सिस्टम सेवा और पिछले हफ़्ते की बची सुरंग—सब इस स्तर पर एक जैसी दिखने वाली प्रविष्टियाँ बनाते हैं। मेरे अपने Mac पर कुछ भी सेट करने से पहले ही utun0 से utun3 तक मौजूद थीं; Continuity और iCloud Private Relay भी सुरंगें इस्तेमाल करते हैं, और उनमें से कोई वह कनेक्शन नहीं है जिसकी आप जाँच कर रहे हैं।

जो सुरंगें सिस्टम में कॉन्फ़िगरेशन दर्ज करती हैं, उनके लिए scutil --nc list सबसे तेज़ मिलान है। यह हर कॉन्फ़िगरेशन उसकी स्थिति और सेवा ID के साथ छापता है, और जुड़ी हुई ऐसे चिह्नित होती है:

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

जो क्लाइंट कॉन्फ़िगरेशन दर्ज करने के बजाय अपनी सुरंग प्रक्रिया चलाते हैं वे वहाँ कभी नहीं दिखते। Tunnelblick और कमांड लाइन से चलने वाला openvpn उदाहरण उसी समूह में हैं, इसलिए प्रक्रिया तालिका भी देखें: ps -Ao pid,comm | grep -i openvpn। एक बार कोई प्रक्रिया सुरंग की मालिक हो जाए, तो utun संख्या उसी प्रक्रिया की होती है और किसी और की नहीं।

रूट जाँचने से पहले पता जाँचें

कोई इंटरफ़ेस काम के पते के बिना भी चालू हो सकता है। केवल IPv6 वाला प्रोफ़ाइल लिंक-लोकल fe80:: प्रविष्टि दिखाता है और inet पंक्ति में कुछ नहीं, और जो क्लाइंट भेजा गया पता लागू नहीं कर पाया वह ठीक वही आकार छोड़ जाता है। अगर आपका गंतव्य IPv4 है और सुरंग के पास IPv4 पता नहीं है, तो रूटिंग का सवाल पहले ही तय हो चुका है।

MTU अलग जाँच का हक़दार है, क्योंकि विफलता आकार की समस्या जैसी नहीं दिखती। वह ऐसे कनेक्शन जैसी दिखती है जो प्रमाणित होता है और फिर बड़ा ट्रांसफ़र शुरू होते ही चुप हो जाता है। ऐसी प्रोब भेजें जिसे खंडित न किया जाए, ऐसे माप की कि पैकेट इंटरफ़ेस के MTU से मेल खाए; 1400 के MTU पर पेलोड 1372 बाइट है:

ping -D -s 1372 10.8.0.5

जवाब का मतलब है कि उस आकार के पैकेट सुरंग से गुज़रते हैं। छोटे ping सफल होते रहें और ख़ामोशी रहे, तो वह MTU की ओर इशारा करती है या रास्ते में ICMP गिराने वाली किसी चीज़ की ओर, न कि प्रमाणीकरण की ओर, जो इंटरफ़ेस मिलने से पहले ही पूरा हो चुका था।

साबित करें कि गंतव्य ही सुरंग चुनता है

अहम सवाल यह नहीं है कि utun4 मौजूद है या नहीं, बल्कि यह कि एक ख़ास पते तक जाने वाला ट्रैफ़िक उससे बाहर निकलता है या नहीं। route -n get एक गंतव्य के लिए इसका जवाब देता है और वह गेटवे और इंटरफ़ेस छापता है जो इस्तेमाल होगा:

route -n get 203.0.113.20
  gateway: 10.8.0.5
  interface: utun4

अगर वही कमांड en0 बताए, तो आपका स्प्लिट-टनल कॉन्फ़िगरेशन वही कर रहा है जो उसे कहा गया था और इंटरफ़ेस की कोई भी जाँच उसे नहीं बदलेगी। जब डिफ़ॉल्ट रूट और पूरी तालिका एक नज़र में चाहिए तो netstat -rn -f inet इस्तेमाल करें।

पैकेट सचमुच हिल रहे हैं या नहीं, यह काउंटर तय करते हैं। netstat -ib हर इंटरफ़ेस के लिए पैकेट और बाइट के कुल बताता है, utun प्रविष्टियों सहित; संख्याएँ संचयी हैं, इसलिए अंतराल के साथ दो बार पढ़ें और तुलना करें:

netstat -ib | grep utun4

ऐप के बार-बार फिर कोशिश करते रहने पर जमे हुए काउंटर का मतलब है कि कर्नेल ने इंटरफ़ेस को कभी पैकेट नहीं सौंपा। ऐप के अब भी विफल होते हुए दोनों दिशाओं में बढ़ते काउंटर जाँच को सुरंग के दूसरे सिरे की ओर ले जाते हैं।

जब कोई utun दिखे ही नहीं

सफल दिखने वाले लॉगिन के बाद खाली इंटरफ़ेस सूची का मतलब आम तौर पर यह है कि सुरंग कभी शुरू नहीं हुई, यह नहीं कि ifconfig उसे छिपा रहा है। पहले क्लाइंट की अपनी स्थिति देखें, फिर सिस्टम की: जो नेटवर्क एक्सटेंशन कभी स्वीकृत नहीं हुआ, या जिसे macOS ने अपडेट के बाद बंद कर दिया, वह पीछे कोई इंटरफ़ेस नहीं छोड़ता। स्वीकृति सिस्टम सेटिंग्स में Login Items & Extensions के अंतर्गत रहती है, और वहाँ की पुरानी प्रविष्टि कुछ भी फिर से इंस्टॉल करने से पहले एक बार दोबारा टॉगल करने लायक है।

utun की संख्या दोबारा जुड़ने पर स्थिर नहीं रहती। दस मिनट पहले जहाँ utun4 था वहाँ आपको utun5 मिल सकता है, क्योंकि पुराना इंटरफ़ेस तोड़ दिया जाता है और कर्नेल अगला खाली इंडेक्स दे देता है। जो स्क्रिप्ट नाम को हार्डकोड करते हैं वे उसी पल चुपचाप टूट जाते हैं; बजाय इसके पते या रूट से मिलान करें।

पढ़ने वाले हिस्से को केवल-पढ़ने के लिए रखें। sudo ifconfig utun4 down सुरंग तोड़ देता है, और पूर्ण-सुरंग प्रोफ़ाइल में यह आपका दूरस्थ सत्र भी ले जाता है, जो तब बुरा सौदा है जब आप सिर्फ़ सबूत जुटा रहे थे। यहाँ जो कुछ भी चाहिए उसके लिए root नहीं चाहिए: फ़्लैग, पते और काउंटर पढ़ना सामान्य उपयोगकर्ता के रूप में काम करता है।

अगली बार Mac की सुरंग बुरा व्यवहार करे तो जाँचें क्रम से करें: ifconfig -l से पुष्टि करें कि utun आया, उसके फ़्लैग, पते और MTU पढ़ें, उसे किसी प्रक्रिया से जोड़ें, route -n get से पूछें कि गंतव्य कौन-सा इंटरफ़ेस इस्तेमाल करता है, फिर देखें कि netstat -ib कैसे हिलता है। हर क़दम अलग परत को बाहर करता है, और जो पहला ग़लत लौटे वहीं सुधार आता है।