NAT arxasındakı FortiGate: local-gw, localid və publik IP

NAT arxasındakı FortiGate 10.0.0.2 ünvanına WAN interfeysində sahib ola bilər, halbuki internet onu 198.51.100.40 kimi təqdim edir və hər iki rəqəm realdır. Cihazın bağlandığı ünvan və IKE autentifikasiyası zamanı göndərdiyi kimlik ayrı seçimlər, ayrı sahələr, ayrı auditoriyalar üçündür. NAT keçərkən xarici ünvanlamanı yenidən yazır; autentifikasiya olunmuş kimliyi uzaq tərəfin gözlədiyi hər şeyə çevirmir. Bu formada əksər faza 1 uğursuzluqları düzgün dəyərin səhv sahəyə qoyulmasından gəlir.

Üç dəyər, üç sahib

Üç dəyəri və hər birinin sahibini adlandırmaqla başlayın. local-gw FortiGate-in xarici interfeysində IKE üçün mənbə kimi istifadə etdiyi ünvandır və cihazın həqiqətən saxladığı ünvan olmalıdır. Publik son nöqtə NAT cihazının ünvanıdır və tərcüməni edən tərəfə aiddir. IKE kimliyi uzaq tərəfin öz konfiqurasiyası ilə uyğunlaşdırdığı sətirdir və ümumiyyətlə IP ünvanı olması tələb olunmur.

Sahə adları əvəzləməyə təhrik edəcək qədər yaxındır və tələ məhz budur. localid və localid-type identifikasiyanı təsvir edir; local-gw lokal bağlanmanı təsvir edir.

Bir nümunə fərqi konkretləşdirir. FortiGate-də config vpn ipsec phase1-interface açın, sonra set interface "wan1" və set local-gw 10.0.0.2 — qutunun sahib olduğu ünvan, IKE soketinin uğurla bağlanmasını təmin edən də budur. local-gw dəyərini 0.0.0.0 olaraq buraxsanız interfeys ünvanı istifadə olunur, bu adətən eyni şeydir, lakin daha az açıqdır. local-gw dəyərini 198.51.100.40 ünvanına qoymayın, çünki cihaz həmin ünvana sahib deyil və soket ona bağlana bilməyəcək. İki dəyəri kağız üzərində bərabər göstərmək konfiqurasiya deyil.

Addım 1: uzaq tərəfin qəbul edəcəyi kimliyi seçin

İndi kimlik, bu fərqli qərardır. set localid uzaq tərəfin müqayisə edəcəyi dəyəri alır və set localid-type FortiGate-ə onu necə şərh edəcəyini deyir: ünvan, FQDN, istifadəçi FQDN-i və ya açar ID. auto ilə cihaz onu çıxarır, adətən çıxan interfeys ünvanından, yəni NAT cihazının dəyişmək üzrə olduğu dəyərdən.

Bu çıxarış bu topologiyada açıq kimliyin niyə vacib olduğunu göstərir. Uzaq tərəf ünvan kimliyi gözləyirsə localid-type address və localid dəyərlərini onun görəcəyi publik ünvana qoyun, sonra uzaq tərəfin bu dəyəri marşrut hədəfi kimi deyil, kimlik kimi qəbul etdiyini təsdiqləyin. Uzaq tərəf FQDN gözləyirsə localid-type fqdn və onunla konfiqurasiya olunduğu adı istifadə edin. Həqiqətən nə göndərildiyini diagnose vpn ike gateway list ilə yoxlayın; bu, yazmaq istədiyinizi deyil, şlüz vəziyyətini və istifadə olunan identifikatorları göstərir. Kimlik növü seçiminin ixtiyari qeyri-lokal ünvanı qəbul etdiyini fərz etməyin; əvvəlcə buraxılışın sənədləşdirilmiş semantikasına baxın.

Addım 2: UDP 500 və 4500-ü cihaza yönləndirin

Üçüncü dəyər NAT cihazına aiddir və insanların yoxlamağı unutduğu elə budur. Publik son nöqtə UDP 500 və UDP 4500-ü FortiGate-ə yönləndirməlidir, çünki NAT-T aşkarlanması və ardınca gələn inkapsullaşdırılmış ESP hər ikisi bu portların gəlməsindən asılıdır. Bu dizaynın fərz etdiyi şey birlikdə-birə xəritələmədir; bir publik ünvanın bir neçə uzaq tərəf arasında port əsaslı paylaşılması fərqli məhdudiyyətləri olan fərqli topologiyadır.

