Ayar Yapamayacağınız Cloud VPN Sınırları: IKE Ömrü ve Peer NAT

Uzak cihaza 24 saatlik bir faz 1 ömrü verin; Google tarafında her şey doğru yapılandırılmış olsa bile Cloud VPN tüneli kapalı kalır. Peer, yanıtlayıcının kabul etmeyeceği bir değer öneriyor, bu yüzden müzakere ya tamamen başarısız olur ya da sonsuza kadar yeniden başlar. Cloud VPN, faz 1'i 36,000 saniyeye, yani on saate sınırlar ve bu üst sınır yükseltebileceğiniz bir ayar değildir. Değişiklik uzak cihaza aittir.

Peer sorar, yanıtlayıcı karar verir

IKE, iki teklif kümesi arasında eşleştirme alıştırmasıdır. Tünel yalnızca kümelerin yanıtlayıcının kabul ettiği sınırlar içinde örtüştüğü yerde oluşur, bu yüzden aralık dışındaki bir ömür kısmi bir tünel bile üretmez. Olağan hata, peer yapılandırmasını teklif değil dilek listesi olarak görmektir. Boş kesişim, yönlendirme ve seçiciler ne kadar doğru olursa olsun tüneli kapalı bırakır.

Bir kayıt açmadan önce tünelin kendi durumunu okuyun, çünkü ayrıntılı durum genellikle başarısız olan fazı adlandırır:

gcloud compute vpn-tunnels describe office-tunnel \
  --region europe-west1 \
  --format="value(status,detailedStatus)"

Dönen bilgiyi ağ geçidi türünüz ve IKE sürümünüz için desteklenen kümeyle karşılaştırın ve oradayken iki trafik seçicisini de kaydedin. Seçici uyuşmazlığı, algoritma uyuşmazlığıyla aynı kapalı tünel belirtisini verir ve algoritmadan farklı olarak bunu sizin düzeltmeniz gerekir.

36,000 saniye üst sınırdır

Faz 1, 36,000 saniyede durur. 86,400'e ayarlı bir cihaz, yanıtlayıcının asla kabul etmeyeceği bir şey ister ve yeniden denemek fikrini değiştirmez. Uzak teklifi aralığın içine geri alın, aynı yapılandırma kurulur; asimetri dersin tamamıdır, çünkü kendi değerinizi düşürebilirsiniz ama Google'ın değerini yükseltemezsiniz.

Seçilen değeri tasarım notlarına yazın. Aksi halde bir sonraki mühendis 24 saatlik deneyi tekrarlar ve aynı duvara çarpar.

Desteklenen küme, her ağ geçidi türü ve IKE sürümü için şurada yayımlanır: Cloud VPN genel bakışı, bu yüzden genel bir IKE kılavuzu yerine topolojinize ait bölümü okuyun.

Belirli bir düzenle düşen tünel

Faz 2 farklı davranır: iki uç anlaşamadığında anahtar yenileme daha kısa aralığı izler. Uyuşmazlığı ölümcül sayan peer, tüneli düşürür, böylece tek bir uyuşmazlık iki ilgisiz arıza gibi görünebilir. Yalnızca ilk bağlantıya değil, anahtar yenileme ritmine bakın. Düzenli bir tempoda açılıp düşen bir tünel, yönlendirme kusurundan çok ömür uyuşmazlığıdır.

Herhangi bir şeyi değiştirmeden önce o düşme zaman damgalarını peerin kendi günlükleriyle ilişkilendirin, çünkü seçici veya rota değişikliği aynı ritmi taklit edebilir. Tempo faz 2 zamanlayıcısıyla eşleşiyorsa neden, teklife dokunmadan bulunmuş olur.

Kümeler ağ geçidi türünden gelir

Şifreleme ve bütünlük kümeleri, strongSwan'ın izin verdiği gibi düzenlediğiniz tünel başına profil değildir. Onları ağ geçidi türü ve IKE sürümüne göre seçersiniz ve var olmayan bir profili aramak bir öğleden sonrayı harcar.

Desteklenen kümenin içinde hiçbir şey sunmayan eski bir cihaz iki dürüst yol bırakır: cihazı değiştirin ya da kontrolünüzdeki bir yazılım ağ geçidinde sonlandırıp oradan VPC'ye yönlendirin. Bunun dışındaki her şey bir sonraki incelemede başarısız olacak bir geçici çözümdür.

Cihaz başına bir dış adres

Peerin dış adresi, iç adresine bire bir eşlenmelidir. Aşırı yüklenmiş bir PAT havuzu çalışamaz, çünkü tek bir genel adresin arkasındaki birkaç ana bilgisayar, yanıtlayıcıya onları ayırmanın hiçbir yolunu vermez. Birden çok ana bilgisayarın bir adresi paylaşması gerekiyorsa tünel, onları ayırt edebilen bir yerde bitmelidir.

O dış adresi de kararlı tutun. Cihazı başka bir NAT'ın arkasına taşıyın, her teklif hâlâ eşleşse bile ilişki kopar. Hangi değerlerin Google'a, hangilerinin size ait olduğunu yazmakta fayda var: ömürler, kümeler ve bire bir NAT onların tarafında sabittir; teklifler, seçiciler, yönlendirme ve BGP öncelikleri ise sizindir.