openfortivpn தொடர்ந்து DNS ஐ மேலெழுதுகிறதா? உண்மையான உரிமையாளரைக் கண்டறியுங்கள்

இணைப்பு மேலெழும்பும் தருணத்திலிருந்தே பின்பற்றுங்கள்: கிளையண்ட் அங்கீகரிக்கிறது, pppd பேச்சுவார்த்தை நடத்துகிறது, பின்னர் ஏதோ இயக்க முறைமையில் DNS அமைப்புகளை எழுதுகிறது. VPN உங்கள் தீர்வியை மாற்றியது என்று மட்டும் தெரிந்தால், அந்த நிலைகளில் எது அதைச் செய்தது என்று இன்னும் தெரியவில்லை. அவற்றில் இரண்டு செய்ய முடியும், ஆவணப்படுத்தப்பட்ட pppd ஒருங்கிணைப்பைப் பயன்படுத்தும் கிளையண்டில் அவை ஒரே நடிகராகத் தோன்றும் அளவுக்கு நெருக்கமாக இயங்குகின்றன. எழுத்தாளரைப் பெயரிடுவது முதல் படி; அவரது மாற்றீட்டைத் தேர்ந்தெடுப்பது இரண்டாவது, அது அதன் சொந்த தோல்வி முறைகளைக் கொண்ட தனி முடிவு.

கீழேயுள்ள வரிசை கிளையண்டை வெளிப்புறமாகப் பின்பற்றுகிறது: இணைப்பு எதை மாற்றியது, எந்த சுவிட்ச் எந்த எழுத்தாளரை அடக்குகிறது, யார் பொறுப்பேற்க வேண்டும், மற்றும் முடிவு மறுஇணைப்பைத் தாங்குகிறதா என்பதை எப்படி உறுதிப்படுத்துவது. ஒவ்வொரு நிலையும் வெவ்வேறு தடத்தை விட்டுச் செல்கிறது, அந்தத் தடமே பரிமாற்றம் உண்மையில் நடந்ததா என்பதை உங்களுக்குச் சொல்கிறது.

இணைப்பு உண்மையில் எதை மாற்றியது என்பதிலிருந்து தொடங்குங்கள்

உங்கள் வழக்கமான கட்டளையுடன் ஒரு முறை இணைத்து முன் மற்றும் பின் தீர்வை ஒப்பிடுங்கள். systemd-resolved இயக்கும் Linux புரவலனில், resolvectl status ஒவ்வொரு இணைப்பிற்கும் DNS சேவையகங்கள் மற்றும் தேடல் களங்களை அச்சிடுகிறது, மேலும் தனது சொந்த சேவையகங்களைச் சுமக்கும் புதிய tun அல்லது ppp இணைப்பு கிளையண்ட் பக்க புதுப்பிப்பின் விரல்ரேகை. macOS இல், scutil --dns தீர்வி உள்ளமைவை பயன்பாடுகள் அதை அணுகும் வரிசையில் காட்டுகிறது.

அதை நீங்கள் மாறும் என்று எதிர்பார்த்த கோப்புடன் ஒப்பிடுங்கள். ஒவ்வொரு இணைப்பு பார்வையில் உள்ள இணைப்பு-பிணைப்பு உள்ளீடு மற்றும் மீண்டும் எழுதப்பட்ட /etc/resolv.conf இரண்டு வெவ்வேறு முடிவுகள், இரண்டாவது வேறு ஏதோ முழுமையாக நிர்வகிக்கும் குறியீட்டு இணைப்பாக இருக்கலாம். தீர்வியின் முகவரி, தேடல் களங்கள் மற்றும் இடைமுகத்தின் பெயரை ஒரே தருணத்தில் பதிவு செய்யுங்கள்; அவற்றில் ஏதேனும் ஒன்றில் மாற்றம் வேறு எழுத்தாளரைச் சுட்டுகிறது. அந்த அடிப்படைக் கோடு இல்லாமல், ஒவ்வொரு பிந்தைய திருத்தமும் மூன்று கூறுகளில் எது நகர்ந்தது என்பதற்கான ஊகமே.

இரண்டு சுவிட்சுகள் மற்றும் ஒவ்வொன்றும் அடக்கும் எழுத்தாளர்

