நுழைவாயிலில் OpenVPN DNS: dnsmasq மற்றும் ஃபயர்வால் எல்லை

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

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

கேட்பவர் இரு திசைகள் கொண்ட உள்ளூர் சேவை

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

வாடிக்கையாளர் தெரிவிக்கும் நேரமுடிவும் நுழைவாயிலில் தெரியும் நேரமுடிவும் ஒரே கோளாறு அல்ல.

சுரங்க முகவரியைப் பிணைக்கவும், ஒவ்வொரு முகவரியையும் அல்ல

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

listen-address=127.0.0.1,10.90.0.1
bind-dynamic
no-resolv
no-hosts
server=192.168.50.53

bind-dynamic தனி முகவரிகளைப் பிணைத்து tun0 பின்னர் தோன்றும்போது கையாளுகிறது, VPN சேவை மீண்டும் தொடங்கும் ஹோஸ்ட்டில் இது முக்கியம். loopback பட்டியலிடுவது பொது கேட்பவரைச் சேர்க்காமல் உள்ளூர் கருவிகளை இயக்க வைக்கிறது. no-resolv டீமன் ஹோஸ்ட்டின் தீர்வி உள்ளமைவிலிருந்து மேல்நிலைகளை மரபுரிமையாகப் பெறுவதைத் தடுக்கிறது, no-hosts இந்த நிகழ்வு நுழைவாயிலின் hosts கோப்பை வெளியிடுவதைத் தடுக்கிறது. இந்த விருப்பங்களில் எதுவும் யாருக்கும் சேவையை வினவ அனுமதி தரவில்லை.

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

DNS உள்ளீட்டை அனுமதிக்கவும், சுரங்க ஓட்டத்தை அல்ல

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

sudo ufw allow in on tun0 proto udp from 10.90.0.0/24 to 10.90.0.1 port 53
sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 53

DNS UDP உடன் TCP வழியாகவும் இயங்குகிறது, எனவே UDP மட்டும் விதி பெரிய பதில்களை இடையிடையே எனத் தோன்றும் வகையில் தோல்வியடைய விடுகிறது. இவை ufw route அனுமதிகள் அல்ல, அவை tun0 மீது பரந்த அனுமதியாகக் கூடாது. வரிசை உள்ளடக்கத்திற்கு நிகரான முக்கியத்துவம்: tun0 இலிருந்து அனைத்து உள்ளீட்டையும் வீசும் முந்தைய விதி இன்னும் வெல்கிறது, இறுதி வீழ்ச்சிக்குக் கீழே அனுமதி சேர்ப்பது எதையும் உருவாக்காது.

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

மேல்நிலைப் பாதி தனி வழி

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

பதில்களை வேலை செய்ய வைக்க வரம்பற்ற சுரங்க வெளியீட்டைச் சேர்க்க வேண்டாம்; கண்காணிக்கப்படும் பதில்களுக்கு அது தேவையில்லை.

விருப்பத்தைப் புஷ் செய்து, பிறகு ஒப்படைப்பைச் சரிபார்க்கவும்

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

push "dhcp-option DNS 10.90.0.1"

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

வாடிக்கையாளரின் தீர்வி உள்ளமைவுக்கு ஒரே உரிமையாளர் இருப்பதே இலக்கு, புஷ் பொதுவாக அந்த உரிமையாளராக இருப்பது வாடிக்கையாளர் தளம் ஒப்புக்கொள்ளும்போது மட்டுமே.

நீங்கள் உண்மையில் கட்டியதைச் சோதிக்கவும்

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

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

  • வாடிக்கையாளர் புஷ் செய்யப்பட்ட விருப்பத்தை ஒருபோதும் பயன்படுத்தவில்லை.
  • பின்னர் மற்றொரு தீர்வி அமைக்கப்பட்டு போட்டியில் வென்றது.
  • பயன்பாடு அதன் சொந்த தீர்வி நூலகத்தையோ தேக்ககப்படுத்தப்பட்ட பதிலையோ பயன்படுத்துகிறது.

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

தொடர்புடைய கட்டுரைகள்