VPN உள்ளே mDNS: .local பெயர்கள் ஏன் தீர்க்கப்படுவதில்லை
ரூட் செய்யப்பட்ட VPN யூனிகாஸ்ட் பாக்கெட்டுகளை எடுத்துச் செல்கிறது, இணைப்பு-உள்ளூர் மல்டிகாஸ்ட் அல்ல. எது தீர்க்கப்படுகிறது, வினவல் ஏன் ஒருபோதும் வரவில்லை மற்றும் எந்த பெயரிடல் வடிவமைப்பு உண்மையில் வேலை செய்கிறது என்பதைச் சரிபார்க்கவும்.
உங்கள் அலுவலக அச்சுப்பொறி உங்கள் மேசையில் உள்ள ஒவ்வொரு பயன்பாட்டிலும் தோன்றி VPN இல் மறைந்துவிடுகிறது, அதற்கு இருப்பதாக உங்களுக்குத் தெரிந்த முகவரிக்கு நீங்கள் பிங் செய்ய முடிந்தாலும். சுரங்கப்பாதையில் எதுவும் உடைந்துவிடவில்லை: கண்டுபிடிப்பும் அணுகலும் தனித்தனி சேவைகள், மேலும் இயல்பாக அவற்றில் ஒன்று மட்டுமே ரூட் செய்யப்பட்ட சுரங்கப்பாதையைக் கடக்கிறது. கீழே உள்ள சரிபார்ப்புகள் வழிகளைச் சேர்ப்பதற்கு முன்பே அவற்றைப் பிரிக்கின்றன. இணைப்பை ஒருபோதும் விட்டு வெளியேறாத வினவலை ஒரு வழியால் சரிசெய்ய முடியாது.
இன்று எது தீர்க்கப்படுகிறது, எது தீர்க்கப்பட்டதாக மட்டும் தோன்றுகிறது என்பதைச் சரிபார்க்கவும்
முதலில் இரண்டு கேள்விகளைப் பிரிக்கவும்: ஹோஸ்ட் பெயருக்கான unicast வினவல் தீர்வியைக் கேட்கிறது, அதே நேரத்தில் _ipp._tcp தேடல் உள்ளூர் இணைப்பைக் கேட்கிறது. Linux இல், avahi-browse -a மல்டிகாஸ்ட் DNS என்ன பார்க்க முடியும் என்பதைக் காட்டுகிறது, resolvectl query name.local தீர்வி அடுக்கு அந்தப் பெயரை என்ன செய்கிறது என்பதைக் காட்டுகிறது. macOS இல், dns-sd -B _ipp._tcp முதலில் முகவரி தேவையில்லாமல் கண்டறியப்பட்ட சேவைகளைப் பட்டியலிடுகிறது.
முகவரி பதிலளித்து பெயர் பதிலளிக்கவில்லை என்றால், ரூட்டிங் வேலை செய்கிறது, கண்டுபிடிப்பு வேலை செய்யவில்லை. .local பெயருக்கு avahi-browse நிறுவப்படாவிட்டாலும் nss-mdns மூலம் ஹோஸ்ட்டிலேயே பதிலளிக்க முடியும், எனவே அந்தப் பெயருக்கான வெற்றிகரமான getent அல்லது பிங் கண்டுபிடிப்பு சுரங்கப்பாதையைக் கடந்தது என்பதற்கான ஆதாரம் அல்ல; தேடல் முடிவும் தீர்வி முடிவும் வெவ்வேறு ஆதாரங்கள். பயன்பாடுகள் கண்டறிந்ததைத் தற்காலிகச் சேமிப்பில் வைக்கின்றன, அதனால்தான் தோல்வி இணைந்தவுடன் அல்லாமல் இணைந்த பல மணி நேரங்களுக்குப் பிறகு தோன்றுகிறது. பயன்பாட்டை மூடி மீண்டும் திறக்கவும், பின்னர் தற்காலிகச் சேமிப்பு உள்ளீட்டில் பெயர் உள்ளதா முகவரி உள்ளதா எனச் சரிபார்க்கவும், ஏனெனில் கண்டுபிடிப்பு நின்ற பிறகும் முகவரி நீண்ட நேரம் வேலை செய்கிறது.
வினவல் ஏன் ஒருபோதும் சுரங்கப்பாதையைக் கடக்கவில்லை
மல்டிகாஸ்ட் DNS வினவல்களை 224.0.0.251 க்கு, உள்ளூர் நெட்வொர்க் கட்டுப்பாட்டுத் தொகுதிக்குள், UDP போர்ட் 5353 இல் அனுப்புகிறது. ரவுட்டர்கள் அந்தத் தொகுதியின் முகவரிகளை அனுப்புவதில்லை, எனவே வினவல் அனுப்பப்பட்ட இணைப்பிலேயே இருக்கும். அனுப்புபவர்கள் IP TTL அல்லது IPv6 ஹாப் வரம்பை 255 ஆக அமைக்கிறார்கள், அதனால் பெறுபவர் ஏற்கனவே ரவுட்டரைக் கடந்த பாக்கெட்டை நிராகரிக்க முடியும்; நெறிமுறை இணைப்புக்கு வெளியேயான மோசடியை இப்படித்தான் கண்டறிகிறது, இப்படி உள்ளூராக இருப்பதில்லை. உள்ளூர்தன்மை இலக்கு முகவரியிலிருந்து வருகிறது, ஒரு-ஹாப் TTL இலிருந்து அல்ல.
சுரங்கப்பாதையின் வகையும் முக்கியம். tun பாணி இடைமுகம் IP பாக்கெட்டுகளை மட்டுமே எடுத்துச் செல்கிறது, வேறு எதையும் அல்ல, எனவே எந்த மல்டிகாஸ்ட் குழுவும் அதைக் கடந்து தப்பிப்பதில்லை. tap பாணி பாலம் ஒலிபரப்பு களத்தையே விரிவாக்குகிறது, அதனால்தான் சில பழைய வடிவமைப்புகள் ரூட்டிங்கிற்குப் பதிலாகப் பாலம் அமைத்தன, மேலும் பாலம் கொண்டு வரும் ஒவ்வொரு சிக்கலையும் வாரிசாகப் பெற்றன.
நம்பகமான LAN க்கான விதிவிலக்கு இதில் எதையும் மாற்றாது, ஏனெனில் அது சுரங்கப்பாதைக்கு மல்டிகாஸ்ட் அனுப்பக் கற்பிப்பதற்குப் பதிலாக எந்த இயக்கத்திற்கு சுரங்கப்பாதையைப் பயன்படுத்தலாம் என்பதைத் தீர்மானிக்கிறது. பாக்கெட்டுக்கு இன்னும் கேட்க ஒரு பகிரப்பட்ட பிரிவு இல்லை.
நீங்கள் தாங்கக்கூடிய பெயரிடல் வடிவமைப்பைத் தேர்ந்தெடுக்கவும்
நிறுவன வளங்களுக்கு நீடித்த பதில் VPN தள்ளும் தீர்வி வழங்கும் ரூட் செய்யப்பட்ட ஹோஸ்ட் பெயர், அதனுடன் பிரிக்கப்பட்ட DNS, உள் பெயர்கள் உள் சேவையகங்களுக்குச் செல்லவும் மற்றவை செல்லாமல் இருக்கவும். Windows இதைப் பெயர் தீர்வுக் கொள்கை அட்டவணையாக வெளிப்படுத்துகிறது, macOS இடைமுகத்திற்கு ஒரு வரம்புக்குட்பட்ட தீர்வியைப் பயன்படுத்துகிறது, பெரும்பாலான வாடிக்கையாளர்களுக்கு சமமான தள்ளல் அமைப்பு உள்ளது. சாதனம் அக DNS இல் அதன் வழக்கமான பெயரை வைத்திருக்கிறது, கண்டுபிடிப்பு பாதையின் ஒரு பகுதியாக இருப்பதை நிறுத்துகிறது.
கண்டுபிடிப்பு ப்ராக்ஸி அல்லது mDNS பிரதிபலிப்பான் இந்த இடைவெளியைப் பாலமிட முடியும், அது அதன் சொந்த ஹோஸ்ட், அதன் சொந்த வெளிப்பாடு மற்றும் அதன் சொந்த வாடிக்கையாளர் தேவைகளைக் கொண்ட உண்மையான வடிவமைப்பு. நீங்கள் ஒரு வழியைச் சேர்த்ததால் அது தோன்றுவதில்லை. .local வினவல்களை ஒருபோதும் பொது தீர்விக்கு அனுப்ப வேண்டாம்: களம் RFC 6762 மூலம் உள்ளூர் மல்டிகாஸ்ட் பயன்பாட்டிற்கு ஒதுக்கப்பட்டுள்ளது, அதை வெளியே அனுப்புவது மெதுவான தோல்விகளையும் தேவையற்ற தரவு வெளிப்பாட்டையும் உருவாக்குகிறது.
பெயரை அல்ல, சேவையைச் சரிபார்க்கவும்
தேடல் பட்டியலில் உள்ள பெயர் கண்டுபிடிப்பு படியை நிரூபிக்கிறது, சேவை பதிலளிக்கிறது என்பதை அல்ல. அச்சு வரிசை அல்லது வலை இடைமுகத்தைத் திறந்து உண்மையான செயல்பாட்டை முடிக்கவும், பின்னர் மீண்டும் இணைந்த பிறகு அதை மீண்டும் செய்யவும்.
கண்டுபிடிப்பு பெயர்களை ஆக்ரோஷமாகத் தற்காலிகச் சேமிப்பில் வைக்கிறது, எனவே பழைய உள்ளீடு வெற்றியாகத் தோன்றலாம். சான்றிதழ் அல்லது அங்கீகார கேட்பு தோன்றினால், அது அடுத்த அடுக்கு மற்றும் தனிச் சிக்கல். நீங்கள் எந்த பொறிமுறையை மாற்றினீர்கள், தீர்வியா கண்டுபிடிப்பா என்று எழுதி வைக்கவும், அடுத்த நபர் முழு கேள்வியையும் மீண்டும் திறக்க வேண்டியதில்லை.