OpenVPN தள்ளிய DNS புறக்கணிக்கப்படுகிறது: எந்த கூறு அதைப் பயன்படுத்துகிறது

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

தள்ளப்பட்ட விருப்பம் ஒரு முன்மொழிவு, நிறுவல் அல்ல

சேவையகத்தில், இரண்டு வழிமுறைகள் விளைவை அல்ல, நோக்கத்தை விவரிக்கின்றன:

push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"

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

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

தள்ளுதல் வந்ததை உறுதிசெய்து உரிமையாளரைக் கண்டறியவும்

தொடக்கியைப் பெயரிடுவதில் தொடங்கவும்: ஒரு வெறும் openvpn கட்டளை, systemd நிகழ்வு, NetworkManager அல்லது விற்பனையாளர் கிளையன். இது hook எங்கு வாழ முடியும் என்பதைத் தீர்மானிக்கிறது. systemd-resolved உள்ள ஹோஸ்ட்டில், resolvectl status ஒவ்வொரு இணைப்பையும் அது உண்மையில் பயன்படுத்தும் DNS சேவையகங்கள் மற்றும் தேடல் களங்களுடன் பட்டியலிடுகிறது, சுரங்கப்பாதை இணைப்பின் பெயர் எப்போதும் tun0 என இருப்பதில்லை.

தள்ளப்பட்ட முகவரி பதிவில் தெரிந்தும் எந்த இணைப்பிலும் இல்லாவிட்டால் ஒருங்கிணைப்பு இல்லை. அது இணைப்பில் இருந்தும் வினவல்கள் இன்னும் வேறெங்கோ சென்றால், பிரச்சினை எந்த வினவல்கள் அந்த இணைப்பைத் தேர்ந்தெடுக்கின்றன என்பதில் உள்ளது. NetworkManager dns=dnsmasq கோப்பில் /etc/NetworkManager/NetworkManager.conf உள்ளூர் அனுப்பியை இயக்குகிறது, அது பிரிக்கப்பட்ட DNS ஐ வேண்டுமென்றே செயல்படுத்துகிறது: VPN களத்திற்குள் உள்ள பெயர்கள் VPN தீர்விக்குச் செல்கின்றன, மற்றவை தங்கள் முந்தைய பாதையைத் தக்கவைக்கின்றன. அனைத்து போக்குவரத்தும் நகரும் என எதிர்பார்த்தபோது இந்த நடத்தை குறையாகத் தெரிகிறது; இணைப்புக்கான அமைப்புகளைச் சரிபார்க்கவும் nmcli connection show "My VPN" மூலம், அங்கு ipv4.dns மற்றும் ipv4.dns-search சாதனம் தெரிவிப்பதற்குப் பின்னால் உள்ள மதிப்புகளை வைத்திருக்கின்றன, அதை உடைந்தது எனக் கூறும் முன். ஒவ்வொரு வினவலும் உண்மையில் VPN தீர்வியை அடைய வேண்டுமானால், அகற்றவும் dns=dnsmasq ஐ NetworkManager.conf கோப்பிலிருந்து, NetworkManager ஐ மீண்டும் தொடங்கவும், அது பெயர்த் தீர்வை இணைப்பு அமைப்புகளுக்குத் திருப்பித் தருகிறது; இல்லையெனில் பிரிக்கப்பட்ட DNS ஐ வைத்துக்கொண்டு தள்ளப்பட்ட களப் பட்டியலைச் சரிசெய்யவும்.

Linux: விருப்பங்களைத் தீர்விக்கு வழங்கவும்

விநியோக தொகுப்புகள் இதற்காக hook வழங்குகின்றன, கிளையன் அதை இயக்க அனுமதிக்கப்பட வேண்டும். systemd-resolved இல்லாத ஹோஸ்ட்டில் வழக்கமான ஏற்பாடு:

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

systemd-resolved உடன் பழைய resolv.conf ஸ்கிரிப்ட் முக்கியமான எதையும் மாற்றாமல் இருக்கலாம், ஏனெனில் stub தீர்வி ஒவ்வொரு இணைப்பிற்கும் நிலையை வைத்திருக்கிறது. update-systemd-resolved உதவியாளர் பயன்படுத்தும் hook வடிவத்தை ஆவணப்படுத்துகிறது up-restart மற்றும் down-pre, இது ஒரு இடைமுகம் ஒரு இணைப்பு முயற்சியை விட நீண்ட காலம் நீடிக்கும் போது முக்கியமானது. எதைத் தேர்ந்தெடுத்தாலும், நிலையின் உரிமை ஒரு கூறுக்கே இருக்க வேண்டும். NetworkManager அருகே தொடர்பில்லாத hook சேர்த்தால் அதே இணைப்பிற்கு இரண்டு எழுத்தாளர்கள் கிடைப்பார்கள், அப்போது முடிவு உங்கள் கட்டமைப்பைப் பொறுத்ததல்ல, வரிசையைப் பொறுத்தது.

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

