NAT arkasındaki FortiGate: local-gw, localid ve genel IP

NAT arkasındaki bir FortiGate, WAN arayüzünde 10.0.0.2 adresine sahip olabilirken internet onu 198.51.100.40 olarak gösterir ve iki sayı da gerçektir. Cihazın bağlandığı adres ile IKE kimlik doğrulaması sırasında gönderdiği kimlik ayrı kararlardır; ayrı alanlarda, ayrı hedef kitleler için verilir. NAT yolda dış adreslemeyi yeniden yazar; kimliği doğrulanmış bir kimliği uzak peer'in beklediği şeye yeniden yazmaz. Bu biçimdeki 1. faz hatalarının çoğu doğru değerin yanlış alana konmasından kaynaklanır.

Üç değer, üç sahip

Üç değeri ve her birinin sahibini adlandırarak başlayın. local-gw FortiGate'in dış arayüzünde IKE için kaynak olarak kullandığı adrestir ve cihazın gerçekten sahip olduğu bir adres olmalıdır. Genel uç nokta NAT cihazının adresidir ve çeviriyi yapan tarafa aittir. IKE kimliği, peer'in kendi yapılandırmasıyla karşılaştırdığı bir dizedir ve bir IP adresi olması hiç gerekmez.

Alan adları değiştirmeye davet edecek kadar yakındır ve tuzak da budur. localid ve localid-type kimliklendirmeyi tanımlar; local-gw yerel bağlamayı tanımlar.

Bir örnek farkı somutlaştırır. FortiGate'te config vpn ipsec phase1-interface komutunu açın, ardından set interface "wan1" ve set local-gw 10.0.0.2 ayarlayın — kutunun sahip olduğu adres budur ve IKE soketinin başarıyla bağlanmasını sağlayan da budur. local-gw değerini 0.0.0.0 olarak bırakırsanız arayüz adresi kullanılır; bu genellikle aynı şeydir ama daha az açıktır. local-gw değerini 198.51.100.40 olarak ayarlamayın, çünkü cihaz o adrese sahip değildir ve soket ona bağlanmaz. İki değeri kâğıt üzerinde eşit göstermek yapılandırma değildir.

Adım 1: peer'in kabul edeceği kimliği seçin

Şimdi kimlik, ki bu farklı bir karardır. set localid peer'in karşılaştıracağı değeri alır ve set localid-type FortiGate'e bunun nasıl yorumlanacağını söyler: bir adres, bir FQDN, kullanıcı FQDN'si veya anahtar ID'si. auto ile cihaz bunu genellikle giden arayüzün adresinden türetir; bu tam olarak NAT cihazının değiştirmek üzere olduğu değerdir.

Bu türetme, bu topolojide açık bir kimliğin neden önemli olduğunun nedenidir. Peer bir adres kimliği bekliyorsa localid-type address ve localid değerlerini peer'in göreceği genel adrese ayarlayın, ardından peer'in bu değeri yönlendirme hedefi olarak değil kimlik olarak kabul ettiğini doğrulayın. Peer bir FQDN bekliyorsa localid-type fqdn ve yapılandırıldığı adı kullanın. Gerçekte ne gönderildiğini diagnose vpn ike gateway list ile doğrulayın; bu, yazmayı düşündüğünüzü değil ağ geçidinin durumunu ve kullanılan tanımlayıcıları gösterir. Kimlik türü seçeneğinin rastgele yerel olmayan bir adresi kabul ettiğini varsaymayın; önce sürümün belgelenmiş anlamını kontrol edin.

Adım 2: UDP 500 ve 4500'ü cihaza iletin

