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 வெற்றியடைந்த பிறகும் சுரங்கப்பாதை இன்னும் பயன்பாட்டு இலக்குக்கு வழிமாற்றுகிறது என்பதை உறுதிசெய்யவும். வழி, சேவை அணுகல் மற்றும் அங்கீகாரம் பெயர் தீர்த்தலில் இருந்து சுயாதீனமாக இருக்கும், செயல்படும் தேடல் செயல்திறன் பற்றி எதையும் சொல்லாது. தனிப்பட்ட பக்கம் மெதுவாக இருந்தாலும் தீர்க்கப்பட்டால், resolver தன் வேலையைச் செய்தது, பிரச்சினை பாதைக்கு நகர்ந்தது.