Azure S2S VPN இணைக்கப்பட்டுள்ளது ஆனால் டிராஃபிக் இல்லை: IKE பதிவைப் படியுங்கள்

போர்ட்டல் Connected என்று கூறுகிறது, சுரங்கப்பாதைக்கு இயக்க நேர கணக்கு உள்ளது, மேலும் உங்கள் மெய்நிகர் இயந்திரத்திலிருந்து எடுக்கப்பட்ட trace இரண்டாவது ஹாப்பில் இறந்துவிடுகிறது. இணைப்பின் நிலை IKE மற்றும் IPsec பேச்சுவார்த்தையை விவரிக்கிறது, இரு பக்கங்களிலும் ஒரு பாக்கெட் கொள்கை அடுக்கைக் கடக்கிறதா என்பதை அல்ல. இந்த டிக்கெட்டுகளில் பெரும்பாலானவற்றுக்குக் காரணம் இரண்டு பிழைகள், அவற்றில் ஒன்றும் Azure வழியை மாற்றுவதால் சரிசெய்யப்படுவதில்லை. இரண்டும் ஏற்கனவே கேட்வே உருவாக்கிய பதிவில் எழுதப்பட்டுள்ளன, அதனால் நான் வழி அட்டவணையிலிருந்து அல்ல, அங்கிருந்து தொடங்குகிறேன்.

Connected உண்மையில் எதை உறுதிப்படுத்துகிறது

இணைக்கப்பட்ட site-to-site இணைப்பு என்பது கட்டம் 1 மற்றும் கட்டம் 2 முடிந்துவிட்டன மற்றும் பாதுகாப்பு சங்கங்கள் செயலில் உள்ளன என்பதாகும். இது பேச்சுவார்த்தை பற்றிய ஒரு கூற்று: இரு தரப்பும் ஒரு முன்மொழிவில் ஒப்புக்கொண்டு, விசைகளை பரிமாறிக்கொண்டு SA ஜோடியை நிறுவின. நீங்கள் பாதுகாக்கப்பட்டதாகக் கருதும் துணை வலைகளுடன் டிராஃபிக் தேர்விகள் பொருந்துகின்றனவா, அல்லது மறைகுறியாக்கிய பிறகு எதிர்ப்பக்கம் பாக்கெட்டை எங்காவது வழிமாற்றுமா என்பது பற்றி இது எதுவும் கூறவில்லை. சுரங்கப்பாதை வாரங்களாக இயங்கிக்கொண்டே இருக்கலாம், ஆனால் ஒவ்வொரு சுவாரஸ்யமான ஓட்டமும் தூக்கி எறியப்படும், மேலும் ஆரோக்கியமான கேட்வேயை மீண்டும் கட்டமைக்க மக்களைத் தூண்டுவது இதே முறையே.

முதலில் சரிபார்க்க வேண்டிய இரண்டு பிழைகள் ESP-க்கு பதிலாக AH முன்மொழியும் peer, மற்றும் கேட்வே உள்நாட்டு எனக் கருதாத இடத்தில் எண்ணிடப்பட்ட மெய்நிகர் வலை.

வழிகளைத் தொடுவதற்கு முன் ஏற்றுமதி செய்யப்பட்ட பதிவைத் திறக்கவும்

போர்ட்டலில் மெய்நிகர் வலை கேட்வேயைத் திறந்து இணைப்பில் VPN troubleshoot செயல்பாட்டை இயக்கவும், பின்னர் அது உருவாக்கும் தொகுப்பைப் பதிவிறக்கி திறக்கவும். உள்ளே கட்டம் 1 மற்றும் கட்டம் 2 பரிமாற்றங்களுடன் IKE பதிவு உள்ளது, நேர முத்திரைகளுடன் மற்றும் சாதாரண உரையாகப் படிக்கக்கூடியது. மேலிருந்து கீழாகப் படிக்காமல் அதில் transform வரியைத் தேடுங்கள், ஏனெனில் சுவாரஸ்யமான பதிவு பொதுவாக சில நூறு வரிகளுக்குள் இருக்கும். போர்ட்டல் அணுகல் இல்லாவிட்டால், கண்டறிதல் அமைப்புகள் இயக்கப்பட்டிருக்கும்போது அதே கண்டறிதல்கள் கேட்வேயின் பதிவு இலக்கில் தோன்றும்.

