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 ला जुळणाऱ्या आकारात पाठवा; MTU 1400 असेल तर पेलोड 1372 बाइट आहे:

ping -D -s 1372 10.8.0.5

उत्तर आले म्हणजे त्या आकाराचे पॅकेट टनेलमधून जातात। लहान पिंग यशस्वी होताना शांतता MTU किंवा मार्गावर ICMP टाकणाऱ्या कशालातरी निर्देश करते, प्रमाणीकरणाकडे नाही, ते इंटरफेस मिळण्यापूर्वीच पूर्ण झाले होते।

गंतव्य टनेल निवडते हे सिद्ध करा

महत्त्वाचा प्रश्न utun4 अस्तित्वात आहे का हा नाही, तर एका विशिष्ट पत्त्याकडचा रहदारी त्यातून बाहेर पडतो का हा आहे। route -n get एका गंतव्यासाठी त्याचे उत्तर देते आणि वापरणारे गेटवे व इंटरफेस छापते:

route -n get 203.0.113.20
  gateway: 10.8.0.5
  interface: utun4

जर तीच आज्ञा en0 असे नोंदवते, तर तुमची split tunneling संरचना सांगितलेले करत आहे आणि इंटरफेसची कितीही तपासणी केली तरी ते बदलणार नाही। netstat -rn -f inet वापरा जेव्हा तुम्हाला डीफॉल्ट मार्ग आणि संपूर्ण तक्ता एका दृश्यात हवा असेल।

पॅकेट खरोखर हलतात का हे काउंटर ठरवतात। netstat -ib utun नोंदींसह प्रत्येक इंटरफेसची पॅकेट आणि बाइट बेरीज नोंदवते; संख्या संचयी आहेत, म्हणून त्या अंतराने दोनदा वाचा आणि तुलना करा:

netstat -ib | grep utun4

अॅप पुन्हा प्रयत्न करत असताना काउंटर स्थिर असतील तर कर्नेलने एकही पॅकेट इंटरफेसला दिले नाही। अॅप अजूनही अपयशी असताना काउंटर दोन्ही दिशांनी वाढत असतील तर तपासणी टनेलच्या पलीकडच्या टोकाकडे जाते।

utun अजिबात दिसत नसताना

यशस्वी वाटलेल्या लॉगिननंतर इंटरफेसची यादी रिकामी असेल तर सहसा टनेल सुरू झालेच नाही असे होते, ifconfig ते लपवत आहे असे नाही। क्लायंटची स्वतःची स्थिती तपासा, नंतर सिस्टमची: कधीही मंजूर न झालेले किंवा अद्यतनानंतर macOS ने बंद केलेले Network Extension मागे इंटरफेस सोडत नाही। मंजुरी System Settings मध्ये, Login Items & Extensions अंतर्गत असते, आणि तिथली जुनी नोंद काहीही पुन्हा इन्स्टॉल करण्यापूर्वी पुन्हा टॉगल करण्यासारखी आहे।

utun क्रमांकन पुन्हा जोडण्यांमध्ये स्थिर नाही। दहा मिनिटांपूर्वी utun5 होते तिथे utun4 मिळू शकतो, कारण जुना इंटरफेस तोडला जातो आणि कर्नेल पुढील मोकळा निर्देशांक देतो। नाव कठीणपणे लिहिलेल्या स्क्रिप्ट त्या क्षणी गुपचूप तुटतात; त्याऐवजी पत्ता किंवा मार्गावर जुळवा।

वाचनाची बाजू फक्त-वाचनीय ठेवा। sudo ifconfig utun4 down टनेल व्यत्यय आणते, आणि संपूर्ण-टनेल प्रोफाइलमध्ये ते तुमचे दूरस्थ सत्रही घेऊन जाते, जे फक्त पुरावे गोळा करत असताना वाईट व्यवहार आहे। इथे हव्या असलेल्या कोणत्याही गोष्टीसाठी root लागत नाही: फ्लॅग, पत्ते आणि काउंटर वाचणे तुमच्या सामान्य वापरकर्त्याने चालते।

पुढच्या वेळी Mac टनेल चुकीचे वागल्यास तपासण्या क्रमाने करा: ifconfig -l ने utun आला का ते निश्चित करा, त्याचे फ्लॅग, पत्ते आणि MTU वाचा, ते प्रक्रियेला जोडा, route -n get ला गंतव्य कोणता इंटरफेस वापरतो ते विचारा, नंतर netstat -ib ची हालचाल पहा। प्रत्येक पायरी वेगळा स्तर वगळते, आणि पहिली चुकीची येणारी पायरी म्हणजे दुरुस्तीची जागा।