openfortivpn தான் கட்டுப்படுத்தக்கூடிய இரண்டு எழுத்தாளர்களையும் அணைக்கும் விருப்பத் துண்டை ஆவணப்படுத்துகிறது, மேலும் ஒவ்வொரு சுவிட்சுக்கும் கையேடு அதே அமைப்பாகக் கருதும் முழுமையாக எழுதப்பட்ட சமமான ஒன்று உள்ளது.

openfortivpn gw.example.com:443 --no-dns --pppd-no-peerdns
# written out in long form
openfortivpn gw.example.com:443 --set-dns=0 --pppd-use-peerdns=0

--no-dns கிளையண்ட் நுழைவாயிலிலிருந்து கற்ற DNS சேவையகங்களைப் பயன்படுத்துவதை நிறுத்துகிறது, அதேசமயம் --pppd-no-peerdns pppd துணையின் DNS ஐ கணினிக்குள் தள்ளுவதை நிறுத்துகிறது. upstream கையேடு PPP வழியாக DNS புதுப்பிப்புகள் கிளையண்டின் சொந்த DNS புதுப்பிப்புகளுடன் போட்டியிடக்கூடும் என்று எச்சரிக்கிறது, எனவே இரண்டில் ஒன்றைப் போதுமானது என்று கருதுவதற்குப் பதிலாக இரண்டு சுவிட்சுகளும் துண்டில் இருக்க வேண்டும்.

எந்த சுவிட்சும் மாற்று தீர்வியைப் பெயரிடவில்லை, எதுவும் பிணைய மேலாளர், DHCP கிளையண்ட் அல்லது தனி VPN ஒருங்கிணைப்பை பின்னர் தீர்வை எழுதுவதிலிருந்து தடுக்கவில்லை. இரண்டு எழுத்தாளர்களை அடக்குவது புலத்தை உரிமையாக்காமல் திறந்தே வைக்கிறது. மூன்றாவது கூறு ஏற்கனவே DNS ஐ நிர்வகித்தால், துண்டு நீங்கள் கவனிக்கக்கூடிய எதையும் மாற்றாது; எதுவும் அதை நிர்வகிக்கவில்லை என்றால், தனிப்பட்ட பெயர் தீர்வின் ஒரே மூலத்தை நீங்கள் இப்போது அகற்றிவிட்டீர்கள். மாற்று உரிமையாளர் முதலில் தேர்ந்தெடுக்கப்பட்டு தனியாகச் சோதிக்கப்பட்டால் மட்டுமே இது செல்லுபடியாகும் ஏற்பாடு.

எதையும் முடக்குவதற்கு முன் உரிமையாளரைத் தேர்ந்தெடுங்கள்

வேலைப் பெயர்களுக்கான வினவல்களுக்கு யார் பதிலளிப்பார் என்பதை முதலில் முடிவு செய்யுங்கள், ஏனெனில் அந்தத் தேர்வு அதற்குப் பிந்தைய அனைத்தையும் கட்டுப்படுத்துகிறது. ஏற்கனவே உள்ள தீர்வியை வைத்திருப்பது என்பது தனிப்பட்ட மண்டலம் கிளையண்ட் இருக்கும் எந்த இடத்திலிருந்தும் ஏற்கனவே அணுகக்கூடியதாக இருக்க வேண்டும், மேலும் அலுவலகத்திற்குள் உள்ள தனிப்பட்ட தீர்விக்கு சுரங்கப்பாதை மேலெழும்போதும் தாங்கும் பாதை தேவை. ஒவ்வொரு வினவலையும் ஒரே உள் சேவைக்கு அனுப்புவது கூர்மையான தோல்வி முறையைக் கொண்ட மூன்றாவது கொள்கை: அந்தச் சேவை அணுக முடியாததாக இருக்கும்போது, பொது பெயர்கள் தனிப்பட்ட பெயர்களுடன் சேர்ந்து தோல்வியடைகின்றன.

பாதை உரிமை வேண்டுமென்றே தனியாகவே உள்ளது. DNS ஐ மாற்றியதால் பாதை விருப்பங்கள் தேவையில்லை, மேலும் மாற்றீட்டை நிறுவாமல் பாதை நிறுவலை முடக்குவது நீங்கள் இப்போது தேர்ந்தெடுத்த தீர்வியை அணுக முடியாததாக்கலாம். அனுமதிப்பாதை அட்டவணையில் குறிப்பாக தீர்வியின் முகவரிக்காகப் பாருங்கள், நீங்கள் தற்செயலாகச் சோதித்த பயன்பாட்டுத் துணைப்பிணையத்திற்காக மட்டும் அல்ல.

