Azure VM, VPN başladıktan sonra IMDS veya WireServer'a ulaşamıyor

VM açık, VPN istemcisi bağlı olduğunu söylüyor ve birkaç dakika sonra Azure aracısı sağlıksız durum bildirmeye başlıyor. Bazen SSH yaşıyor ama portaldan Run Command çalışmıyor; bu da insanları yönlendirme tablosu yerine aracıya bakmaya itiyor. Tünel açıldığında konuğun kendi iletim kararları değişti ve genellikle iki platform adresi ilk kayıplar oluyor. Bunu aracı arızası olarak ele almadan önce bir yönlendirme belirtisi olarak ele alıyorum.

Belirti bozuk bir aracı gibi görünüyor

Aşağıdaki iki adres de çözüm olarak öneriliyor, oysa aynı hizmet değiller. Birine /32 kopyalamak, diğerinde işe yaradı diye, geçici bir çözümün kimsenin kaldırmaya cesaret edemediği kalıcı bir yapılandırmaya dönüşmesinin tam yoludur.

İşe yarayan sıra önce başarısız çağrının gerçekte hangi adresi hedeflediğini doğrulamak, sonra konuğun onu nasıl çözdüğünü okumaktır. Geri kalan her şey ek adımlarla tahmin ve daha uzun bir değişiklik penceresidir.

168.63.129.16 genel bir hedef değil

168.63.129.16, Azure'un özel sanal platform adresidir ve rollerinden biri, VM aracısının fabric ile konuşmak için kullandığı WireServer'dır. Microsoft, aracının TCP 80 ve 32526 bağlantı noktalarına giden trafiğinin kullanılabilir kalması gerektiğini belgeler. Bu sıradan bir internet sunucusu değildir ve tam tünelli bir VPN'in uzak bir çıkışa taşımaması gerekir. Bu yüzden sağlıklı görünen bir tünel bile aracıyı açlığa mahkûm edebilir.

Platform adresi belgeleri de bu adresin kullanıcı tanımlı yönlendirmelere tabi olmadığını söyler; bu Azure fabric'inin bir özelliğidir, konuğunuz hakkında bir söz değildir. Yerel bir güvenlik duvarı kuralı veya VPN istemcisinin kendi yönlendirme politikası yolu yine de bozabilir ve hiçbiri VNet'in yönlendirme tablosunda yaşamaz.

Sorunu bildiren aracıysa, herhangi bir şeyi yeniden kurmadan önce hizmet durumunu ve o adrese giden yolu kontrol edin.

169.254.169.254'ün kendi kuralları var

169.254.169.254, Azure Instance Metadata Service için link-local adresidir. Ona giden isteklerin kendi gereksinimleri vardır: birincil NIC ve birincil IP, adresi destekleyen bir DHCP yapılandırması ve herhangi bir HTTP proxy'yi atlama. Bunları uzak bir VPN çıkışından veya rastgele bir internet ağ geçidinden göndermek Microsoft'un anlattığı erişim modeli değildir.

Bu proxy maddesi rotayı düzeltip hâlâ hata görenleri yakalar. Konuktaki HTTP proxy'si IMDS'yi bozabilirken ip route get tam olarak beklediğiniz arayüzü döndürür; bu yüzden rotaların yanı sıra proxy istisnalarını da kontrol edin.

Bunu ayıklarken meta veri yanıtlarını bir destek talebine yapıştırmayın. Olaydan daha uzun yaşayan kimlik bilgileri ve örnek ayrıntıları taşıyabilirler.

Konuğun politika yönlendirmesini okuyun, yalnızca ana tabloyu değil

Linux konuğunda üç salt okunur komut katmanları ayırır: politika kuralları için ip -4 rule show, ardından çekirdeğin gerçekten verdiği kararlar için ip -4 route get 168.63.129.16 ve ip -4 route get 169.254.169.254. VPN bağlanmadan önce ve sonra çalıştırın. Bu iki çıktı arasındaki fark değişiklik kümenizdir ve istemcinin ne yaptığına dair herhangi bir tahminden daha faydalıdır.

Politika kuralları kuran bir VPN istemcisi ana tabloyu dokunmadan bırakıp bu aramaları yine de yönlendirebilir. Bu yüzden yalnızca ana tabloyu düzelten bir çözüm bir ana bilgisayarda işe yarıyor gibi görünür, sonrakinde hiçbir şey yapmaz. Birden fazla NIC'li konuklar aynı sorunu diğer yönden ekler, çünkü yanıt kuralın hangi NIC'i ve kaynak adresi seçtiğine bağlıdır.

Her iki /32 rotasını eski ağ geçidi üzerinden ekleyen tarife direnin. Link-local platform yolu ile genel WAN sonraki atlaması farklı nesnelerdir ve toptan bir istisna gerçek politika çatışmasını gizler.

Yönetimi ve kurtarmayı ayrı tutun

SSH veya RDP yanıtınız da tam tünel varsayılanı tarafından yakalanabilir, ancak platform uç noktasını değil, yöneticinin gözlenen adresini hedefler. Bunu kendi istek-yanıt çiftinden teşhis edin ve VPN politikasını değiştirmeden önce seri konsol gibi bağımsız bir kurtarma kanalı bulundurun. Bir dağıtım VM'i yeniden başlatırsa ve aracı sağlıksız bildirirse, yeniden başlatmaya rota değişikliğinin neden olduğunu varsaymak yerine kaydedilen eylemi ve sorumlu hizmeti inceleyin.

Ardından üç akışı ayrı ayrı doğrulayın: gerçekten istediğiniz özel kaynak, desteklenen aracı ve platform iletişimi ve yönetim yolu. Birini geri yüklemek, diğer ikisinin hayatta kaldığının kanıtı değildir.

Onaylanan istisnayı konuk ağının ve VPN yapılandırmasının sahibi adına yazın; yeniden bağlanma ve yeniden başlatmada ne olacağını da ekleyin. Azure UDR'leri konuğun yönlendirme tablosu değildir ve onları düzenlemek yerel bir politika kuralını düzeltmez.