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

సరిపోల్చేది అరుదుగా దోషి

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

ఖాళీ A రికార్డ్ సాంప్రదాయ తప్పు. సున్నా సమాధానాలతో NOERROR తిరిగి ఇవ్వడం చెల్లుబాటు అయిన సమాధానంలా కనిపిస్తుంది, కాబట్టి stub రిజాల్వర్ దాన్ని అంగీకరిస్తుంది, బ్రౌజర్ మళ్లీ ప్రయత్నిస్తుంది, AAAA ప్రయత్నిస్తుంది, మరో రిజాల్వర్ ప్రయత్నిస్తుంది, చాలా ఆలస్యంగా వదిలేస్తుంది. ప్రశ్న విభాగాన్ని పునరావృతం చేసి, లావాదేవీ IDని కాపీ చేసి ఇచ్చే సమాధాన కోడ్ 3, అంటే NXDOMAIN, సంభాషణను వెంటనే ముగిస్తుంది. మీరు ఉద్దేశపూర్వకంగా తిరస్కరించే ప్రతి పేరుకు దాన్ని ఉపయోగించండి.

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

అన్నిటినీ పట్టుకునే మార్గం అన్నిటినీ కలిగి ఉంటుంది

DNS మాత్రమే ఉన్న నిర్మాణం ఎప్పుడూ addRoute("0.0.0.0", 0) జోడించదు, కాబట్టి TUN ఇంటర్‌ఫేస్‌లోకి ప్రశ్నలు మాత్రమే ప్రవేశిస్తాయి, మిగతావన్నీ కింది నెట్‌వర్క్‌ను ఉపయోగిస్తూనే ఉంటాయి. అదే సురక్షిత రూపం, కొన్ని అనుమతి జాబితాలు Wi-Fiలో పనిచేసినట్లు కనిపించి మొబైల్ నెట్‌వర్క్‌లో ఎందుకు విఫలమవుతాయో కూడా అదే వివరిస్తుంది.

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

రిజాల్వర్ సాకెట్ సొరంగం నుండి బయటకు వెళ్లాలి

ఫార్వర్డింగ్ తదుపరి ఉచ్చు ఉన్న చోటు. క్యారియర్ రిజాల్వర్లు తరచుగా సొరంగం చేరుకోలేని ప్రైవేట్ చిరునామాలో ఉంటాయి, కాబట్టి మీరు పంపే ప్రశ్న ఎక్కడికీ వెళ్లదు మరియు యాప్ చదివే సమయం ముగిసిందని నివేదిస్తుంది. ఆమోదించిన ప్రశ్నలను చేరుకోగలమని మీకు తెలిసిన రిజాల్వర్‌కు పంపండి, ఆ సాకెట్‌ను మొదట VpnService.protect() కి ఇవ్వండి. రక్షించబడని సాకెట్ ప్రశ్నను మీ సొంత సొరంగంలోకి తిరిగి పంపుతుంది, అక్కడ అది మళ్లీ యాప్‌కు చేరి సమయ పరిమితి వరకు తిరుగుతుంది.

వైఫల్యం నెట్‌వర్క్ అంతరాయంలా కనిపిస్తుంది, అందుకే బగ్ నివేదికల్లో ఇంత కాలం జీవిస్తుంది. పంపిన ప్రశ్నలు మరియు పొందిన సమాధానాలకు కౌంటర్లు ఉంచుకోండి: మొదటి సంఖ్య పెరిగి రెండవది సున్నా వద్ద నిలిస్తే, మీరు జాబితాను కాదు, సాకెట్‌ను చూస్తున్నారు.

పరిమాణం మరియు చెక్‌సమ్ సందేశం లేకుండా విఫలమవుతాయి

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

మీరే ప్యాకెట్‌లు నిర్మిస్తే, చెక్‌సమ్ మరో నిశ్శబ్ద హంతకుడు. UDP పొడవు లేదా ప్రోటోకాల్ ఫీల్డ్‌ను వదిలేసిన సూడో హెడర్‌పై లెక్కించిన UDP చెక్‌సమ్, మీ వైపు సరిగ్గా కనిపిస్తూ గ్రహీత ఎటువంటి ఆనవాలు లేకుండా విసిరే ప్యాకెట్‌ను ఉత్పత్తి చేస్తుంది. మీ సూడో హెడర్‌ను స్పెసిఫికేషన్‌తో ఫీల్డ్-ఫీల్డ్‌గా పోల్చండి, డీబగ్ చేస్తున్నప్పుడు ఒక తెలిసిన ప్రవాహానికి లెక్కించిన చెక్‌సమ్‌ను ముద్రించండి.

VpnService మీ కోసం ఏమి చేయదు

