VPN தொடங்கிய பிறகு Azure VM IMDS அல்லது WireServer-ஐ அடைய முடியவில்லை

VM இயங்குகிறது, VPN கிளையண்ட் இணைக்கப்பட்டுள்ளதாகக் கூறுகிறது, சில நிமிடங்களுக்குப் பிறகு Azure முகவர் ஆரோக்கியமற்ற நிலையைப் புகாரளிக்கத் தொடங்குகிறது. சில சமயங்களில் SSH தப்பிப்பிழைக்கிறது, போர்ட்டலின் Run Command இல்லை, இது மக்களை ரூட் அட்டவணைக்குப் பதிலாக முகவரைப் பார்க்க வைக்கிறது. சுரங்கப்பாதை ஏறியபோது விருந்தினரின் சொந்த ஃபார்வர்டிங் முடிவுகள் மாறின, பொதுவாக இரண்டு தள முகவரிகள் முதல் பலிகளாகும். முகவர் தோல்வியாகக் கருதுவதற்கு முன் இதை ரூட்டிங் அறிகுறியாகக் கருதுகிறேன்.

அறிகுறி உடைந்த முகவர் போலத் தெரிகிறது

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

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

168.63.129.16 பொது இலக்கு அல்ல

168.63.129.16 என்பது Azure இன் சிறப்பு மெய்நிகர் தள முகவரி, அதன் ஒரு பங்கு WireServer, VM முகவர் ஃபேப்ரிக்குடன் பேசப் பயன்படுத்துகிறது. TCP போர்ட் 80 மற்றும் 32526 க்கான முகவர் டிராஃபிக் கிடைக்கக்கூடியதாக இருக்க வேண்டும் என்று Microsoft ஆவணப்படுத்துகிறது. இது சாதாரண இணைய ஹோஸ்ட் அல்ல, முழு-சுரங்க VPN அதை தொலை வெளியேற்றத்திற்கு எடுத்துச் செல்லக்கூடாது. அதனால்தான் ஆரோக்கியமாகத் தெரியும் சுரங்கப்பாதையும் முகவரை பட்டினியாக வைக்க முடியும்.

தள முகவரி ஆவணம் இந்த முகவரி பயனர்-வரையறுத்த ரூட்டுகளுக்கு உட்பட்டது அல்ல என்றும் கூறுகிறது, இது Azure ஃபேப்ரிக்கின் பண்பு, உங்கள் விருந்தினர் பற்றிய உறுதிமொழி அல்ல. உள்ளூர் ஃபயர்வால் விதி அல்லது VPN கிளையண்டின் சொந்த ரூட்டிங் கொள்கை இன்னும் பாதையை உடைக்கலாம், அவை எதுவும் VNet இன் ரூட் அட்டவணையில் வாழ்வதில்லை.

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

169.254.169.254 க்கு அதன் சொந்த விதிகள் உள்ளன

169.254.169.254 என்பது Azure Instance Metadata Service இன் link-local முகவரி. அதற்கான கோரிக்கைகளுக்கு அவற்றின் சொந்த நிபந்தனைகள் உள்ளன: முதன்மை NIC மற்றும் முதன்மை IP, முகவரியை ஆதரிக்கும் DHCP உள்ளமைவு, மற்றும் எந்த HTTP ப்ராக்ஸியையும் தவிர்த்தல். அவற்றை தொலை VPN வெளியேற்றம் அல்லது தன்னிச்சையான இணைய நுழைவாயில் வழியாக அனுப்புவது Microsoft விவரிக்கும் அணுகல் மாதிரி அல்ல.

அந்த ப்ராக்ஸி விதி பாதையைச் சரிசெய்தும் இன்னும் தோல்விகளைக் காண்பவர்களைப் பிடிக்கிறது. விருந்தினர் HTTP ப்ராக்ஸி IMDS ஐ உடைக்கலாம், அதே நேரம் ip route get நீங்கள் எதிர்பார்க்கும் இடைமுகத்தைச் சரியாகத் திருப்பித் தருகிறது, எனவே பாதைகளுடன் ப்ராக்ஸி விலக்குகளையும் சரிபார்க்கவும்.

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

விருந்தினரின் கொள்கை ரூட்டிங்கைப் படியுங்கள், பிரதான அட்டவணையை மட்டும் அல்ல

Linux விருந்தினரில், மூன்று படிக்க-மட்டும் கட்டளைகள் அடுக்குகளைப் பிரிக்கின்றன: கொள்கை விதிகளுக்கு ip -4 rule show, பின்னர் கர்னல் உண்மையில் எடுக்கும் முடிவுகளுக்கு ip -4 route get 168.63.129.16 மற்றும் ip -4 route get 169.254.169.254. VPN இணைவதற்கு முன்பும் பின்பும் அவற்றை இயக்கவும். அந்த இரண்டு வெளியீடுகளுக்கு இடையிலான வேறுபாடே உங்கள் மாற்றத் தொகுப்பு, கிளையண்ட் என்ன செய்தது என்பது பற்றிய எந்த ஊகத்தையும் விட அது பயனுள்ளது.

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

பழைய நுழைவாயில் வழியாக இரண்டு /32 பாதைகளையும் சேர்க்கும் செய்முறையை எதிர்க்கவும். link-local தளப் பாதையும் பொது WAN அடுத்த ஹாப்பும் வெவ்வேறு பொருள்கள், மேலும் மொத்த விலக்கு உண்மையான கொள்கை மோதலை மறைக்கிறது.

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

உங்கள் SSH அல்லது RDP பதிலும் முழு-சுரங்க இயல்புநிலையால் பிடிக்கப்படலாம், ஆனால் அது தள முனைப்புள்ளியை அல்ல, நிர்வாகியின் கவனிக்கப்பட்ட முகவரியை இலக்காகக் கொள்கிறது. அதை அதன் சொந்த கோரிக்கை-பதில் இணையிலிருந்து கண்டறியவும், VPN கொள்கையை மாற்றுவதற்கு முன் தொடர் கன்சோல் போன்ற சுயாதீன மீட்பு சேனலை வைத்திருங்கள். ஒரு வரிசைப்படுத்தல் VM ஐ மறுதொடக்கம் செய்து முகவர் ஆரோக்கியமற்றதாகத் தெரிவித்தால், பாதை மாற்றமே மறுதொடக்கத்திற்குக் காரணம் எனக் கருதுவதற்குப் பதிலாக பதிவு செய்யப்பட்ட செயலையும் பொறுப்பான சேவையையும் ஆய்வு செய்யவும்.

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

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