Azure VM VPN başladıqdan sonra IMDS və ya WireServer-ə çatmır

VM işləyir, VPN müştərisi bağlantının olduğunu bildirir, bir neçə dəqiqə sonra isə Azure agenti nasazlıq barədə məlumat verməyə başlayır. Bəzən SSH işləyir, portaldan Run Command isə işləmir; bu, insanları marşrut cədvəlinə deyil, agentə baxmağa yönəldir. Tunel qalxdıqda qonağın öz yönləndirmə qərarları dəyişdi və adətən ilk itki iki platforma ünvanı olur. Mən bunu agent nasazlığı kimi deyil, əvvəlcə marşrutlaşdırma simptomu kimi qiymətləndirirəm.

Simptom xarab agent kimi görünür

Aşağıdakı hər iki ünvan həll yolu kimi təklif olunur, halbuki onlar eyni xidmət deyil. Birinə /32 kopyalamaq, çünki digəri üçün işləmişdi, müvəqqəti çıxış yolunun heç kimin silməyə cürət etmədiyi daimi konfiqurasiyaya çevrilməsi deməkdir.

İşləyən ardıcıllıq belədir: əvvəlcə uğursuz çağırışın həqiqətən hansı ünvana getdiyini təsdiqləyin, sonra qonağın onu necə həll etdiyini oxuyun. Bunun xaricində hər şey əlavə addımlarla edilən təxmin və daha uzun dəyişiklik pəncərəsidir.

168.63.129.16 publik təyinat deyil

168.63.129.16 Azure-un xüsusi virtual platforma ünvanıdır və rollarından biri WireServer-dir; VM agenti ondan toxuculuqla danışmaq üçün istifadə edir. Microsoft sənədləşdirir ki, agentin TCP 80 və 32526 portlarına trafiki əlçatan qalmalıdır. Bu, adi internet hostu deyil və tam tunel VPN-in onu uzaq çıxışa daşıması lazım deyil. Sağlam görünən tunelin agenti belə ac qoya bilməsinin səbəbi budur.

Platforma ünvanı sənədləşməsi həmçinin deyir ki, bu ünvan istifadəçi tərəfindən müəyyən edilmiş marşrutlara tabe deyil; bu, qonağınız haqqında vəd deyil, Azure toxuculuğunun xassəsidir. Lokal firewall qaydası və ya VPN müştərisinin öz marşrut siyasəti yenə də yolu poza bilər və heç biri VNet-in marşrut cədvəlində yaşamır.

Əgər problemi bildirən agentdirsə, hər hansı şeyi yenidən quraşdırmadan əvvəl xidmətin vəziyyətini və həmin ünvana gedən yolu yoxlayın.

169.254.169.254-ün öz qaydaları var

169.254.169.254 Azure Instance Metadata Service üçün link-local ünvandır. Ona edilən sorğuların öz tələbləri var: əsas NIC və əsas IP, ünvanı dəstəkləyən DHCP konfiqurasiyası və istənilən HTTP proksisinin yan keçməsi. Onları uzaq VPN çıxışından və ya ixtiyari internet şlüzündən göndərmək Microsoft-un təsvir etdiyi giriş modeli deyil.

Bu proksi bəndi marşrutu düzəldib yenə nasazlıq görənləri tutur. Qonaq HTTP proksisi IMDS-i poza bilər, halbuki ip route get tam gözlədiyiniz interfeysi qaytarır, ona görə də yalnız marşrutları deyil, proksi istisnalarını da yoxlayın.

Bunu ayırd edərkən metadata cavablarını dəstək bileti kimi yapışdırmayın. Onlar insidentdən daha uzun yaşayan etimadnamələr və instans detalları daşıya bilər.

Qonağın siyasət marşrutlaşdırmasını oxuyun, yalnız əsas cədvəli deyil

Linux qonağında üç yalnız-oxuma əmri qatları ayırır: siyasət qaydaları üçün ip -4 rule show, sonra kernelin həqiqətən verdiyi qərarlar üçün ip -4 route get 168.63.129.16 və ip -4 route get 169.254.169.254. Onları VPN qoşulmadan əvvəl və sonra işə salın. Bu iki çıxış arasındaki fərq sizin dəyişiklik dəstinizdir və müştərinin nə etdiyinə dair hər hansı təxmindən faydalıdır.

Siyasət qaydaları quraşdıran VPN müştərisi əsas cədvəli toxunulmaz qoyub həmin axtarışları yenə də yönləndirə bilər. Buna görə yalnız əsas cədvəli düzəldən həll bir hostda işləyir, digərində heç nə etmir. Çox NIC-li qonaqlar eyni problemi digər tərəfdən əlavə edir, çünki cavab qaydanın hansı NIC və mənbə ünvanını seçdiyindən asılıdır.

Hər iki /32 marşrutunu köhnə şlüz vasitəsilə əlavə edən reseptə müqavimət göstərin. Link-local platforma yolu və ümumi WAN növbəti hopu fərqli obyektlərdir və hər şeyi əhatə edən istisna real siyasət konfliktini gizlədir.

İnzibatetmə və bərpanı ayrı saxlayın

SSH və ya RDP cavabınızı tam tunel defoltu da tuta bilər, lakin o, platforma son nöqtələrindən birini deyil, administratorun müşahidə olunan ünvanını hədəfləyir. Onu öz sorğu-cavab cütündən diaqnoz edin və VPN siyasətini dəyişməzdən əvvəl seriyalı konsol kimi müstəqil bərpa kanalı saxlayın. Əgər yerləşdirmə VM-i yenidən başladırsa və agent nasazlıq bildirirsə, yenidən başlatmanın marşrut dəyişikliyindən qaynaqlandığını güman etmək əvəzinə qeydə alınmış əməliyyatı və məsul xidməti yoxlayın.

Sonra üç axını ayrı-ayrılıqda yoxlayın: həqiqətən istədiyiniz özəl resurs, dəstəklənən agent və platforma əlaqəsi, və inzibati yol. Onlardan birini bərpa etmək digər ikisinin sağ qaldığına sübut deyil.

Təsdiqlənmiş istisnanı qonaq şəbəkəsinin və VPN konfiqurasiyasının sahibi adından yazın, yenidən qoşulma və yenidən başlatma zamanı nə baş verdiyini də daxil edin. Azure UDR-ləri qonağın marşrut cədvəli deyil və onları redaktə etmək lokal siyasət qaydasını düzəltməyəcək.