Pritunl యొక్క ప్రైవేట్ DNS విఫలమవుతుందా? ఒక సన్నని resolver మార్గాన్ని జోడించండి
VPN పూల్ను విస్మరించే ప్రైవేట్ resolver కు మూలానికి మినహాయింపు కావాలి, విస్తృత మార్గం కాదు. NAT ఎనేబుల్ చేసిన /32 జోడించి నిజమైన ప్రైవేట్ శోధనను పరీక్షించండి.
ప్రైవేట్ పేర్లు కార్పొరేట్ నెట్వర్క్లో అందరికీ పరిష్కరించబడతాయి, VPN లో అందరికీ గడువు ముగుస్తుంది. Resolver గేట్వేకు సమాధానమిస్తుంది, అక్కడికి మార్గం ఉంది, అయినా క్వెరీకి ఎప్పుడూ సమాధానం రాదు. లేనిది మరో పబ్లిక్ resolver లేదా విస్తృత మార్గం కాదు: ప్రైవేట్ DNS సర్వర్ సమాధానం ఇవ్వడానికి సిద్ధంగా ఉన్న మూల చిరునామా.
Resolver మీ క్లయింట్ పూల్ను తిరస్కరిస్తున్నట్లు నిర్ధారించండి
విఫలత్వం చేరుకోగలిగే సామర్థ్యం గురించి కాదు, మూలం గురించి అని నిరూపించడంతో ప్రారంభించండి. కనెక్ట్ అయిన క్లయింట్ నుండి ప్రైవేట్ resolver ను నేరుగా అడిగి, అభ్యర్థన సమయం ముగుస్తుందా లేదా తిరస్కరణగా తిరిగి వస్తుందా గమనించండి. dig @10.40.0.53 intranet.example.net +time=2 +tries=1 సమయం ముగుస్తుండగా గేట్వే నుండి అదే క్వెరీ విజయవంతమైతే అది resolver పై యాక్సెస్ విధానాన్ని సూచిస్తుంది. SERVFAIL సమాధానం పూర్తిగా వేరే చోటికి, సాధారణంగా జోన్ లేదా అప్స్ట్రీమ్ ఫార్వర్డర్కు సూచిస్తుంది.
పరీక్షకు ముందు క్లయింట్ చిరునామాను నమోదు చేయండి. క్లయింట్పై ip -4 addr show tun0, లేదా కన్సోల్లో చూపిన లీజ్, resolver ఏ పూల్ను చూస్తుందో చెబుతుంది.
తర్వాత మార్గం నిజంగా ఉందా అని నిర్ధారించండి. Resolver చిరునామాను టన్నెల్లోకి పంపే మార్గం ముందస్తు షరతు, పరిష్కారం కాదు; ప్యాకెట్లు ఎప్పుడూ చేరకపోతే మూల విధానం పరిగణించబడదు. క్లయింట్పై ip route get 10.40.0.53 తో దాన్ని తనిఖీ చేయండి.
అన్నింటినీ అనువదించే బదులు ఒక హోస్ట్ మార్గాన్ని జోడించండి
Pritunl యొక్క ప్రైవేట్ DNS మార్గదర్శకం సన్నని పరిష్కారాన్ని వివరిస్తుంది: resolver చిరునామా కోసం NAT ఎనేబుల్ చేసిన /32 మార్గం, ఆ చిరునామా క్లయింట్ల DNS సర్వర్గా ఎంచుకోబడి. మార్గం DNS ట్రాఫిక్కు మాత్రమే resolver చూసే మూలాన్ని మారుస్తుంది. అప్లికేషన్ ట్రాఫిక్ మీరు దాని కోసం ఎంచుకున్న మూల-సంరక్షణ రూపకల్పనను నిలుపుకుంటుంది.
ఇప్పటికే ఉన్న మార్గాలను అతివ్యాప్తి కోసం సమీక్షించిన తర్వాత, సర్వర్ మద్దతు ఉన్న మార్గ యజమాని ద్వారా దాన్ని కాన్ఫిగర్ చేయండి. పై ఉదాహరణలో గమ్యం NAT ఎనేబుల్ చేసిన 10.40.0.53/32, క్లయింట్ పూల్ 10.90.0.0/24 గానే ఉంటుంది. ఒక సేవను సరిచేయడానికి మొత్తం ప్రైవేట్ పరిధిని అనువదించవద్దు, ఎందుకంటే క్లయింట్ యొక్క నిజమైన చిరునామాపై ఆధారపడే ప్రతి డౌన్స్ట్రీమ్ విధానం దాని బదులు గేట్వేను చూడటం ప్రారంభిస్తుంది. పరీక్షా శోధన సమయంలో resolver యొక్క క్వెరీ లాగ్ను చూసి అది నిజంగా పొందే చిరునామాను నిర్ధారించండి. ఒక హోస్ట్ మార్గం మాత్రమే అనువాదం లేదా అనుమతి గురించి ఏమీ నిరూపించదు.
Resolver ఇంకా అనువదించిన మూలాన్ని UDP మరియు TCP పై అనుమతించాలి, దాని సమాధానాలు తిరిగి రాగలగాలి. మూలాన్ని మార్చడం తప్పిపోయిన జోన్ లేదా రికార్డును సృష్టించలేదు.
క్వెరీని సర్వర్ పంపుతుందా క్లయింట్ పంపుతుందా నిర్ణయించండి
Pritunl VPN Client DNS Mapping తో అనుబంధించిన DNS-ప్రాక్సీ ఏర్పాటును కూడా డాక్యుమెంట్ చేస్తుంది, ఇక్కడ సర్వర్ క్లయింట్ల కోసం అప్స్ట్రీమ్ క్వెరీలను ఫార్వర్డ్ చేస్తుంది. ఆ నమూనాలో అప్స్ట్రీమ్ మూలం సర్వర్ యొక్క స్వంత నెట్వర్క్ సందర్భానికి చెందుతుంది, క్లయింట్-వైపు మినహాయింపు తప్పు పరిష్కారం.
ఏదైనా జోడించే ముందు ఏ నమూనా క్రియాశీలంగా ఉందో గుర్తించండి. మూడు అతివ్యాప్తి మరమ్మతులు, ఒక ప్రాక్సీ, క్లయింట్పై resolver భర్తీ మరియు చేతితో చేసిన NAT స్క్రిప్ట్ సాధారణంగా ఎవరూ నిర్ధారించలేదని అర్థం: ఏ భాగం క్వెరీని పంపాలి. bootstrap కూడా తనిఖీ చేయండి: టన్నెల్ ఉనికిలోకి రాకముందు ఎండ్పాయింట్ కనుగొనే ఏకైక మార్గం ప్రైవేట్-మాత్రమే resolver కాకూడదు, శాశ్వత resolver మార్పు కనెక్షన్ కంటే ఎక్కువ కాలం ఉండకూడదు.
పబ్లిక్ వెబ్ పేజీ కాదు, ప్రైవేట్ శోధనను పరీక్షించండి
మార్పును వర్తింపజేసి మళ్లీ కనెక్ట్ అయిన తర్వాత, క్లయింట్ యొక్క ప్రభావవంత resolver కాన్ఫిగరేషన్ను పరిశీలించి, ఆ తర్వాత ప్రైవేట్ జోన్లో మాత్రమే ఉందని మీకు తెలిసిన పేరును పరిష్కరించండి. స్పష్టమైన సర్వర్ లేకుండా dig intranet.example.net క్లయింట్ నిజంగా ఏమి ఉపయోగిస్తుందో చూపిస్తుంది. తర్వాత ఆ శోధన తిరిగి ఇచ్చిన చిరునామాకు అభ్యర్థన పంపండి, ఎందుకంటే పరిష్కరణ మరియు సేవా యాక్సెస్ వేర్వేరు దశలు. DNS-over-HTTPS ద్వారా పబ్లిక్ సైట్లను లోడ్ చేసే బ్రౌజర్ ఆపరేటింగ్ సిస్టమ్ యొక్క ప్రైవేట్ resolver మార్గం గురించి ఏమీ నిరూపించదు. పబ్లిక్ ద్వితీయ resolver కూడా అంతర్గత జోన్కు అధికారం కాదు.
resolver చిరునామా, /32 మార్గం మరియు క్లయింట్ DNS సెట్టింగ్ను కలిపి సర్వర్ నోట్స్లో నమోదు చేయండి. ఆ కాన్ఫిగరేషన్లో సగం మాత్రమే పునరుద్ధరిస్తే అసలు విఫలత్వం మళ్లీ సంభవిస్తుంది.
చివరగా, DNS విజయవంతమైన తర్వాత కూడా టన్నెల్ అప్లికేషన్ గమ్యానికి మార్గం చూపుతోందని నిర్ధారించండి. మార్గం, సేవా యాక్సెస్ మరియు ప్రామాణీకరణ పేరు పరిష్కరణ నుండి స్వతంత్రంగా ఉంటాయి, పనిచేసే శోధన throughput గురించి ఏమీ చెప్పదు. ప్రైవేట్ పేజీ నెమ్మదిగా ఉన్నా పరిష్కరించబడితే, resolver తన పని చేసింది, సమస్య మార్గానికి మారింది.