మీ స్ప్లిట్ టన్నెల్ యాప్కు చేరుతుంది కానీ దాని DNS సర్వర్కు కాదు
స్ప్లిట్ టన్నెల్ యాప్ సబ్నెట్ను రూట్ చేయగలదు మరియు పక్కన ఉన్న రిజాల్వర్ను వదిలేయగలదు. హోస్ట్ రూట్ను జోడించండి, ఆపై Windows నిజంగా ఏ సర్వర్ను ఎంచుకుంటుందో తనిఖీ చేయండి.
యాప్ సబ్నెట్ను రూట్ చేయడం స్ప్లిట్ టన్నెల్ స్పష్టమైన భాగం మరియు అది మొత్తం పని కాదు. రిజాల్వర్ తరచుగా తాను సేవ చేసే యాప్ కంటే వేరే చిరునామాలో కూర్చుంటుంది, కాబట్టి పని చేసే టన్నెల్ కూడా శోధనను దాని బయట వదిలేయగలదు. 10.80.0.0/16 మాత్రమే మోసే ప్రొఫైల్ 10.90.0.53 కోసం ప్రశ్నను స్థానిక ఇంటర్ఫేస్ ద్వారా పంపుతుంది, అక్కడ ప్రైవేట్ జోన్ లేదు. రిజాల్వర్ మార్గాన్ని జోడించండి, ఆపై సమస్య రెండవ సగం చూడండి: క్లయింట్ నిజంగా ఏ సర్వర్ను ఎంచుకుంటుంది.
అపోహ: ఒక మార్గం మొత్తం సేవను కవర్ చేస్తుంది
స్ప్లిట్ టన్నెల్ అనేది కనెక్షన్ ద్వారా వెళ్లే గమ్యాల జాబితా, సేవ వివరణ కాదు. యాప్ సబ్నెట్ మరియు రిజాల్వర్ చిరునామా రెండు గమ్యాలు, ప్రొఫైల్ ఒకదాన్ని మరొకటి లేకుండా మోయగలదు. అలా జరిగినప్పుడు, యాప్ చిరునామా ద్వారా చేరుకోగలిగినా దాని పేరు విఫలమవుతుంది, ఇది రూటింగ్ ఖాళీగా కాకుండా DNS లోపంగా కనిపిస్తుంది.
రిజాల్వర్ చుట్టూ ఉన్న సబ్నెట్ కూడా స్వయంచాలకంగా కవర్ కాదు. ఒక చిరునామాకు హోస్ట్ రూట్ ఆ రిజాల్వర్కు సరిపోతుంది మరియు దాని పొరుగువారిని తెరవదు. హోస్ట్ రూట్ అర్థం అదే: రూపకల్పనలో ఇరుకైనది, తదుపరి సేవ అదే సబ్నెట్లో కనిపించినప్పుడు మరచిపోవడం సులభం.
శోధన పని చేయడానికి మూడు విషయాలు నిజం కావాలి: క్లయింట్ రిజాల్వర్ చిరునామాను టన్నెల్ ద్వారా రూట్ చేస్తుంది, గేట్వే ఆ అభ్యర్థనను అంగీకరించి పంపిస్తుంది, రిజాల్వర్ పొందిన మూలాన్ని అంగీకరిస్తుంది. ప్రత్యుత్తరం కూడా అంగీకరించిన మార్గం ద్వారా తిరిగి రావాలి. వాటిలో ఒకటి లేకపోతే లక్షణం అదే ఉంటుంది, కాబట్టి కాన్ఫిగరేషన్ను తాకే ముందు చిరునామాల పట్టికను రాయడం విలువైనది.
ప్రొఫైల్ ఏ చిరునామాలను మోయాలో నిర్ణయించండి
గమ్యాలను వరుసగా జాబితా చేయండి: యాప్ నెట్వర్క్, రిజాల్వర్ చిరునామా మరియు టన్నెల్ను స్వయంగా ముగించే పబ్లిక్ ఎండ్పాయింట్. మూడవదాన్ని ఎప్పుడూ టన్నెల్లోకి రూట్ చేయకూడదు, ఎందుకంటే బాహ్య కనెక్షన్కు టన్నెల్కు ముందు ఉన్న మార్గం కావాలి.
| Destination | Coverage this example needs |
|---|---|
| Application network | 10.80.0.0/16 through the VPN |
| Private resolver | 10.90.0.53/32 through the VPN |
| Public VPN endpoint | Normal internet path, outside the tunnel |
DNS కోసం UDP మరియు TCP రెండింటినీ చేర్చండి, ఎందుకంటే అమలులు UDPతో పాటు TCPకి మద్దతు ఇస్తాయని ఆశిస్తారు, నిరోధించిన TCP మార్గం శుభ్రమైన వైఫల్యాలకు బదులుగా నెమ్మదైన, పాక్షిక వైఫల్యాలను ఉత్పత్తి చేస్తుంది. ప్రైవేట్ జోన్ IPv6 ద్వారా కూడా సేవ చేయబడితే, సమానమైన హోస్ట్ మినహాయింపు IPv6 చిరునామా మరియు ప్రీఫిక్స్ను ఉపయోగిస్తుంది మరియు అది ప్రత్యేక ఎంట్రీ.
ఏదైనా జోడించే ముందు ప్రొఫైల్ ఇప్పటికే ఏమి కవర్ చేస్తుందో నమోదు చేయండి. నకిలీ మార్గం హానికరం కాదు, కానీ ఊహించని ఇప్పటికే ఉన్న మార్గం, ప్రొఫైల్ మీకు ఇచ్చిన చిరునామా ప్రణాళికకు భిన్నమైన ప్రణాళిక కోసం రూపొందించబడిందని చెబుతుంది.
కనెక్షన్ యజమాని ద్వారా హోస్ట్ రూట్ను జోడించండి
స్థానికంగా నిర్వహించబడే స్థానిక Windows ప్రొఫైల్ కోసం, మార్గం యంత్రం యొక్క గ్లోబల్ రౌటింగ్ పట్టికకు కాదు, కనెక్షన్కు చెందుతుంది. మొదట జోడింపును ప్రివ్యూ చేయండి, తర్వాత ప్రొఫైల్ ఉపయోగించే అదే పరిధితో దాన్ని వర్తించండి.
Add-VpnConnectionRoute -ConnectionName 'Office VPN' -DestinationPrefix '10.90.0.53/32' -WhatIf Get-VpnConnection -Name 'Office VPN' | Select-Object -ExpandProperty Routes
మొదటి ఆదేశం ఏమీ ఇన్స్టాల్ చేయకుండా మార్పును ప్రివ్యూ చేస్తుంది, రెండవది ప్రొఫైల్ ప్రస్తుతం మోస్తున్న మార్గాలను జాబితా చేస్తుంది. Microsoft యొక్క Add-VpnConnectionRoute సూచన ప్రతి వినియోగదారు మరియు అందరు వినియోగదారుల పరిధులను నమోదు చేస్తుంది; అందరు వినియోగదారుల ప్రొఫైల్కు దాని స్వంత పరిధి పరామితి అవసరం, అందరు వినియోగదారుల ప్రొఫైల్కు వ్యతిరేకంగా ప్రతి వినియోగదారు ఆదేశం విఫలమవుతుంది లేదా తప్పు స్థలంలో దిగుతుంది.
ప్రొఫైల్ నిర్వహించబడినప్పుడు లేదా విక్రేత క్లయింట్ నుండి వచ్చినప్పుడు, మార్పు ఆ యజమానికి చెందుతుంది. కనెక్షన్ విధానంపై శాశ్వత సిస్టమ్ మార్గాన్ని పేర్చడం విధానం మళ్లీ వర్తించే వరకు మరియు మార్గం పోయే వరకు పని చేస్తుంది, ఇది సాధారణంగా పరీక్ష సమయంలో కాదు, మద్దతు కాల్ సమయంలో జరుగుతుంది. ఆ వైఫల్యం నిశ్శబ్దం: మార్గం మాయమవుతుంది, పేరు పరిష్కారం ఆగిపోతుంది, ఎవరూ రెండు సంఘటనలను కలపరు. మార్పును యజమాని సొంత రికార్డులో ఉంచండి, తదుపరి పునర్వినియోగం దాన్ని తుడిచివేయడం బదులు మోస్తుంది.
వర్తించిన తర్వాత మార్గం అమల్లోకి వచ్చిందని ఊహించడం బదులు ప్రొఫైల్ను మళ్లీ కనెక్ట్ చేయండి. ప్రత్యక్ష కనెక్షన్పై మార్గ మార్పులు ఎల్లప్పుడూ తీసుకోబడవు, మళ్లీ కనెక్ట్ చేయడం మీ వినియోగదారులు నిజంగా అనుభవించే స్థితిని కూడా పునఃసృష్టిస్తుంది.
క్లయింట్ నిజంగా ఏ రిజాల్వర్ను ఉపయోగించిందో తనిఖీ చేయండి
మార్గం రిజాల్వర్కు చిరునామా చేసిన ప్యాకెట్లను నియంత్రిస్తుంది. ఏ పేర్లు అక్కడికి పంపాలో అది నిర్ణయించదు, ఆ ఎంపిక ప్రత్యేక యంత్రాంగం. Windowsలో, ప్రభావవంతమైన పేరు స్థల నియమాలు ప్రతి డొమైన్కు రిజాల్వర్ను ఎంచుకోగలవు, ప్రొఫైల్ DNS సెట్టింగ్లు డిఫాల్ట్ను అందిస్తాయి. ఈ రెండు పొరలు ఎలాంటి లోపం ఉత్పత్తి చేయకుండా విభేదించవచ్చు, కాబట్టి ప్రత్యక్ష ప్రశ్న సాక్ష్యంలో సగం మాత్రమే.
Get-DnsClientNrptPolicy Resolve-DnsName app.svc.example -Server 10.90.0.53 -Type A
మొదటి ఆదేశం అమల్లో ఉన్న పేరు స్థల విధానాన్ని ముద్రిస్తుంది, రెండవది ప్రైవేట్ రిజాల్వర్ను నేరుగా యాప్ పేరు అడుగుతుంది. ప్రత్యక్ష సమాధానం మార్గం మరియు రిజాల్వర్ పని చేస్తున్నాయని రుజువు చేస్తుంది; యాప్ సొంత శోధన ఆ సర్వర్ను ఎంచుకుందని రుజువు చేయదు. దాన్ని అదే పేరు సాధారణ శోధన మరియు యాప్ పొందే సమాధానంతో పోల్చండి.
కాష్లు మరియు బ్రౌజర్ స్థాయి సురక్షిత DNSను పరిగణించండి, అది వినియోగదారు టైప్ చేసిన పేర్లకు సిస్టమ్ రిజాల్వర్ను పూర్తిగా బైపాస్ చేయగలదు. శోధన సఫిక్స్ మరో దారితప్పించే సూచన: అది చిన్న పేరును పూర్తిగా అర్హత కలిగిన పేరుగా విస్తరిస్తుంది, ఏ సర్వర్ సమాధానం ఇస్తుందనే దానితో ఎలాంటి సంబంధం లేదు.
చివర్లో మళ్లీ కనెక్ట్ అయి సాధారణ శోధనను పునరావృతం చేయండి, తర్వాత సాధారణ బ్రౌజింగ్ ఇప్పటికీ తన ఆమోదించిన విధానాన్ని అనుసరిస్తుందని నిర్ధారించండి. సంబంధం లేని పేరు పరిష్కారం కావడానికి ప్రైవేట్ రిజాల్వర్ను పబ్లిక్ ఒకటితో భర్తీ చేయడం పరిష్కారం కాదు, అది ప్రైవేట్ ప్రశ్నలను ఎప్పుడూ వెళ్లకూడని చోటుకు నిశ్శబ్దంగా తరలిస్తుంది.