இரண்டு பதிவுகள் பெரும்பாலான மதிப்பைக் கொண்டுள்ளன. முதலாவது தோராயமாக இப்படிப் படிக்கப்படுகிறது: expected ESP with combined authentication and cipher, received AH. இரண்டாவது IKE பரிமாற்றத்தின் போது invalid payload பிழை, இது பொதுவாக தவறாக வடிவமைக்கப்பட்ட அல்லது ஆதரிக்கப்படாத முன்மொழிவு புலத்தைக் குறிக்கிறது.

இரண்டும் ஆன்-பிரிமைஸ் சாதனம் என்ன முன்மொழிந்தது என்பதை விவரிக்கின்றன, எனவே இரண்டும் peer பக்க அமைப்புகள். இணைப்பின் Azure பக்கத்தை மீண்டும் உருவாக்குவது உங்கள் ஃபயர்வால் அனுப்பும் முன்மொழிவை மாற்றாது, அப்படிச் செய்வதே இந்த வேலையில் அதிகம் வீணாகும் மணிநேரம். peer-இல் கட்டம் 2-ஐ இணைந்த அங்கீகாரம் மற்றும் சைஃபருடன் ESP-க்கு அமைத்து அல்காரிதத்தைப் பேச்சுவார்த்தை செய்ய விடுங்கள், பின்னர் combined mode போன்ற பெயரில் உள்ள விற்பனையாளர் தேர்வுப்பெட்டி அடியில் அமைதியாக AH முன்மொழிவைத் தேர்ந்தெடுக்கிறதா எனப் பாருங்கள்.

மெய்நிகர் வலையின் முகவரி இடைவெளியை உறுதிப்படுத்தவும்

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

முகவரி இடைவெளி பகுதியில் இருக்கும்போதே ஆன்-பிரிமைஸ் வரம்புகளுடன் உள்ள மேலோட்டத்தைப் பதிவு செய்யுங்கள், ஏனெனில் மேலோட்டமான முன்னொட்டுகள் வாடிக்கையாளரிடமிருந்து ஒரே மாதிரியாகத் தெரியும் வேறு வகையான தோல்வியை உருவாக்குகின்றன.

இரு திசைகளிலும் முன்னொட்டுகளைச் சரிபார்க்கவும்

உள்ளூர் வலை கேட்வே வளம் ஆன்-பிரிமைஸ் முன்னொட்டுகளை வைத்திருக்கிறது, அவை தொலை சாதனம் உண்மையில் பாதுகாக்கும் துணை வலைகளுடன் பொருந்த வேண்டும். சாதனம் தூக்கி எறியும் முகவரிகளை உள்ளடக்கிய சுருக்கம் சில ஓட்டங்களைக் கடக்கவிட்டு மற்றவற்றில் தோல்வியடையும், இது உள்ளமைவு பொருந்தாமையை விட இடைவிடாத வழிமாற்று பிழையாகப் படிக்கப்படுகிறது. தொலைப் பக்கத்தையும் பாருங்கள்: ஒரு முனை /16 பட்டியலிடும்போது மற்றொன்று அதற்குள் மூன்று /24 பட்டியலிடுவது — இதுவே செந்நெறி பகுதி தோல்வி. எந்தப் பட்டியலும் தனியாக அதிகாரமுடையது அல்ல, எனவே நீங்கள் பார்க்கக்கூடியதை நம்புவதற்குப் பதிலாக இரண்டையும் அருகருகே ஒப்பிடுங்கள்.

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

ping அல்ல, பாதையைச் சோதியுங்கள்

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

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

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