VPN DNS vs బ్రౌజర్ DoH: లీక్ పరీక్ష చెప్పలేనిది
లీక్ పరీక్ష నుండి వచ్చే చిరునామా ఏ resolver సమాధానం ఇచ్చిందో మాత్రమే చూపుతుంది. గుప్తీకరించిన ప్రశ్నలు, విభజిత DNS మరియు బ్రౌజర్ విధానం — ఇవి ప్రైవేట్ పేర్లు ఇంకా పరిష్కారమవుతాయా అని నిర్ణయిస్తాయి.
లీక్ పరీక్ష పేజీ మీ DNS బాగానే ఉందని చెబుతుంది, బ్రౌజర్ బ్యాడ్జ్ సురక్షితమని చెబుతుంది, అంతర్గత వికీ మాత్రం ఇంకా లోడ్ కాదు. మూడూ ఒకేసారి నిజం కావచ్చు, ఎందుకంటే resolver చిరునామా అనేది దాన్ని ఎంచుకున్న విధానం లేదా ప్రశ్న ప్రయాణించిన మార్గం కాదు. ప్రజలు DNS లీక్ అని పిలిచేది నిజానికి ఒకే ప్రశ్న: ఏ resolver ఆ పేరును స్వీకరించింది, ఆ ఎంపిక ఉద్దేశపూర్వకమా? దాన్ని విడదీయడానికి మూడు తనిఖీలు అవసరం, చివరిది మాత్రమే ఒక సెట్టింగ్ మార్చడం కలిగి ఉంటుంది.
మొదటి అపోహ: బ్యాడ్జ్ మీ resolver పేరు చెబుతుంది
లీక్ పరీక్ష ఒక ప్రయోగ పేరును పరిష్కరించి సమాధానం ఇచ్చిన చిరునామాను నివేదిస్తుంది. ఆ resolver ఎంచుకున్న విధానాన్ని అది నివేదించదు, మరియు ప్రశ్న DNS over HTTPS లో చుట్టబడినప్పుడు మార్గంలోని మధ్యవర్తి పరికరం పేరును అసలు చూడలేదు. చాలా భిన్నమైన రెండు యంత్రాలు ఒకే ఊరటనిచ్చే బ్యాడ్జ్ ఇస్తాయి: ఒకటి VPN 10.8.0.1 ను నెట్టింది మరియు బ్రౌజర్ దాన్ని వాడుతోంది; రెండోది బ్రౌజర్ సిస్టమ్ జాబితాను పట్టించుకోకుండా పేరును టన్నెల్ ద్వారా తన సొంత గుప్తీకరించిన ప్రదాతకు పంపింది.
ప్రైవేట్ పేరు విఫలమైన క్షణంలో ఈ భేదం ముఖ్యం. మొదటి అమరికలో కార్పొరేట్ జోన్ కోసం VPN resolver సమాధానం ఇస్తుంది; రెండోదానిలో బ్రౌజర్ దాన్ని అసలు అడగలేదు, కాబట్టి చిన్న హోస్ట్ పేరు పరిష్కారం కాదు, ఆ వైఫల్యం పాడైన VPN లా కనిపిస్తుంది. ఈ తనిఖీ మరో లీక్ పరీక్ష కాదు, ఒక resolver కి మాత్రమే తెలిసిన పేరు కోసం చేసే శోధన.
రెండో అపోహ: బ్రౌజర్ టన్నెల్ నుండి బయటకు వెళ్తుంది
DNS చిరునామాను ఎంచుకుంటుంది, రూటింగ్ కనెక్షన్‌ను మోసుకెళ్తుంది, ఈ రెండూ వేర్వేరు పొరలు. పబ్లిక్ DoH ప్రదాతకు పంపిన ప్రశ్న ఇప్పటికీ రూట్ చేయగల చిరునామాకు TCP port 443 నే. మీ రూట్ పట్టిక డిఫాల్ట్ రూట్‌ను టన్నెల్ లోకి పంపితే, ఆ ప్రశ్న కూడా టన్నెల్ గుండానే వెళ్తుంది. resolver బ్రాండ్ మార్గాన్ని నిర్ణయించదు.
బ్రౌజర్ DoH మార్చేది పేర్ల గ్రహీతను. అది నిజమైన గోప్యతా నిర్ణయం మరియు నిజమైన విధాన నిర్ణయం, కానీ రూటింగ్ బైపాస్ కాదు. పేర్లు VPN ఆపరేటర్ వద్దే ఉండాలని మీ అవసరం అయితే, మరొకరికి పంపే గుప్తీకరించిన ప్రశ్న ఆ అవసరాన్ని విఫలం చేస్తుంది, అయినా నిజమైన కనెక్షన్ కోసం టన్నెల్ నే వాడుతుంది.
మూడో అపోహ: ప్రతి VPN ప్రతి బ్రౌజర్‌ను ఓవర్‌రైడ్ చేస్తుంది
బ్రౌజర్‌లో సురక్షిత DNS కి స్విచ్ కాదు, మోడ్‌లు ఉంటాయి: ఆఫ్, ఫాల్‌బ్యాక్ ఉన్న డిఫాల్ట్ ప్రదాత, అనుకూల టెంప్లేట్, లేదా ఆపరేటింగ్ సిస్టమ్ లేదా సంస్థ విధించే విధానం. ఫాల్‌బ్యాక్ కేసు మాత్రమే అప్పుడప్పుడు వచ్చే నివేదికలను కలిగిస్తుంది. గుప్తీకరించిన ఎండ్‌పాయింట్ అందుబాటులో లేనప్పుడు, బ్రౌజర్ సిస్టమ్ resolver కి వెనక్కి వెళ్లవచ్చు, కాబట్టి అదే ల్యాప్‌టాప్ సోమవారం ప్రైవేట్ పేరును సరిగ్గా పరిష్కరిస్తుంది, మంగళవారం కాదు.
అదే సమయంలో, చాలా VPN క్లయింట్లు కనెక్షన్ లేచినప్పుడు సిస్టమ్ resolver ను సెట్ చేస్తాయి, అది పడిపోయినప్పుడు మునుపటిదాన్ని పునరుద్ధరిస్తాయి. అనుకూల గుప్తీకరించిన resolver ను పట్టుకున్న బ్రౌజర్ ఆ పునరుద్ధరణను అసలు గమనించదు. అందుకే ఒకే ప్రొఫైల్ రెండు ల్యాప్‌టాప్‌లలో వేర్వేరుగా ప్రవర్తిస్తుంది, అందుకే బ్రౌజర్ ఇంకా మరొకరిని అడుగుతుండగా resolv.conf సరిగ్గా కనిపిస్తుంది.
resolvectl status # per-link DNS servers and split-DNS domains
scutil --dns | head -30 # macOS resolver order for each domain
nslookup intranet.corp 10.8.0.1 # ask the VPN resolver directlyకనెక్ట్ అయి ఉన్నప్పుడు వాటిని నడపండి, ప్రతి resolver క్లెయిమ్ చేసే డొమైన్‌లను గుర్తించి, బ్రౌజర్ తన మోడ్ గురించి నివేదించే దానితో పోల్చండి. Mozilla DoH పత్రం బ్రౌజర్ డిఫాల్ట్ మరియు ఫాల్‌బ్యాక్ ప్రవర్తన ఎలా పని చేయాలో సహేతుకమైన వివరణ.
నిర్ణయానికి ఒకటి కాదు, మూడు ఇన్‌పుట్‌లు
ప్రైవేట్ పేర్లు, ఆపరేటర్ పై నమ్మకం మరియు చేరుకోగలిగే సామర్థ్యం సరైన ఏర్పాటును నిర్ణయిస్తాయి. VPN resolver కి మాత్రమే తెలిసిన పేర్లు విభజిత DNS ను బలవంతం చేస్తాయి: ప్రైవేట్ సఫిక్స్ నెట్టిన resolver కి వెళ్తుంది, మిగతావన్నీ పబ్లిక్ పేర్ల కోసం మీరు ఎంచుకున్న విధానాన్ని అనుసరిస్తాయి. పబ్లిక్ పేర్లు కూడా ఆ resolver కి వెళ్లాలా లేదా ప్రత్యేక సేవకు వెళ్లాలా అని ఆపరేటర్ పై నమ్మకం నిర్ణయిస్తుంది. మీరు ఎంచుకున్న గుప్తీకరించిన resolver ఈ నెట్‌వర్క్‌లో వాడదగినదా అని చేరుకోగలిగే సామర్థ్యం నిర్ణయిస్తుంది.
| Condition | What it forces |
|---|---|
| Internal names must resolve | Split DNS: private suffixes to the VPN resolver, the rest to your chosen default |
| Queries must stay with one operator | Pin both the system resolver and the browser mode, and disable fallback |
| Resolver only reachable through the tunnel | Keep the pushed resolver; do not point DoH at an endpoint your routes exclude |
ఈ వరుసలలో ఏదీ సార్వత్రిక సిఫార్సు కాదు. VPN నడిపే resolver పరిశీలనలను ఆ ఆపరేటర్ వద్దే కేంద్రీకరిస్తుంది; ప్రత్యేక సేవ అడిగిన పేర్లకు మరో గ్రహీతను జోడిస్తుంది. మీరు విధానాన్ని చదవకపోతే, ఏ ఏర్పాటు నిల్వ గురించి ఏమీ నిరూపించదు.
ప్రతి ప్రొఫైల్ కు నిర్ణయాన్ని రాసుకోండి, ఎందుకంటే ఈ సెట్టింగ్‌లు జరుగుతుంటాయి. గత నెల resolver ను నెట్టిన ప్రొఫైల్ ఈరోజు ఏమీ నెట్టకపోవచ్చు, బ్రౌజర్ మాత్రం ఇంకా సమాధానం ఇచ్చే పాత అనుకూల ఎండ్‌పాయింట్‌ను సంతోషంగా ఉంచుకుంటుంది. నోట్‌లో ఉండాల్సింది resolver చిరునామా, అది కలిగి ఉన్న సఫిక్స్‌లు మరియు బ్రౌజర్ మోడ్, సేవ బ్రాండ్ కాదు.
మీరు కాన్ఫిగర్ చేశానని అనుకునే విధానాన్ని పరీక్షించండి
బ్యాడ్జ్ తో కాదు, పేరుతో పరీక్షించండి. సిస్టమ్ resolver ద్వారా ఒక పబ్లిక్ పేరు, ఒక ప్రైవేట్ పేరు పరిష్కరించి, తర్వాత బ్రౌజర్ లోపల దాని సొంత సురక్షిత DNS సెట్టింగ్‌తో మీరు వాడాలనుకునే మోడ్‌లో పునరావృతం చేయండి. ప్రైవేట్ పేరు బ్రౌజర్‌లో మాత్రమే విఫలమైతే, ఒక్క VPN సెట్టింగ్ కూడా తాకకుండా గ్రహీత అసమతుల్యతను కనుగొన్నారు.
తర్వాత మళ్లీ కనెక్ట్ అయి పునరుద్ధరణను తనిఖీ చేయండి, ఎందుకంటే హ్యాండ్‌ఆఫ్ బగ్‌లు అక్కడే ఉంటాయి: డిస్‌కనెక్ట్ చేయండి, మునుపటి resolver తిరిగి వచ్చిందని నిర్ధారించండి, మళ్లీ కనెక్ట్ అవ్వండి, నెట్టినది తిరిగి వచ్చిందని నిర్ధారించండి. చివరగా, నిర్వహిత విధానంతో ఉన్న బ్రౌజర్ ఉంటే పరీక్షించండి, ఎందుకంటే ఆ మోడ్ మీ మార్పును పూర్తిగా తిరస్కరించి నిశ్శబ్దంగా మునుపటి resolver నే ఉంచవచ్చు.
పేర్ల స్థలం ప్రశ్నతో ప్రారంభించండి, దీనిలో చాలావరకు తప్పించుకుంటారు. యంత్రం అంతర్గత పేర్లను చేరుకోవాలంటే, బ్రౌజర్ గుప్తీకరించిన resolver పబ్లిక్ సగం గురించిన నిర్ణయం మాత్రమే, ప్రైవేట్ సగం VPN నెట్టిన దాని వద్దే ఉంటుంది.