ஸ்டேட்லெஸ் VPN எட்ஜ் ஃபயர்வாலில் DNS பதில் ஏன் தோல்வியடைகிறது

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

இரு பரிமாற்றங்களும் ஒரே பரிமாற்றம் அல்ல

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

query:  203.0.113.10:53018 -> 198.51.100.53:53
reply:  198.51.100.53:53 -> 203.0.113.10:53018

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

நிலையற்ற எட்ஜ் மற்றும் நிலையுள்ள ஹோஸ்ட் ஃபயர்வால்

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

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

அனுமதியைப் போர்ட் எண்ணைச் சுற்றி அல்ல, நெறிமுறையைச் சுற்றி கட்டுங்கள்

விதியை உண்மையான தீர்வியல் முகவரிகள், இலக்கு ஹோஸ்ட் மற்றும் தயாரிப்பு ஆதரிக்கும் பெறும் போர்ட் கொள்கைக்கு மட்டுப்படுத்துங்கள். DNS-இன் TCP பாதையையும் நினைவில் கொள்ளுங்கள், ஏனெனில் பெரிய பதில் அல்லது வெட்டப்பட்டதால் பின்வாங்குதல் பரிமாற்றத்தை TCP-க்கு நகர்த்துகிறது, UDP மட்டும் கொண்ட விதி அதை மூடாது. எட்ஜ் வரையறுக்கப்பட்ட ஓட்டத்திற்கு நிலையுள்ள ஆய்வை ஆதரித்தால், கையால் எழுதப்பட்ட பதில் விதியை விட அதற்கு முன்னுரிமை கொடுங்கள், ஏனெனில் நிலையுள்ள பாதை வாடிக்கையாளர் தேர்ந்தெடுத்த போர்ட்டுகளை தானாகவே பின்பற்றுகிறது.

பின்னர் பாதையில் எந்தத் தயாரிப்பு போக்குவரத்தை உண்மையில் வடிகட்டுகிறது என்பதை உறுதிப்படுத்துங்கள். ஆவணப்படுத்தப்பட்ட IPv4 எட்ஜ் எல்லை IPv6 கொள்கையை நிறுவாது, வழங்குநரின் உள் போக்குவரத்து அதே வடிகட்டியை ஒருபோதும் கடக்காமல் இருக்கலாம்.

எந்த மூலப் போர்ட் 53-ஐயும் அனுமதிப்பது ஏன் தீர்வு அல்ல

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

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

சரியான எல்லையில், சரியான திசையில் சரிபார்க்கவும்

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

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