Windows VPNలో తప్పు DNS సర్వర్: మెట్రిక్, బైండింగ్ క్రమం లేదా ప్రత్యయం
Windows యొక్క మూడు యంత్రాంగాలు DNS రిసాల్వర్ను ఎంచుకుంటాయి, అవి వేర్వేరు విధాలుగా విఫలమవుతాయి. పేరు స్థల పరిధి, ప్రపంచ క్రమం, లేదా సరిదిద్దడం పునఃకనెక్షన్ తర్వాత నిలిచి ఉంటుందా అనే దాని ఆధారంగా నిర్ణయించండి.
Windows క్లయింట్కు పనిచేసే సొరంగం ఉండవచ్చు, కార్పొరేట్ రిసాల్వర్ ఉండవచ్చు, అయినా అంతర్గత పేర్లు ఇంటి రౌటర్కు వెళ్లవచ్చు. ఏ సర్వర్ సమాధానం ఇస్తుందో మూడు వేర్వేరు యంత్రాంగాలు నిర్ణయిస్తాయి, అవి వేర్వేరు విధాలుగా విఫలమవుతాయి. మూడింటినీ సరిచేయాల్సిన అవసరం లేదు: ఏది ఆటలో ఉందో లక్షణం చెబుతుంది. క్రింది నిర్ణయ వృక్షం కొన్ని నిమిషాలు తీసుకుంటుంది మరియు మెట్రిక్ మార్పు, రిజిస్ట్రీ పునర్వ్యవస్థీకరణ మరియు NRPT నియమం కలిసి వచ్చి ఎవరికీ ఏది ఏమి చేసిందో తెలియని సాధారణ ఫలితాన్ని నిరోధిస్తుంది.
మూడు యంత్రాంగాలు నిర్ణయిస్తాయి, సాధారణంగా ఒకటి తప్పు
ఇంటర్ఫేస్ మెట్రిక్ ఇచ్చిన చిరునామా కుటుంబానికి అడాప్టర్లను క్రమబద్ధం చేస్తుంది. Tcpip\Linkage క్రింద బైండింగ్ క్రమం అనేది పాత కోడ్ మార్గాలు ఇంకా చూసే యంత్ర స్థాయి ఇంటర్ఫేస్ గుర్తింపుల జాబితా. పేరు విశ్లేషణ విధాన పట్టిక (NRPT) పేరు స్థలాన్ని నిర్దిష్ట సర్వర్లకు కట్టివేస్తుంది, ప్రత్యయ జాబితా చిన్న పేరు అసలు విస్తరించబడుతుందో లేదో నిర్ణయిస్తుంది. అవి స్వతంత్రం, అందుకే VPN అడాప్టర్పై సరైన రిసాల్వర్ మరెక్కడో ఉన్న పాత ప్రాధాన్యతకు ఓడిపోతుంది.
| What you see | Mechanism to check | First command |
|---|---|---|
| Every name is slow, public names sometimes wrong | Global adapter order: metric, then Linkage | Get-NetIPInterface |
| Internal names resolve to a public address | The query left through the home resolver, not the tunnel | Resolve-DnsName intranet.corp.example -Type A, then the same query with -Server 10.20.0.10 |
| Only corp.example names fail, public names fine | Namespace binding: NRPT or suffix | Get-DnsClientNrptRule |
| Short name fails, fully qualified name works | Suffix list on the adapter, with the corporate suffix ahead of other entries, or pushed by the server | Get-DnsClientGlobalSetting |
| Works, then breaks after a reconnect | Runtime setting that was never persisted | Get-VpnConnection for the stored profile, then Get-NetIPInterface again after a reconnect |
ఈ యంత్రాంగాలలో ఏదీ సొరంగం ఆవలి వైపు కాదు. VPN నెట్టే సర్వర్ పేరును విశ్లేషించలేకపోతే, క్లయింట్ వైపు ప్రతి సెట్టింగ్ కేవలం అలంకారం, కాబట్టి మొదటి నిర్ణయం రిసాల్వర్ స్వయంగా నేరుగా అడిగినప్పుడు సమాధానం ఇవ్వగలదా అనేది.
నిర్ణయం ఒకటి: నెట్టబడిన రిసాల్వర్ సమాధానం ఇవ్వగలదా?
సర్వర్ను స్పష్టంగా అడిగి సాధారణ శోధనతో పోల్చండి. సమాధానాల మధ్య వ్యత్యాసం ఎంపిక సమస్యను చేరుకోగల సమస్య నుండి వేరుచేస్తుంది, ఇక్కడ వేగవంతమైన శాఖ ఇదే:
Resolve-DnsName intranet.corp.example -Server 10.20.0.10 -Type A
Resolve-DnsName intranet.corp.example -Type Aమొదటిది విజయవంతమై రెండవది విఫలమైతే, రిసాల్వర్ చేరుకోగలదు మరియు Windows తప్పుగా ఎంచుకుంటోంది; క్రింది పేరు స్థలం మరియు క్రమ నిర్ణయాలకు వెళ్లండి. మొదటిది కూడా విఫలమైతే, క్లయింట్పై ఏదీ సహాయపడదు: UDP మరియు TCP 53 సొరంగం ద్వారా సర్వర్ను చేరుతున్నాయా, సర్వర్పై హోస్ట్ ఫైర్వాల్ పూల్ను వదిలేయదా, సర్వర్ సొంత ఫార్వర్డర్లు ఆరోగ్యంగా ఉన్నాయా చూడండి.
ఈ శాఖ వద్ద ఆగండి. మీరు చేరుకోలేని రిసాల్వర్కు NRPT నియమాన్ని వర్తింపజేయడం అదే వైఫల్యాన్ని ఎక్కువ తిరిగి తీసుకోవాల్సిన కాన్ఫిగరేషన్తో ఇస్తుంది, నిజమైన లోపాన్ని అధికారం ఉన్నట్లు కనిపించే నియమం వెనుక దాస్తుంది.
నిర్ణయం రెండు: ఒక పేరు స్థలమా లేదా ప్రతి ప్రశ్నా?
పరిధి సాధనాన్ని నిర్ణయిస్తుంది. కార్పొరేట్ పేర్లు మాత్రమే విఫలమైతే, యంత్రాన్ని పునర్వ్యవస్థీకరించే బదులు పేరు స్థలాన్ని కట్టండి: NRPT నియమం ఆ ప్రత్యయాన్ని సొరంగ రిసాల్వర్కు పంపి మిగతావన్నీ వదిలివేస్తుంది. ప్రతి శోధన ప్రభావితమైతే, సమస్య ప్రపంచ అడాప్టర్ ప్రాధాన్యత, మెట్రిక్ ప్రారంభించే స్థలం ఎందుకంటే అది సర్వర్ సెట్టింగ్ను మార్చదు.
ప్రతి చిరునామా కుటుంబానికి, రెండు ఇంటర్ఫేస్లపై మెట్రిక్ సెట్ చేసి, తర్వాత క్రమాన్ని నిర్ధారించండి:
Get-NetIPInterface | Select-Object ifIndex, InterfaceAlias, AddressFamily, InterfaceMetric
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv4
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv6పై పంక్తి నుండి సొరంగ అడాప్టర్ ifIndexతో 11ని మార్చండి; 11 LAN అడాప్టర్ అయితే, అదే ఆదేశం తప్పు మార్గాన్ని దించుతుంది. బదులుగా LAN అడాప్టర్ను పైకి లేపితే మరో వైపు నుండి అదే క్రమం చేరుతుంది: netsh int ip set interface interface="Ethernet" metric=15, మరియు రెండవ కుటుంబానికి netsh int ipv6 set interface interface="Ethernet" metric=15, ఎందుకంటే int ip IPv4ని మాత్రమే తాకుతుంది.
బైండింగ్ క్రమం మొదటి అడుగు కాదు, చివరి మార్గం. HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage పరికర గుర్తింపుల Bind జాబితాను ఉంచుతుంది, సొరంగ గుర్తింపును ముందుకు జరపడం ఏ అడాప్టర్ మొదట అడగబడుతుందో నిజంగా మారుస్తుంది, కానీ ఇది ప్రతి పేరు స్థలానికి పరిధి లేని యంత్ర స్థాయి రిజిస్ట్రీ విలువ. సవరించే ముందు దాన్ని ఎగుమతి చేసి, తర్వాత సొరంగాన్ని మళ్లీ కనెక్ట్ చేయండి, క్లయింట్ ఆశించే స్థితిలో క్రమం వర్తించేలా.
ఒక పేరు స్థలానికి, ఇరుకైన సాధనాన్ని ఎంచుకోండి:
Add-DnsClientNrptRule -Namespace ".corp.example" -NameServers 10.20.0.10
Get-DnsClientNrptRule | Select-Object Namespace, NameServersనిర్ణయం మూడు: మళ్లీ కనెక్ట్ అయిన తర్వాత సరిదిద్దడం నిలిచి ఉంటుందా?
తదుపరి డయల్-అప్ పునఃకనెక్షన్ వరకు పనిచేసే మెట్రిక్ ఎప్పుడూ సేవ్ చేయబడలేదు. L2TP/IPsec మరియు ఇతర కనెక్షన్ ప్రొఫైళ్లు కనెక్షన్ ప్రారంభమైనప్పుడు మళ్లీ సృష్టించబడతాయి, కాబట్టి సేవ్ చేసిన విలువ ఫోన్-బుక్ నమోదులో IpInterfaceMetric గా జీవిస్తుంది, కేవలం లైవ్ ఇంటర్ఫేస్పై మాత్రమే కాదు. కొన్ని వాతావరణాలు ఆ ఫీల్డ్ను ఇదే కారణంతో స్క్రిప్ట్ చేస్తాయి; మరికొన్ని నిర్వహణ విధానం నుండి ప్రాధాన్యతను నెట్టి చివరి బిందువును వదిలివేస్తాయి.
కాష్ మరియు నమోదు వేరే పొర. సొరంగం పైకి వచ్చిన తర్వాత వీటిని అమలు చేయడం పాత నమోదులను సరిచేసి క్లయింట్ను మళ్లీ నమోదు చేస్తుంది, కానీ ఏదీ అడాప్టర్ను పునర్వ్యవస్థీకరించదు:
ipconfig /registerdns
ipconfig /flushdnsఅదే పొరలో ఆఫ్ స్విచ్ ఉంది. భౌతిక అడాప్టర్పై డైనమిక్ నమోదును నిలిపివేయడం క్లయింట్ తన VPN వైపు చిరునామాను తప్పు పేరుతో ప్రకటించకుండా నిరోధిస్తుంది, ఇది పైన తాజాకరణ కంటే భిన్నమైన మరమ్మతు.
IPv6 నిర్ణయంలో తనకంటూ వరుసకు అర్హం. భౌతిక అడాప్టర్కు ప్రపంచ IPv6 చిరునామా ఉండి సొరంగం IPv4ని మాత్రమే మోస్తే, పేరు విశ్లేషణకు సొరంగం లేని మార్గాన్ని Windows ప్రాధాన్యం ఇవ్వవచ్చు. ఆ కుటుంబాన్ని విడిగా తనిఖీ చేయండి, ఎందుకంటే IPv4 కోసం సెట్ చేసిన మెట్రిక్ దాని గురించి ఏమీ చెప్పదు:
Get-NetIPInterface -AddressFamily IPv6 | Select-Object ifIndex, InterfaceAlias, InterfaceMetricLAN అడాప్టర్పై IPv6 నిలిపివేయడం ఆ మార్గాన్ని మరియు దానితో పాటు ప్రోటోకాల్ను తొలగిస్తుంది; IPv6 ఇంటర్ఫేస్పై మెట్రిక్ మార్పు, లేదా కార్పొరేట్ పేరు స్థలానికి NRPT నియమం, కుటుంబాన్ని ఉంచి ప్రాధాన్యతను సరిచేస్తుంది. ఆ లింక్కు IPv6 ఉండకూడదని నిర్ణయించుకోకపోతే ఇరుకైనదాన్ని ఎంచుకోండి.
పేర్కొన్న మూలంతో ధృవీకరించండి, ఒకే యజమానిని ఉంచండి
పేజీ లోడ్ అవుతుందా అని మాత్రమే కాదు, ఏ మూలం అమలులో ఉందో నివేదించే సాధనాలతో ధృవీకరించండి:
ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName fileserver.corp.example -Server 10.20.0.10 -Type Aతర్వాత వడపోతను ఎంపిక నుండి వేరు చేయండి, ఎందుకంటే అప్లికేషన్ లోపలి నుండి రెండూ ఒకేలా కనిపిస్తాయి. OpenVPN block-outside-dns ఇతర అడాప్టర్లపై పోర్ట్ 53ని నిరోధిస్తుంది; అది రిసాల్వర్ను ఎంచుకోదు. ఇప్పుడు ప్రతి ప్రశ్న విఫలమైతే, వడపోత ఏకైక చేరుకోగల సర్వర్ను నిరోధిస్తుండవచ్చు; కాన్ఫిగర్ చేసిన రిసాల్వర్ నిర్లక్ష్యం చేయబడుతుంటే, క్రమం లేదా పేరు స్థల నియమం తప్పు. రెండింటినీ ఒకేసారి మార్చడం నిరోధించిన ప్రశ్నను నిర్లక్ష్యం చేసిన ప్రశ్న నుండి వేరు చేయలేకుండా చేస్తుంది.
DNS విధానానికి ఒకే యజమానిని ఉంచండి: VPN ప్రొఫైల్, నిర్వహణ విధానం లేదా NRPT నియమం, అందులో రెండు కాదు. మూసివేసే ముందు:
- నెట్టబడిన రిసాల్వర్ స్పష్టంగా పేరు పెట్టినప్పుడు సమాధానం ఇస్తుంది, సాధారణ శోధన దాన్ని ఉపయోగిస్తుంది.
- మీరు మార్చిన నియమం లేదా మెట్రిక్ ప్రశ్నలను నిజంగా మోసే చిరునామా కుటుంబాన్ని కవర్ చేస్తుంది.
- సెట్టింగ్ డిస్కనెక్ట్ మరియు పునఃకనెక్ట్ తర్వాత నిలిచి ఉంటుంది, లేదా మీరు దాన్ని సేవ్ చేసిన ప్రొఫైల్కు తరలించారు.
- సరిగ్గా ఒక యంత్రాంగం అధికారం కలిగి ఉంది, మిగతావి ఉన్నట్లుగానే వదిలివేయబడ్డాయి.
క్రమాన్ని ముగించాల్సిన వస్తువుగా కాక పర్యావరణ స్థితిగా పరిగణించండి. పునఃకనెక్షన్ తర్వాత మరియు నెట్వర్క్ స్టాక్ను తాకే Windows నవీకరణ తర్వాత దాన్ని మళ్లీ తనిఖీ చేయండి, ఎందుకంటే వాటిలో ఏదైనా భౌతిక అడాప్టర్ను మళ్లీ ముందుకు తీసుకురావచ్చు.