యాప్ ఆధారిత మరియు గమ్యస్థాన ఆధారిత స్ప్లిట్ టన్నెలింగ్ ఒకే పనికి రెండు సెట్టింగ్‌లు కావు. ఒకటి ఏ ప్రక్రియ ప్యాకెట్ పంపుతోందని అడుగుతుంది; మరొకటి ఆ ప్యాకెట్ ఎక్కడికి వెళ్తోందని అడుగుతుంది. మొదటి ప్రశ్న కోసం నిర్మించిన నియమం ట్రాఫిక్ సహాయక ప్రక్రియ నుండి వచ్చినప్పుడు నిశ్శబ్దంగా విఫలమవుతుంది, రెండవదానికి నిర్మించిన నియమం మీరు ఎప్పుడూ జాబితా చేయని చిరునామాకు హోస్ట్‌నేమ్ పరిష్కరించబడినప్పుడు విఫలమవుతుంది. అవసరానికి సరిపోయే వస్తువును ఎంచుకోండి, ఆపై రెండు పరీక్ష ప్యాకెట్లతో నిరూపించండి: ఒకటి టన్నెల్‌ను ఉపయోగించాలి, మరొకటి ఉపయోగించకూడదు.

రెండు నియమాలు వేర్వేరు పొరల్లో పనిచేస్తాయి

యాప్ నియమం నెట్‌వర్క్ పొర పైన, ఆపరేటింగ్ సిస్టమ్ పంపేవారికి ఇచ్చే గుర్తింపుకు వ్యతిరేకంగా అమలు చేయబడుతుంది. Android లో అది ప్యాకేజీ వెనుక ఉన్న UID, మరియు VPN సేవ ప్రతి UID కి ట్రాఫిక్ టన్నెల్‌లోకి ప్రవేశిస్తుందా అని నిర్ణయిస్తుంది. గమ్యస్థానం గురించి ఏమీ అడగబడదు, కాబట్టి ఎంచుకున్న యాప్ ఏదైనా చేరుకోగలదు, మరే ఇతర యాప్ అంతర్గత నెట్‌వర్క్‌ను చేరుకోలేదు.

గమ్యస్థాన నియమం ప్యాకెట్‌పైనే అమలు చేయబడుతుంది. టన్నెల్ ఇంటర్‌ఫేస్ కొన్ని ప్రిఫిక్స్‌లను కలిగి ఉంటుంది, రూటింగ్ పట్టిక సరిపోయే ట్రాఫిక్‌ను అందులోకి పంపుతుంది, మరియు పంపే ప్రక్రియ అప్రస్తుతం. అందుకే గమ్యస్థాన నియమం ఎవరూ జాబితా చేయాలని గుర్తుంచుకోని సేవ, ప్రింటర్ లేదా బ్యాచ్ పనిని కవర్ చేస్తుంది, అందుకే క్లయింట్ ప్రక్రియను ఎప్పుడూ చూడని ప్లాట్‌ఫారమ్‌పై దాన్ని కేవలం ఈ ప్రోగ్రామ్ అని వ్యక్తపరచలేము.

యాప్ నియమాలు మొబైల్ క్లయింట్లకు మరియు నిర్వహించబడే ఏజెంట్లకు సరిపోతాయి

Android ఎంపికను నేరుగా బయటపెడుతుంది: VpnService.Builder.addAllowedApplication() మరియు addDisallowedApplication() ప్యాకేజీ పేర్లను తీసుకొని ప్రతి UID కి నిర్ణయాన్ని అమలు చేస్తాయి, Android యొక్క VPN డెవలపర్ గైడ్‌లో వివరించినట్లు. iOS లో బండిల్ ఐడెంటిఫైయర్ల ఆధారిత ప్రతి-యాప్ VPN నియమాల ద్వారా సమానమైన ఏర్పాటు ఉంది, సాధారణంగా చేతితో రాయడం బదులు MDM ప్రొఫైల్ ద్వారా ఇవ్వబడుతుంది.

డెస్క్‌టాప్ క్లయింట్లు బలహీనమైన స్థానం. చాలా Windows మరియు macOS VPN క్లయింట్లు గమ్యస్థానం ప్రకారం రూట్ చేస్తాయి మరియు ప్రక్రియ ప్రకారం ఎంపికను అసలు ఇవ్వవు, ఎందుకంటే టన్నెల్ డ్రైవర్ ప్రక్రియలను కాదు, ప్యాకెట్లను చూస్తుంది. మీ ప్రణాళిక ల్యాప్‌టాప్‌లో ఒక అప్లికేషన్‌ను టన్నెల్ చేయడంపై ఆధారపడి ఉంటే, దాని చుట్టూ రూపకల్పన చేయడానికి ముందు క్లయింట్ యొక్క వాస్తవ సామర్థ్యాలను తనిఖీ చేయండి; బహుశా మీరు గమ్యస్థానాల జాబితా మరియు రెండవ యంత్రం మధ్య ఎంచుకుంటున్నారు.

