Azure P2S VPN இன் திரும்பு டிராஃபிக் ஒரு திசையில் மட்டுமே செயல்படுகிறது

டனல் ஐகான் பச்சையாக உள்ளது, NSG அனுமதிப்பதாகத் தெரிகிறது, பயனுள்ள வழிகள் சரியாகத் தெரிகின்றன, இருந்தாலும் VM இணைக்கப்பட்ட வாடிக்கையாளருக்கு திரும்பி இணைப்பைத் திறக்க முடியவில்லை. வழக்கமான அனுமானம் என்னவென்றால், செயல்படும் point-to-site டனல் சமச்சீராக இருக்கும்: வாடிக்கையாளர் VM ஐ அடைந்தால், VM வாடிக்கையாளரை அடையும். அந்த அனுமானமே பகுத்தறிவில் உள்ள பிழை, உள்ளமைவில் அல்ல. ஒரு டனல் கோரப்படாத ஓட்டத்தின் ஒரு திசையைக் கடத்தி மற்றதை விட்டுவிடலாம், மற்றும் திருத்தம் எந்த அடுக்கு அதை விடுகிறது என்பதைப் பொறுத்தது.

கட்டுக்கதை: இணைக்கப்பட்ட டனல் இரு திசை டனல்

VPN டனல் ஒரு கொள்கை பாதை, கம்பி அல்ல. ஒவ்வொரு திசையும் தேர்விகள், வழிகள் மற்றும் வடிகட்டிகளுடன் பொருத்தப்படுகிறது, அவற்றில் எதுவும் ஒரு திசையை அனுமதித்து மற்றதைத் தடுக்கலாம்.

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

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

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

அடுத்த படி ஆதாரம், கூடுதல் விதிகள் அல்ல. VM துணைக்கட்டத்தில் NSG ஐ இரு திசைகளிலும் சரிபார்க்கவும், VM இன் NIC இல் பயனுள்ள வழிகளைப் படிக்கவும், வாடிக்கையாளர் டிராஃபிக்கை அனுப்பும்போது VM இல் பாக்கெட்டுகளைப் பிடிக்கவும். பதிலில்லாமல் வரும் கோரிக்கை வடிகட்டி அல்லது திரும்பு வழி சிக்கல்; ஒருபோதும் வராத கோரிக்கை பாதை சிக்கல். தோல்வியடைந்த ping ஐ VM அணுக முடியாததற்கான ஆதாரமாகக் கருத வேண்டாம், ஏனெனில் TCP செயல்படும்போது ICMP கொள்கை பதிலை விட்டுவிடலாம்.

IKEv2 point-to-site திரும்பு பாதையே வழக்கமான சந்தேக நபர்

இந்தக் கட்டுரைக்குப் பின்னால் உள்ள Azure அறிக்கையில், ஒரு வாடிக்கையாளர் IKEv2 வழியாக VM களை அடைய முடிந்தது, ஆனால் VM இலிருந்து வாடிக்கையாளருக்கு வரும் ICMP, கேட்வேயின் டனல் வகை OpenVPN ஆக மாற்றப்படும் வரை தோல்வியடைந்தது. அறிக்கையாளர் கூறுகிறார், IKEv2 point-to-site பாதையில் Microsoft ஒரு வரம்பை உறுதிப்படுத்தியது: வாடிக்கையாளர் அமர்வைத் தொடங்காத வரை VM இலிருந்து வாடிக்கையாளருக்கான திரும்பு டிராஃபிக் சமச்சீராக வழியமைக்கப்படுவதில்லை. IKEv2 டிராஃபிக் தேர்விகளைச் சார்ந்துள்ளது, அந்த நிலையில் கேட்வே திரும்பு திசையை மதிக்கவில்லை.

அது OpenVPN ஐ பொதுவாக சிறந்த டனல் வகையாக மாற்றாது. அது இந்த பணிச்சுமைக்கான சோதனை அணிவரிசையில் டனல் வகையை ஒரு மாறியாக மாற்றுகிறது.

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

கட்டுக்கதை: பிராட்காஸ்ட் கண்டுபிடிப்பு VNet எல்லையைக் கடக்கிறது

இரண்டாவது அனுமானம் தொடர்பில்லாத காரணத்தால் தோல்வியடைகிறது. Azure மெய்நிகர் நெட்வொர்க் பிராட்காஸ்ட் டிராஃபிக்கைக் கடத்துவதில்லை, எனவே VM ஆன்-பிரிமைஸ் நெட்வொர்க்கிலிருந்து site-to-site அல்லது point-to-site இணைப்பு வழியாக பிராட்காஸ்ட் பிரேம்களைப் பெற முடியாது. பிராட்காஸ்ட் மூலம் சகாக்களைக் கண்டறியும் பயன்பாடுகள், எடுத்துக்காட்டாக பழைய கோப்பு உலாவல் அல்லது சில சாதன-கண்டுபிடிப்பு நெறிமுறைகள், வழிகள் எவ்வாறு எழுதப்பட்டாலும் தொலைப் பக்கத்தை ஒருபோதும் பார்க்காது.

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

எதை மாற்ற வேண்டும், அதை எப்படி நிரூபிப்பது

திசை சோதனை IKEv2 இல் மட்டும் தோல்வியடைந்தால், கேட்வேயின் டனல் வகை, வாடிக்கையாளர் முகவரி குளம் மற்றும் சரியான ICMP அல்லது TCP சோதனையைப் பதிவு செய்து, பாதிக்கப்பட்ட வாடிக்கையாளர்களுக்கு அங்கீகரிக்கப்பட்ட OpenVPN சுயவிவரத்தை மதிப்பிடவும். ஒவ்வொரு டனல் வகையிலும் தோல்வியடைந்தால், திரும்பு பாதையில் வேலை செய்யவும்: வாடிக்கையாளர் முகவரி VM துணைக்கட்டத்திலிருந்து வழியமைக்கக்கூடியதாக இருக்க வேண்டும், பயனர் வரையறுத்த எந்த வழியும் செல்லுபடியாகும் அடுத்த ஹாப்பை நோக்கி இருக்க வேண்டும், வாடிக்கையாளர் ஃபயர்வால் உள்வரும் ஓட்டத்தை ஏற்க வேண்டும். NSG மற்றும் வழி ஆதாரங்களை டிக்கெட்டுடன் இணைக்கவும்.

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