Çok NIC'li GCP VM: yanıtlar neden yanlış arayüzden çıkıyor

Bir Compute Engine VM'ine ikinci bir arayüz eklemek ona başka bir ağ bağlantısı verir, simetrik bir dönüş yolu değil. Konuk hâlâ kendi rotalarından ve kurallarından bir arayüz ve kaynak adresi seçer. Ardından Google Cloud, paketin çıktığı arayüz çevresinde VPC yönlendirmesini ve güvenlik duvarı ilkesini uygular. Bu iki karar uyuşmadığında, istekler bir NIC'ye varır ve yanıtlar diğerinden çıkar, şube de yarı açık bir konuşma görür.

Yolu beş adımda izleyin, ilke kuralı yazmadan önce uyumsuzluk ortaya çıkacaktır.

Adım 1: bulut NIC'lerini konuk aygıtlarıyla eşleştirin

Bulut arayüzleri nic0, nic1 ve benzeri diye adlandırır, konuk ise eşleşmesi gerekmeyen aygıt adları görür. Eşlemeyi her şeyden önce örnek meta verilerinden veya arayüzün kendi adresinden çözün. DHCP'nin sağladığı olağan varsayılan rota nic0 ile ilişkilidir, bu yüzden internete giden yol bu kadar sık kazara kazanır. Tahmin edilen bir aygıt adına göre ilke yazmak, doğru kuralın yanlış arayüze düşme biçimidir.

Adresleri, aygıt adlarını ve her birinin ait olduğu VPC'yi not edin. O üç sütunlu harita sonraki her adımın girdisidir.

Adım 2: iki yönlendirme kararını adlandırın

İlk karar konuğa aittir: bu paket için hangi arayüz ve hangi kaynak adresi. İkincisi buluta aittir: VPC'nin rotaları ve güvenlik duvarı ilkesi o arayüz çevresinde neye izin verir.

VPN'e bakan VPC'de görünen bir rota, o NIC'yi seçen bir konuk rotası hâline gelmez. Bulut rotası ağın ne teslim edebileceğini açıklar, konuk rotası ise paketin ne yaptığını belirler.

Adım 3: bir dönüş yolu ilkesi seçin

Küçük ve kararlı bir şube öneki kümesi için konukta açık hedef rotaları en basit ifadedir: bu öneklere yanıtlar VPN'e bakan arayüzden çıkar. Birkaç hizmet bilerek farklı yerel kaynak adresleri kullandığında, arayüz başına tablo seçen kaynak tabanlı kurallar her yanıtı doğru bağlamda tutar. Birden çok arayüz belgesi, bu tasarımların dayandığı NIC adlandırmasını ve varsayılan rota davranışını açıklar.

Her tablo geçerli bağlı rotalara ve sonraki atlamalara, ayrıca kendisine sorulacak hedeflere ihtiyaç duyar. Eksik bir tabloya işaret eden kural, dönüş yolu tasarımı değildir. O NIC için belgelenmiş ağ geçidini kullanın, alt ağın görünümünden bir Ethernet ağ geçidi uydurmayın.

Adım 4: konuğun kendi filtrelerini denetleyin

Sunucunun nerede dinlediğini ve yanıtın hangi yerel kaynağı taşıdığını denetleyin. Tüm adreslerde dinleyen bir dinleyici yönlendirme ilkesini geçersiz kılmaz, bu yüzden tüm adreslere bağlanmak yanıtın çıktığı arayüz açısından hiçbir şeyi değiştirmez.

Linux'ta ters yol doğrulamasını amaçlanan tasarıma göre gözden geçirin. Onu ilk adım olarak genel olarak devre dışı bırakmak, bir yönlendirme hatasını sahtekârlığa maruz kalma ile değiştirir ve bulmaya çalıştığınız asimetriyi gizler.

Adım 5: her yol için bir akış test edin

İzin verilen bir şube isteğini ve ilgisiz bir internet isteğini ayrı ayrı doğrulayın, her biri gerçek kaynağı ve hedefiyle. Yapabildiğinizde iki arayüzde de yakalayın, çünkü işe yarar kanıt yanıtı hangi arayüzün taşıdığıdır. Ardından bulut tarafındaki ilkenin tasarladığınız yola saygı gösterdiğini doğrulayın. Başarılı tek bir istek tek bir akışı kanıtlar, simetrik bir tasarımı değil.

İki testi notlarınızda ayrı tutun, çünkü farklı rotalar ve farklı güvenlik duvarı kuralları kullanırlar.

İkinci bir NIC'nin size vermediği şey

İkinci bir arayüz bir ağ bağlantısı ve bir adres daha ekler. Otomatik simetrik yönlendirme eklemez ve güvenlik duvarı ilkesini atlamaz. Onu bir yönlendirme düzeltmesi olarak görmek, çok NIC'li tasarımların sonradan kimsenin açıklayamadığı kurallar biriktirmesinin nedenidir.

VM başka makinelerin trafiğini iletmek zorundaysa, bu yönlendirici rolünü açıkça planlayın; iletmeye izin veren bulut ayarını ve ona eşlik eden konuk filtrelerini de dahil edin.