தீர்வை ஒவ்வொரு கோப்பிற்கும் அல்ல, ஒவ்வொரு இணைப்பிற்கும் சரிபார்க்கவும்

வரம்புக்குட்பட்ட அல்லது களம் வாரியான தீர்வைக் கொண்ட புரவலனில் பயன்பாடுகள் உண்மையில் எதைப் பயன்படுத்துகின்றன என்பதன் பட்டியல் ஒரு /etc/resolv.conf அல்ல, எனவே தளம் தீர்வியின் நிலையை வெளிப்படுத்தும் விதமாகவே படியுங்கள்.

resolvectl status
resolvectl query vpn.internal.example.com
resolvectl query example.com
ip route get 10.20.0.53

இணைப்பு மேலெழுந்த பிறகு ஒரு தனிப்பட்ட பெயரையும் ஒரு பொது பெயரையும் கேளுங்கள், எந்த இணைப்பு எதற்குப் பதிலளித்தது என்பதைக் குறிக்கவும். VPN இணைப்பு களம் வாரியான தேடல் பட்டியலைச் சுமக்கும் இடத்தில், தனிப்பட்ட பெயர் சரியாகத் தீர்க்கப்படலாம் அதேசமயம் பொது பெயர் இன்னும் உள்ளூர் தீர்விக்குச் செல்கிறது, அந்தப் பிரிவு தோல்வி அல்ல, வேலை செய்யும் வடிவமைப்பு. தனிப்பட்ட வினவல் தோல்வியடைந்தால், மீண்டும் DNS ஐத் தொடுவதற்கு முன் தீர்விக்கான பாதையைச் சரிபார்க்கவும்; அது வெற்றியடைந்தும் பயன்பாடு தோல்வியடைந்தால், பயன்பாடு அதன் சொந்த தேக்ககப்படுத்தப்பட்ட அல்லது தனியாக உள்ளமைக்கப்பட்ட தீர்வியைப் படிக்கலாம்.

மீண்டும் இணைத்து துண்டிக்கப்பட்ட நிலையை உறுதிப்படுத்துங்கள்

இணைப்பைக் கீழே இறக்கி இரண்டு வினவல்களையும் மீண்டும் செய்யுங்கள். தேர்ந்தெடுக்கப்பட்ட உரிமையாளர் நிறுவியதை அதே உரிமையாளரே அகற்ற வேண்டும் அல்லது மீட்டெடுக்க வேண்டும், நீங்கள் அமைதியாக்கிய கிளையண்ட் அதை விட்டுச் செல்லக்கூடாது. சுரங்கப்பாதையை விட நீண்ட காலம் நீடிக்கும் பழைய இணைப்பு-உள்ளீடு இனி அணுக முடியாத முகவரிக்கு தனிப்பட்ட வினவல்களை அனுப்பிக்கொண்டே இருக்கிறது.

பிறகு மீண்டும் இணைத்து அதே மூன்று மதிப்புகளைப் படியுங்கள்: தீர்வியின் முகவரி, தேடல் களங்கள், இடைமுகம்.

அவை நீங்கள் எழுதிய கொள்கையுடன் பொருந்தினால், பரிமாற்றம் முடிந்தது, VPN கிளையண்ட் இனி எழுத்தாளர்களில் ஒன்றல்ல. இணைப்பு மேலெழுந்த சில வினாடிகளுக்குப் பிறகு ஒரு மதிப்பு பின்னோக்கி நகர்ந்தால், வேறு ஏதோ இன்னும் உள்ளமைவைப் பயன்படுத்துகிறது, அடுத்த படி மற்றொரு கொடியைச் சேர்ப்பது அல்ல, அந்தக் கூறை அடையாளம் காண்பது. நீங்கள் விரும்பும் இறுதி நிலை நிகழ்வற்றது: ஒரு உரிமையாளர், ஒரு ஆவணப்படுத்தப்பட்ட கொள்கை, மற்றும் சுரங்கப்பாதை இருப்பதற்கு முன்பு இருந்ததைப் போலவே சரியாகத் தீர்க்கும் துண்டிக்கப்பட்ட புரவலன்.