వాటి చుట్టూ రూపకల్పన చేయడానికి ముందు రెండు పరిమితులు తెలుసుకోవడం విలువైనది. ఏ సాధారణ యాప్ కూడా Wi-Fi బయట సిస్టమ్-వ్యాప్త ప్రాక్సీ లేదా PAC ఫైల్‌ను ఇన్‌స్టాల్ చేయలేదు, ఆ భాగం మారలేదు. ప్రతి-యాప్ మార్గం మారింది: API 29 కి ముందు VpnService.Builder ప్రాక్సీని అసలు మోయలేకపోయింది, API 29 నుండి setHttpProxy(ProxyInfo.buildPacProxy(uri)) VPN నెట్‌వర్క్ కోసం మూల్యాంకనం చేయడానికి ప్లాట్‌ఫారమ్‌కు PAC స్క్రిప్ట్ ఇస్తుంది. పాత APIలను లక్ష్యంగా చేసుకున్నప్పుడు లేదా PAC నమూనా నియమాన్ని వ్యక్తపరచలేనప్పుడు నియమాలను మీ సొంత కోడ్‌లో మూల్యాంకనం చేయండి. UDP కూడా ఉచితం కాదు: బ్రౌజర్లు SOCKS ప్రాక్సీ ద్వారా TCP మాత్రమే పంపుతాయి, చాలా SOCKS5 క్లయింట్లు UDP ASSOCIATE ను ఎప్పుడూ అమలు చేయవు, కాబట్టి ప్రాక్సీ ఆధారిత నిర్మాణం TCP ఆరోగ్యంగా కనిపిస్తున్నప్పుడు UDP ను విస్మరిస్తుంది లేదా లీక్ చేస్తుంది.

ఆ రెండవ పరిమితే UDP ఆధారిత ప్రోటోకాల్ సాధారణ నెట్‌వర్క్‌లో పనిచేసి మీ VPN కనెక్ట్ అయ్యే క్షణంలో విఫలమవడానికి కారణం. సొరంగం UDP మోయాలని ఆశిస్తే, ఫార్వర్డర్ దానికి ఫార్వర్డింగ్ మార్గాన్ని అమలు చేయాలి, వేరే సాకెట్ రకంతో కూడిన TCP మార్గాన్ని మాత్రమే కాదు.

ఈ క్రమంలో తనిఖీ చేయండి

జాబితాను క్రమంగా చేయండి మరియు విఫలమయ్యే మొదటి దశలో ఆపండి, ఎందుకంటే మునుపటిది నిలబడనంత వరకు ప్రతి తదుపరి తనిఖీ శబ్దం మాత్రమే.

  1. ఇన్‌స్టాల్ చేసిన రూట్‌లను జాబితా చేయండి మరియు DNS కాని ప్యాకెట్‌లు TUN ఇంటర్‌ఫేస్‌లోకి ప్రవేశిస్తాయో లేదో నిర్ధారించండి.
  2. ఒక నిరోధించిన మరియు ఒక ఆమోదించిన పేరుకు ప్రశ్న పేరు, నిర్ణయం మరియు సమాధాన కోడ్‌ను లాగ్ చేయండి.
  3. రిజాల్వర్ సాకెట్ రక్షించబడిందని మరియు ఎంచుకున్న రిజాల్వర్ సొరంగం లోపలి నుండి సమాధానం ఇస్తుందని నిర్ధారించండి.
  4. ఇంటర్‌ఫేస్ MTU మరియు చేతితో నిర్మించిన ఒక సమాధానం యొక్క చెక్‌సమ్‌ను నిర్ధారించండి.
  5. అదే పేజీని Wi-Fi మరియు మొబైల్ నెట్‌వర్క్‌లో పునరావృతం చేయండి, ఎందుకంటే క్యారియర్ రిజాల్వర్లు మరియు మార్గ MTU భిన్నంగా ఉంటాయి.

ఐదూ నిలబడి పేజీ ఇంకా నిలిచిపోతే, తదుపరి అనుమానితుడు ఫార్వర్డర్ స్వయంగా: పట్టుబడిన అభ్యర్థనను పట్టుబడిన సమాధానంతో పోల్చి, తప్పిపోయిన బైట్ గణన లేదా సగం మూసిన సాకెట్ కోసం వెతకండి. VpnService.Builder సూచన మార్గం, DNS మరియు MTU ఒప్పందాలను కవర్ చేస్తుంది, మరియు protect() builder ఎంపిక కాదు, ప్రత్యేక VpnService కాల్; కనెక్ట్ అయిన ఇంటర్‌ఫేస్ అంటే మొదటి ఒప్పందం నెరవేరిందని మాత్రమే.

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