Üçüncü değer NAT cihazına aittir ve insanların kontrol etmeyi unuttuğu değer odur. Genel uç nokta UDP 500 ve UDP 4500'ü FortiGate'e iletmelidir, çünkü NAT-T algılaması ve ardından gelen kapsüllenmiş ESP ikisi de bu bağlantı noktalarının gelmesine bağlıdır. Bu tasarım bire bir eşleme varsayar; tek bir genel adresi birden çok peer arasında bağlantı noktasına göre paylaşmak, farklı sınırları olan farklı bir topolojidir.

İletimi bir yakalama ile doğrulayın, bir umutla değil: diagnose sniffer packet any "udp port 500 or udp port 4500" 4 paketlerin gelip gelmediğini ve yanıtların çıkıp çıkmadığını gösterir.

Google Cloud VPN, NAT arkasındaki peer için desteklenen düzenleme olarak NAT-T ile bire bir NAT'ı belgeler ve uzak uç bir Cloud VPN ağ geçidiyse tasarımın bu sınırlamaya göre yapılması gerekir. Bire çok veya bağlantı noktasına göre paylaşım aynı desteklenen topoloji değildir ve hiçbir yerel kimlik ayarı bunu değiştirmez. Uzak taraf başka bir cihazsa, kendi belgeleri kimlik olarak neyi kabul edeceğini ve çevrilmiş peer adresine tolerans gösterip göstermeyeceğini tanımlar. Yerel bir alanı değiştirmeden önce bunu okuyun, çünkü yerel taraf uzak tarafın uygulamadığı bir kuralı müzakere edemez.

Adım 3: 1. fazın neyi çözmediğini kontrol edin

NAT geçişi tüneli kaldırır, kimlik uzlaşması peer'in bunu kabul edip etmeyeceğine karar verir ve iç önek yönlendirmesi gerçekte neyin geçtiğine karar verir. Doğru bir yerel ID eksik bir statik rotayı veya eksik bir trafik seçiciyi sağlayamaz.

Bu yüzden katman katman doğrulayın. get vpn ipsec tunnel details tünelin ayakta olup olmadığını ve hangi seçicilerin müzakere edildiğini gösterir; yapılandırılmış uzak alt ağ ile müzakere edilen seçici arasındaki uyumsuzluk, 2. faz kılığındaki bir yönlendirme sorunudur. execute vpn ike gateway clear yeniden müzakereyi zorlar, böylece son değişikliğinizden önce kurulmuş bir oturumu değil mevcut yapılandırmayı test edersiniz. Ardından uzak önekteki bir ana bilgisayara trafik gönderin ve sayaçların hareket ettiğini doğrulayın, çünkü ayakta olup hiçbir şey geçirmeyen bir tünel, kontrol edene kadar çalışan bir tünelle aynı görünür.

Üç değeri notlarınızda tek bir yerde tutun: cihazın sahip olduğu yerel adres, NAT cihazının sunduğu genel uç nokta ve peer'in beklediği kimlik dizesi. Farklı nedenlerle ve farklı zamanlarda değişirler.

NAT cihazını yeniden numaralandırmak FortiGate'in local-gw alanına dokunmak için bir neden değildir ve kimlik değişikliği herhangi bir şeyi yeniden numaralandırmak için bir neden değildir. İkisini karıştırmak, çalışan bir tünelin ilgisiz bir bakım penceresinde yeniden kurulma şeklidir. Cloud VPN NAT rehberi o taraftaki desteklenen topoloji için referanstır.

Buna karar veren test sıkıcı ve hızlıdır: dış arayüzde yakalama yapın, UDP 500 ve 4500'ün peer'den geldiğini doğrulayın, IKE alışverişindeki kimliğin peer'in beklemek üzere yapılandırıldığıyla eşleştiğini doğrulayın, ardından müzakere edilen seçicilerin önemsediğiniz alt ağları kapsadığını doğrulayın. İlk kontrol başarısız olursa şüpheli NAT cihazıdır. İkincisi başarısız olursa kimlik alanlarıdır. Üçüncüsü başarısız olursa ne NAT ne de kimlik hiçbir zaman sorun olmamıştır.