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 కదలికను గమనించండి. ప్రతి అడుగు వేరే పొరను తొలగిస్తుంది, మొదట తప్పుగా వచ్చిన అడుగే సరిదిద్దవలసిన స్థలం.