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 કેવી રીતે ખસે છે તે જુઓ. દરેક પગલું અલગ સ્તર બાકાત કરે છે, અને જે પહેલું ખોટું પાછું આવે ત્યાં જ સુધારો આવે છે.