Azure-ի VM-ը VPN-ի մեկնարկից հետո չի հասնում IMDS կամ WireServer

Մեքենան աշխատում է, VPN հաճախորդը հայտնում է կապի մասին, և մի քանի րոպե անց Azure-ի գործակալը սկսում է անառողջ վիճակ հաղորդել։ Երբեմն SSH-ը պահպանվում է, իսկ պորտալի Run Command-ը՝ ոչ, ինչը մարդկանց ուղղում է գործակալի, այլ ոչ երթուղիների աղյուսակի մոտ։ Հյուրի սեփական փոխանցման որոշումները փոխվեցին, երբ թունելը բարձրացավ, և սովորաբար երկու պլատֆորմային հասցեներն են առաջին զոհերը։ Ես դա դիտարկում եմ որպես երթուղային ախտանիշ, նախքան գործակալի խափանում համարելը։

Ախտանիշը նման է կոտրված գործակալի

Ստորև նշված երկու հասցեներն էլ առաջարկվում են որպես լուծում, սակայն դրանք նույն ծառայությունը չեն։ Մեկի համար /32 պատճենելը, որովհետև այն աշխատել էր մյուսի համար, հենց այն ձևն է, թե ինչպես ժամանակավոր շրջանցումը դառնում է մշտական կարգավորում, որը ոչ ոք չի համարձակվում հեռացնել։

Աշխատող հերթականությունն այս է՝ նախ հաստատել, թե ձախողված կանչն իրականում որ հասցեին է ուղղված, ապա կարդալ, թե ինչպես է հյուրը լուծում այն։ Մնացած ամեն ինչ լրացուցիչ քայլերով գուշակություն է և ավելի երկար փոփոխության պատուհան։

168.63.129.16-ը հանրային նպատակակետ չէ

168.63.129.16-ը Azure-ի հատուկ վիրտուալ պլատֆորմային հասցեն է, և նրա դերերից մեկը WireServer-ն է, որն օգտագործում է VM գործակալը՝ ֆաբրիկայի հետ խոսելու համար։ Microsoft-ը փաստում է, որ գործակալի թրաֆիկը TCP 80 և 32526 պորտերին պետք է հասանելի մնա։ Սա սովորական ինտերնետ հոսթ չէ, և այն չպետք է ամբողջական թունելով VPN-ը տեղափոխի հեռավոր ելք։ Դրա համար էլ առողջ տեսք ունեցող թունելը դեռ կարող է սոված թողնել գործակալին։

Պլատֆորմային հասցեի փաստաթղթերը նույնպես նշում են, որ այս հասցեն ենթակա չէ օգտվողի սահմանած երթուղիներին, ինչը Azure ֆաբրիկայի հատկություն է, ոչ թե խոստում ձեր հյուրի մասին։ Տեղական firewall կանոնը կամ 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-ները հյուրի երթուղիների աղյուսակը չեն, և դրանց խմբագրումը չի շտկի տեղական քաղաքականության կանոնը։