Windows மற்றும் macOS வெவ்வேறு பகுதிகளைப் பயன்படுத்துகின்றன

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

Get-DnsClientServerAddress -InterfaceAlias "My VPN"
Get-DnsClientNrptPolicy

முகவரி இல்லாவிட்டால், இதனால் அமைக்கவும் Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1, பின்னர் பின்னொட்டை அடாப்டரின் IPv4 பண்புகளில் சேர்க்கவும், அதனால் fileserver ஆகும் fileserver.corp.example. இயந்திரம் முழுவதும் SearchList மதிப்பு Tcpip\Parameters கீழ் அதே செய்கிறது. நீண்ட பெயர் தீர்க்கப்படும் ஆனால் வெறும் பெயர் தீர்க்கப்படாத இடத்தில், தீர்வி ஏற்கனவே சரியானது, குற்றம் தேடல் பட்டியலின். திருத்தங்கள் வரிசையாக: தள்ளவும் DOMAIN கிளையன் பின்னொட்டைக் கற்றுக்கொள்ள, அந்த பின்னொட்டை அடாப்டர் அல்லது இணைப்பின் தேடல் பட்டியலில் சேர்க்கவும், தற்காலிக நடவடிக்கையாகப் பெயரை இங்கே நிலைநிறுத்தவும் hosts கோப்பில், அல்லது LMHOSTS இல் Windows இல்; NetBIOS உலாவல் திசைவியைக் கடப்பதில்லை, எனவே அலுவலக LAN இல் குறுகிய பெயரைக் கண்டுபிடிக்கும் ஒளிபரப்பு ஒருபோதும் சுரங்கப்பாதை கிளையனை அடையாது.

block-outside-dns block-outside-dns என்பது Windows கிளையனின் நடத்தை, எடுத்துச் செல்லக்கூடிய சுயவிவர வரி அல்ல, அதை Linux அல்லது macOS சுயவிவரத்திற்கு நகலெடுப்பது அங்கே அதை மீண்டும் உருவாக்காது. Windows இல் பொது பெயர்கள் வேலை செய்து உள் பெயர்கள் தோல்வியடைந்தால், மேம்பட்ட அமைப்புகளின் கீழ் அடாப்டர் வரிசையை இதனுடன் ஒப்பிடவும் ipconfig /all. macOS இல் சேவைக்கான தீர்வி வரிசை கணினிக்கு உரியது, எனவே scutil --dns பயன்படுத்தி எந்த களத்திற்கு எந்த தீர்வி கேட்கப்படுகிறது எனப் பார்க்கவும், அறிவிக்கப்பட்ட எந்த ஒரு சுயவிவரத் திருத்தத்தையும் பொதுவானதல்ல, கிளையனைச் சார்ந்ததாகக் கருதவும்.

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

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

வினவல் எங்கு சென்றது என்பதை நிரூபிக்கவும்

ஒரு தேடலின் போது பிடிப்பு வாதத்தை முடிவுக்குக் கொண்டுவருகிறது: tcpdump -ni eth0 port 53 இயற்பியல் இடைமுகத்தில் வினவல்களைக் காட்டுகிறது, அதாவது அவை சுரங்கப்பாதைக்கு வெளியே செல்கின்றன, தீர்வி எப்போதும் மாற்றப்படவில்லை. dig @10.8.0.1 name.corp.example பின்னர் மீதமுள்ள இரண்டு நிகழ்வுகளைப் பிரிக்கிறது. நேரடி வினவல் பதிலளித்தால் தீர்வி வேலை செய்கிறது, கிளையன் அதைப் பயன்படுத்தவில்லை; நேரம் முடிந்தால் தீர்வி சுரங்கப்பாதை வழியாக அணுக முடியாதது, உள்ளூர் மாற்றம் எதுவும் உதவாது.

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

அணுகலில் VPN ஹோஸ்ட்டின் தீச்சுவரும் அடங்கும், அது குளத்திலிருந்து UDP மற்றும் TCP 53 ஐ அனுமதிக்க வேண்டும். மூடப்பட்ட துறைமுகம் சரியாக உடைந்த தள்ளுதல்போலவே தெரிகிறது, சுரங்கப்பாதை வலையமைப்பின் உள்ளிருந்து மட்டுமே பதிலளிக்கும் தீர்வியும் அப்படியே. ஒரு முறை துண்டித்து மீண்டும் இணைந்த பிறகு பிடிப்பை மீண்டும் செய்யவும், ஏனெனில் முதல் இணைப்பில் தோன்றி இரண்டாவதில் மறையும் அமைப்புகள் hook இல் உள்ள வாழ்க்கைச் சுழற்சிக் குறை, காணாமல் போன விருப்பம் அல்ல.

ஒரு உரிமையாளரை வைத்துக்கொண்டு வரிசையாகச் சரிபார்க்கவும்

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

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