ప్రజలు కోల్పోయే పరిణామం: ఆ ప్లాట్‌ఫారమ్‌లలో రూట్లతో యాప్ నియమాన్ని అనుకరించలేరు. యాప్ సర్వర్ కోసం హోస్ట్ రూట్‌ను జోడించడం వల్ల బ్రౌజర్ మరియు అప్‌డేటర్‌తో సహా అందరి ట్రాఫిక్ ఆ సర్వర్‌కు టన్నెల్ అవుతుంది.

గమ్యస్థాన నియమాలు సబ్‌నెట్ జాబితాలకు మరియు సైట్ చేరికకు సరిపోతాయి

WireGuard నమూనాను స్పష్టం చేస్తుంది. AllowedIPs అనేది క్రిప్టోకీ రూటింగ్: గమ్యస్థానం ఒక పీర్ జాబితాలో పడే లోపలి ప్యాకెట్ ఆ పీర్‌కు ఎన్‌క్రిప్ట్ చేయబడుతుంది, మిగతావన్నీ సాధారణ మార్గం ద్వారా ఎన్‌క్రిప్షన్ లేకుండా బయటకు వెళ్తాయి. పేరు పెట్టడానికి ప్రక్రియ లేదు మరియు ఏమి చేర్చబడిందనే దానిపై ఎటువంటి అస్పష్టత లేదు.

OpenVPN నెట్టబడిన రూటింగ్ పట్టిక ద్వారా అదే స్థానానికి చేరుతుంది. route-nopull సర్వర్ రూట్లను ఆదేశించకుండా ఆపుతుంది, ఆ తర్వాత క్లయింట్ వైపు route 10.20.0.0 255.255.0.0 vpn_gateway ఖచ్చితంగా కార్యాలయ ప్రిఫిక్స్‌ను కవర్ చేస్తుంది. IPv6 ఈ ప్రతి క్లయింట్‌లో ప్రత్యేక ప్రకటన, మరియు దాన్ని మరచిపోవడం సరైనగా కనిపించే IPv4 విభజన చుట్టూ లీక్ అయ్యే అత్యంత సాధారణ మార్గం.

హోస్ట్‌నేమ్ రూట్ కాదు. ప్రొఫైల్ డొమైన్ ఫీల్డ్‌ను అందిస్తే, దాన్ని క్లయింట్ ఒకసారి పరిష్కరించే పేరుగా పరిగణించండి, శాశ్వత చిరునామా పరిధిగా కాదు; కంటెంట్ డెలివరీ నెట్‌వర్క్‌లు మరియు లోడ్ బ్యాలెన్సర్‌లు రేపు వేరే చిరునామాలను ఇస్తాయి.

రెండు నమూనాలు విరిగే చోటు: సహాయకులు, పంచుకున్న సేవలు, రిజాల్వర్లు

సహాయక ప్రక్రియలు యాప్ నియమాలను విరుస్తాయి సర్వర్ వైఫల్యంలా కనిపించే విధంగా. బ్రౌజర్ అప్‌డేటర్, క్రాష్ రిపోర్టర్, SYSTEM గా నడిచే సింక్ సేవ మరియు మరొక ప్యాకేజీలో పొదిగిన WebView అన్నీ వేర్వేరు గుర్తింపులు, కాబట్టి బ్రౌజర్‌ను టన్నెల్ చేయడం వల్ల అసలు అభ్యర్థన టన్నెల్ బయట ఉండిపోవచ్చు. దీనికి విరుద్ధంగా కూడా అంతే గందరగోళం: టన్నెల్ చేసిన ప్రక్రియ లోపల షేర్డ్ లైబ్రరీని పిలిచే మినహాయించిన యాప్ ట్రాఫిక్ కూడా టన్నెల్ గుండానే వెళ్తుంది.

