WireGuard DNS-ஐ தள்ளாது: ஒரு தனியார் BIND மண்டலத்தை வழங்குதல்

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

சுரங்கப்பாதையும் தீர்வியும் தனித்தனி ஒப்பந்தங்கள்

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

எனவே வேலை செய்யும் சுரங்கப்பாதை பெயர் தீர்வைப் பற்றி எதுவும் சொல்லாது. வாடிக்கையாளருக்கு 10.90.0.1-க்கு சிறந்த பாதை இருந்தும் அதன் வினவல்களை பொது தீர்விக்கு அனுப்பலாம், அதனால்தான் அறிகுறி “VPN DNS-ஐ உடைத்தது” போலத் தெரிகிறது, ஆனால் DNS ஒருபோதும் VPN-ஐ நோக்கி இருக்கவில்லை.

மீள்சுழற்சி தீர்வியாகாமல் மண்டலத்தை வழங்குங்கள்

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

இரண்டாவது தொகுதியை உருவாக்குவதற்குப் பதிலாக இந்த அமைப்புகளை ஏற்கனவே உள்ள options தொகுதியில் இணைக்கவும்:

options {
    listen-on { 127.0.0.1; 10.90.0.1; };
    listen-on-v6 { none; };
    allow-query { 127.0.0.1; 10.90.0.0/24; };
    allow-transfer { none; };
    recursion no;
};

பிறகு மண்டலத்தையும் அதன் கோப்பையும் அறிவிக்கவும்:

zone "corp.example" {
    type primary;
    file "/etc/bind/db.corp.example";
};

$TTL 300
@ IN SOA ns.corp.example. hostmaster.corp.example. ( 1 3600 600 604800 300 )
@      IN NS ns.corp.example.
ns     IN A  10.90.0.1
portal IN A  10.60.0.20

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

named-checkconf
named-checkzone corp.example /etc/bind/db.corp.example

UDP மற்றும் TCP 53-ஐ VPN இடைமுகத்தில் மட்டும் திறக்கவும். பொது இடைமுகத்தில் தனியார் அதிகாரத்தை வெளியிடுவது வினவல்களையும் கணக்கெடுப்பையும் அழைக்கிறது, மேலும் ஒரு இரண்டாம் நிலை உண்மையில் தேவைப்படாத வரை allow-transfer மூடியே இருக்க வேண்டும்.

வாடிக்கையாளரை அதை நோக்கி திருப்புங்கள், ஒவ்வொரு இணைப்புக்கும்

இணைப்பை NetworkManager வைத்திருப்பதாகவும் தீர்வி systemd-resolved என்றும் கருதுங்கள். முதலில் ஏற்கனவே உள்ள கொள்கையைப் படியுங்கள், குறிப்பாக ஏதேனும் மூல வழிசெலுத்தல் களம், ஏனெனில் ~. பதிவு நீங்கள் சேர்க்கப் போவதை மிஞ்சும்.

nmcli connection modify wg-office +ipv4.dns 10.90.0.1
nmcli connection modify wg-office +ipv4.dns-search '~corp.example'

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

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

பெயருக்கு முன் பாதையைச் சரிபார்க்கவும்

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

resolvectl query portal.corp.example

அது 10.60.0.20-ஐத் திருப்பினால், DNS ஒப்பந்தம் நிறைவேறியது. நேரம் முடிந்தால், முதலில் 10.90.0.1-க்கான பாதை, பிறகு ஃபயர்வால் விதி, பிறகு சேவையகத்தில் allow-query சரிபார்க்கவும். இந்த அமைப்பில் பெயர் தீர்வுத் தோல்விகள் கிட்டத்தட்ட எப்போதும் அணுகல் அல்லது ACL, மண்டலக் கோப்பு அல்ல. வாடிக்கையாளரிலிருந்து வெளிநோக்கி வேலை செய்யுங்கள், ஏனெனில் ஒரு வினவல் ஏன் ஒருபோதும் வரவில்லை என்று சேவையகத்தால் சொல்ல முடியாது.

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

இன்னும் தானியங்காதவை

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

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

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