Mac அடைய முடியாத DNS முகவரியை StrongSwan அனுப்புகிறது

யாராவது ஒரு MacBook திறக்கும் வரை எல்லாம் வேலை செய்கிறது. சுரங்கப்பாதை நிறுவப்படுகிறது, உள் ஹோஸ்ட்கள் முகவரியால் பதிலளிக்கின்றன, பெயர் தீர்வு இறந்துவிடுகிறது. iPhoneஇல் அதே சுயவிவரம் அதேபோலவே நடந்துகொள்கிறது, ஆனால் Windows மற்றும் Linux வாடிக்கையாளர்கள் நன்றாகவே உள்ளனர். அனுப்பப்படும் DNS பண்பேற்பாடே பொதுவாகக் குற்றவாளி: சேவையகம் தன் சொந்த பொது இடைமுக முகவரியை வழங்குகிறது, Appleஇன் IKEv2 வாடிக்கையாளர் அங்கு வினவல்களைச் சுரங்கப்பாதை வழியாக அனுப்புவதில்லை. தீர்வியைக் குளத்திற்குள் நகர்த்துங்கள், வாடிக்கையாளரைத் தொடாமலே அறிகுறி மறைந்துவிடும்.

அறிகுறி அனுப்பப்படும் முகவரியையே சுட்டுகிறது

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

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

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

தீர்வியைக் குத்தகை வரம்பிலிருந்து வெட்டியெடுங்கள்

தீர்வி குளத்தின் சொந்த துணைக்கோளத்தின் உறுப்பினராக இருக்கும் ஒரு முகவரித் திட்டத்தைச் சுரங்கப்பாதைக்குக் கொடுங்கள், பிறகு அந்த முகவரியை ஒதுக்கி வையுங்கள், எந்த வாடிக்கையாளருக்கும் அது ஒருபோதும் குத்தகைக்கு வரக்கூடாது. இந்த எடுத்துக்காட்டில் குளம் 10.180.7.0/24, சேவையகம் 10.180.7.1ஐ வைத்திருக்கிறது, குத்தகைகள் 10.180.7.2இல் தொடங்குகின்றன.

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

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

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

தீர்வியைப் பிணைத்து போர்ட் 53ஐ மூடுங்கள்

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

interface: 10.180.7.1
access-control: 10.180.7.0/24 allow
access-control: 0.0.0.0/0 refuse

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

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

iptables -A INPUT -p udp --dport 53 -s 10.180.7.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 53 -s 10.180.7.0/24 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j DROP
iptables -A INPUT -p tcp --dport 53 -j DROP

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

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

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

swanctl --list-sas
swanctl --list-pools
dig +short @10.180.7.1 intranet.plant.example

நேரடி வினவல், தீர்வி குள முகவரியில் அதை அடையக்கூடிய ஹோஸ்டிலிருந்து பதிலளிக்கிறது என்பதை நிரூபிக்கிறது. Mac அந்தச் சேவையகத்தைத் தேர்ந்தெடுத்தது என்பதை அது நிரூபிக்காது. macOSஇல், scutil --dns வரம்பிட்ட சேவைக்கு ஒரு தீர்வியைப் பட்டியலிடுகிறது, சுருக்கப் பலகையை விட அதிகத் தகவல் தருகிறது; Windowsஇல், Get-DnsClientServerAddress சுரங்கப்பாதை அடாப்டர் அனுப்பிய மதிப்பை ஏற்றுக்கொண்டதா என்பதைக் காட்டுகிறது.

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