స్ప్లిట్ టన్నెల్ బ్రౌజర్ను మినహాయిస్తుంది, దాని DNS ప్రశ్నలను కాదు
నేరుగా డేటా మార్గం పేరు పరిష్కారాన్ని కదిలించదు. ఏ రిజాల్వర్ ప్రశ్నను స్వీకరిస్తుంది, అది ఉద్దేశమేనా అని లీక్ అని పిలిచే ముందు తనిఖీ చేయండి.
బ్రౌజర్ సొరంగం నుండి మినహాయించబడింది, పబ్లిక్ IP పేజీ దాని ట్రాఫిక్ ఇంటి కనెక్షన్ ద్వారా బయటకు వెళ్తుందని నిర్ధారిస్తుంది, అయినా అంతర్గత వికీ తెరుచుకోదు. పేరు పరిష్కారం వేరే చోటికి వెళ్ళింది, ఆ వేరే చోటు సాధారణంగా VPN సెట్ చేసిన రిజాల్వర్. డేటా మార్గం మరియు రిజాల్వర్ మార్గం చాలా స్ప్లిట్-టన్నెల్ డిజైన్లలో వేర్వేరు నిర్ణయాలు. మినహాయింపును పాడైనది అని పిలిచే ముందు బ్రౌజర్ నిజంగా ఏది ఉపయోగించిందో తనిఖీ చేయండి.
డేటా మార్గం మరియు రిజాల్వర్ మార్గం విడిపోతాయి
మినహాయింపు అనువర్తనం యొక్క ప్యాకెట్లను సొరంగం నుండి తొలగిస్తుంది, ఇది డేటా మార్గంలో రూటింగ్ మరియు ఫైర్వాల్ నిర్ణయం. పేరు పరిష్కారం మరో శోధన: ఒక ప్రక్రియ సిస్టమ్ రిజాల్వర్ను అడుగుతుంది, ఆ రిజాల్వర్ ఏ సర్వర్ ప్రశ్నను స్వీకరిస్తుందో నిర్ణయిస్తుంది.
రెండూ ఉద్దేశపూర్వకంగా మరియు భిన్నంగా ఉండవచ్చు. పని అమరిక అంతర్గత పేరు స్థలాలను కార్పొరేట్ రిజాల్వర్ వద్ద ఉంచి ఎంచుకున్న పబ్లిక్ బ్రౌజింగ్ను సొరంగం వెలుపలికి పంపవచ్చు, ఎందుకంటే అంతర్గత పేర్లు మరెక్కడా పరిష్కరించబడవు. గందరగోళ కేసు దీనికి విరుద్ధం: పబ్లిక్ సైట్ విఫలమవుతుంది, ఎందుకంటే అమరిక ఆశించిన రిజాల్వర్ను బ్రౌజర్ ఎప్పుడూ అడగలేదు. మార్గాన్ని మరియు రిజాల్వర్ను విడివిడిగా నమోదు చేయండి, సగం చర్చలు మాయమవుతాయి.
ఏ ప్రక్రియ ప్రశ్న అడుగుతుందో కనుగొనండి
బ్రౌజర్ సిస్టమ్ రిజాల్వర్, దాని స్వంత ఎన్క్రిప్టెడ్ DNS సేవ, లేదా ఆపరేటింగ్ సిస్టమ్ ప్రతి నెట్వర్క్కు కేటాయించే రిజాల్వర్ను ఉపయోగించవచ్చు. మొదటిది ప్లాట్ఫారమ్ విధానాన్ని అనుసరిస్తుంది, రెండవది ఆ విధానాన్ని పూర్తిగా దాటవేస్తుంది, మూడవది ప్రశ్న ఏ లింక్కు రూట్ చేయబడుతుందనే దానిపై ఆధారపడి ఉంటుంది.
resolvectl status
resolvectl query intranet.example.net
dig +short +time=2 intranet.example.net @10.52.0.2
scutil --dns | head -n 40
పరీక్షించే ముందు అమలులో ఉన్న కాన్ఫిగరేషన్ చదవండి: ఏ లింక్లు DNS సర్వర్లను మోసుకుంటాయి, ఏ పేరు స్థలాలను క్లెయిమ్ చేస్తాయి, పేరుకు విధానం డిఫాల్ట్ను భర్తీ చేస్తుందా. Linux లో స్ప్లిట్ DNS రూటింగ్ డొమైన్లను ఉపయోగిస్తుంది; Windows లో పేరు పరిష్కార విధాన పట్టిక పేరు స్థలాలకు అదే పని చేస్తుంది. రెండూ లీక్ పరీక్ష పేజీ నుండి కనిపించవు.
ఏ రిజాల్వర్ ఏ పేరును చూస్తుందో నిర్ణయించండి
ఏదైనా మార్చే ముందు ఉద్దేశిత మ్యాపింగ్ను రాయండి: అంతర్గత పేర్లు కార్పొరేట్ రిజాల్వర్కు, పబ్లిక్ పేర్లు విధానం అనుమతించే సేవకు, మినహాయింపులు యజమానితో. ఆ జాబితా లేకుంటే, లీక్ పరీక్షలోని ప్రతి లేబుల్ ఎవరూ పరిష్కరించలేని విధాన చర్చగా మారుతుంది.
తర్వాత బ్రౌజర్ స్వంత సెట్టింగ్ను తనిఖీ చేయండి, ఎందుకంటే బ్రౌజర్లోని ఎన్క్రిప్టెడ్ DNS ఆపరేటింగ్ సిస్టమ్ ప్రశ్నను స్వీకరించే ముందే వర్తిస్తుంది. క్యాప్టివ్ పోర్టల్ను దాటవేయడానికి దాన్ని ఆన్ చేసిన వినియోగదారు అమరిక ఎంచుకున్న రిజాల్వర్ను నిశ్శబ్దంగా భర్తీ చేశాడు. అది లీక్ కాదు, కాన్ఫిగరేషన్ నిర్ణయం, మరియు అది బ్లాక్లిస్ట్ కంటే నిర్ణయానికి అర్హం.
ఒక పరీక్షా లేబుల్ ఆకుపచ్చగా మారడానికి ప్రతి DNS ఫీల్డ్ను తిరిగి రాయవద్దు. లేబుల్ ఒక క్షణంలో ఒక ప్రక్రియ యొక్క ఒక ప్రశ్నను వివరిస్తుంది.
ప్రశ్న మరియు కనెక్షన్ను విడివిడిగా నిర్ధారించండి
రెండు మార్గాలను స్వతంత్రంగా పరీక్షించండి. కనెక్షన్ పరీక్ష డేటా మార్గాన్ని చూపుతుంది, రిజాల్వర్ పరీక్ష పేరును ఎవరు స్వీకరించారో చూపుతుంది.
curl -sS --max-time 8 https://api.ipify.org
resolvectl query example.net
dig +short example.net
రిజాల్వర్ను స్పష్టంగానూ అడగండి, వైఫల్యం మార్గానికి కాదు సర్వర్కు ఆపాదించబడేలా. తర్వాత బ్రౌజర్ను పునఃప్రారంభించి పునరావృతం చేయండి, ఎందుకంటే అనువర్తనాలు ప్రతికూల సమాధానాలను కాష్ చేస్తాయి మరియు పాత వైఫల్యం శాశ్వతంగా కనిపిస్తుంది.
ఆమోదించిన మార్పు తర్వాత డేటా మార్గాన్ని మరియు రిజాల్వర్ స్వీకర్తను రెండు వేర్వేరు పంక్తులుగా తేదీతో నమోదు చేయండి. తదుపరి పునఃకనెక్షన్లో ప్రవర్తన తిరిగి వస్తే, దాన్ని అందించే ప్రొఫైల్ సరిదిద్దాలి, బ్రౌజర్ కాదు.