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 को चाल हेर्नुहोस्। हरेक चरणले फरक तह हटाउँछ, र पहिलो गलत आउने चरण नै सुधारको ठाउँ हो।