గమ్యస్థాన నియమాలు పంచుకున్న సేవలపై మరియు పేర్లపై విరుగుతాయి. ఫైల్ షేర్లు, ప్రింటర్లు, అంతర్గత DNS మరియు లైసెన్స్ సర్వర్ అన్నీ చిరునామాలపై నివసిస్తాయి, కాబట్టి ఒక-యాప్ టన్నెల్ బ్రౌజర్‌కు యాక్సెస్ ఇస్తుంది కానీ మ్యాప్ చేసిన డ్రైవ్ చనిపోయినట్లే ఉంటుంది. ఆ కవరేజ్ తేడా ఏ నమూనాలోనూ బగ్ కాదు, కానీ ఒక-యాప్ టన్నెల్ చాలాసార్లు VPN ఆన్‌లో ఉంది మరియు షేర్ పోయింది అనే స్థితిని సృష్టించడానికి కారణం అదే.

రిజాల్వర్లు రెండింటినీ కత్తిరిస్తాయి. క్లయింట్ అంతర్గత DNS సర్వర్లను సెట్ చేస్తే కానీ ఆపరేటింగ్ సిస్టమ్ పబ్లిక్ రిజాల్వర్‌కు HTTPS పై DNS వాడితే, సమాధానం టన్నెల్ బయట నుండి వస్తుంది మరియు గమ్యస్థాన నియమం ఎప్పటికీ సరిపోకపోవచ్చు. నియమం తప్పు అని నిర్ధారించే ముందు ఏ రిజాల్వర్ నిజంగా సమాధానమిచ్చిందో తనిఖీ చేయండి, మరియు క్లయింట్ వైపు టన్నెల్ రిజాల్వర్‌ను అసలు ఇన్‌స్టాల్ చేసిందో లేదో నిర్ధారించండి. DNS ను టన్నెల్ బయట ఉంచే విభజన రూటింగ్ పట్టికలో పరిపూర్ణంగా కనిపిస్తుంది మరియు ప్రతి అంతర్గత పేరుపై విఫలమవుతుంది.

కార్యవిధానం: ఎంచుకోండి, వర్తించండి, ధృవీకరించండి

మెనూ నుండి కాదు, అవసరం నుండి ప్రారంభించండి. లక్ష్యం ఈ యాప్ మాత్రమే టన్నెల్‌ను ఉపయోగించగలగడం అయితే, యాప్ నియమాలు మరియు వాటిని మద్దతిచ్చే ప్లాట్‌ఫారమ్ అవసరం. లక్ష్యం ఈ నెట్‌వర్క్‌లు టన్నెల్ ద్వారా చేరగలగడం అయితే, ప్రిఫిక్స్‌లు అవసరం. సమాధానం రెండూ అయితే, వాటిని రెండు వేర్వేరు నియంత్రణలుగా అమలు చేయండి మరియు ఏది ఏ వైఫల్యానికి బాధ్యత అని రాయండి.

మీరు వ్యక్తపరచగలిగే అత్యంత సన్నని రూపాన్ని వర్తింపజేయండి, ఆపై క్లయింట్ స్థితి చిహ్నం బదులు రూటింగ్ పట్టికను అడిగి ధృవీకరించండి:

ip route get 10.20.30.40
ip -6 route get 2001:db8:10::40
wg show wg0 allowed-ips
Get-NetRoute -DestinationPrefix 10.20.0.0/16
Find-NetRoute -RemoteIPAddress 10.20.30.40

మొదటి రెండు పంక్తులు నిజమైన గమ్యస్థానం ఉపయోగించే ఇంటర్‌ఫేస్‌ను పేర్కొంటాయి; wg show కాన్ఫిగర్ చేసిన ప్రిఫిక్స్ జాబితాను ముద్రిస్తుంది; Windows లో Find-NetRoute ప్యాకెట్ పంపినప్పుడు స్టాక్ సమాధానమిచ్చే అదే ప్రశ్నకు సమాధానమిస్తుంది. ఇంటర్‌ఫేస్ టన్నెల్ అయితే, నియమం సరిపోయింది.

తర్వాత మినహాయించాల్సిన రెండవ ప్యాకెట్‌ను మరో అప్లికేషన్ నుండి అదే గమ్యస్థానానికి పరీక్షించండి. టికెట్‌లో క్లయింట్ వెర్షన్, నియమ రకం, ప్రిఫిక్స్ లేదా ప్యాకేజీ జాబితా మరియు గమనించిన రెండు ఫలితాలను నమోదు చేయండి. ఆ ఫలితాల జతయే తదుపరి ఇంజనీర్‌కు విధానం తప్పుగా కాన్ఫిగర్ చేయబడిందా లేదా ట్రాఫిక్ ఎప్పుడూ దానికి చెందలేదా అని చెబుతుంది.

సంబంధిత వ్యాసాలు