Yönləndirməni ümidlə deyil, tutma ilə təsdiqləyin: diagnose sniffer packet any "udp port 500 or udp port 4500" 4 paketlərin gəlib-gəlmədiyini və cavabların çıxıb-çıxmadığını göstərir.

Google Cloud VPN NAT arxasındakı uzaq tərəf üçün dəstəklənən quruluş kimi NAT-T ilə birlikdə-birə NAT-ı sənədləşdirir və uzaq tərəf Cloud VPN şlüzüdürsə dizayn etməli olduğunuz məhdudiyyət budur. Birdən-çoxa və ya port əsaslı paylaşma eyni dəstəklənən topologiya deyil və heç bir lokal kimlik tənzimləməsi bunu dəyişmir. Uzaq tərəf başqa cihazdırsa onun öz sənədləri kimlik kimi nəyi qəbul edəcəyini və tərcümə olunmuş ünvana dözüb-dözməyəcəyini müəyyən edir. Lokal sahəni dəyişməzdən əvvəl bunu oxuyun, çünki lokal tərəf uzaq tərəfin tətbiq etmədiyi qaydanı razılaşdıra bilməz.

Addım 3: faza 1-in həll etmədiyini yoxlayın

NAT keçidi tuneli qaldırır, kimlik razılığı uzaq tərəfin onu qəbul edib-etməyəcəyini həll edir, daxili prefiks marşrutlaşdırması isə həqiqətən nəyin keçdiyini müəyyən edir. Düzgün lokal ID çatışmayan statik marşrutu və ya çatışmayan trafik selektorunu verə bilməz.

Ona görə qat-qat yoxlayın. get vpn ipsec tunnel details tunelin qalxıb-qalxmadığını və hansı selektorların razılaşdırıldığını göstərir; konfiqurasiya olunmuş uzaq altşəbəkə ilə razılaşdırılmış selektor arasındakı uyğunsuzluq faza 2 kostyumunda marşrutlaşdırma problemidir. execute vpn ike gateway clear yenidən danışıqları məcbur edir, beləliklə son dəyişikliyinizdən əvvəl qurulmuş sessiyanı deyil, cari konfiqurasiyanı sınaqdan keçirirsiniz. Sonra uzaq prefiksdəki hosta trafik göndərin və sayğacların hərəkət etdiyini təsdiqləyin, çünki qalxmış və heç nə keçirməyən tunel yoxlayana qədər işlək tunelə tam bənzəyir.

Üç dəyəri qeydlərinizdə bir yerdə saxlayın: cihazın sahib olduğu lokal ünvan, NAT cihazının təqdim etdiyi publik son nöqtə və uzaq tərəfin gözlədiyi kimlik sətri. Onlar fərqli səbəblərdən və fərqli vaxtlarda dəyişir.

NAT cihazının yenidən nömrələnməsi FortiGate-in local-gw sahəsinə toxunmaq üçün səbəb deyil və kimlik dəyişikliyi heç nəyi yenidən nömrələmək üçün səbəb deyil. İkisini qarışdırmaq işlək tunelin əlaqəsiz texniki xidmət pəncərəsində yenidən qurulmasına gətirib çıxarır. Cloud VPN NAT təlimatı həmin tərəfdə dəstəklənən topologiya üçün istinaddır.

Məsələni həll edən test darıxdırıcı və sürətlidir: xarici interfeysdə tutma aparın, uzaq tərəfdən UDP 500 və 4500-ün gəldiyini təsdiqləyin, IKE mübadiləsindəki kimliyin uzaq tərəfin gözləmək üçün konfiqurasiya olunduğu ilə uyğun olduğunu təsdiqləyin, sonra razılaşdırılmış selektorların sizi maraqlandıran altşəbəkələri əhatə etdiyini təsdiqləyin. Birinci yoxlama uğursuz olarsa şübhəli NAT cihazıdır. İkinci uğursuz olarsa kimlik sahələridir. Üçüncü uğursuz olarsa nə NAT, nə də kimlik heç vaxt problem olmayıb.