FortiGate за NAT: local-gw, localid і публічний IP

FortiGate за NAT може володіти 10.0.0.2 на своєму інтерфейсі WAN, хоча інтернет подає його як 198.51.100.40, і обидва числа реальні. Адреса, до якої прив'язується пристрій, і ідентичність, яку він надсилає під час автентифікації IKE, — це різні рішення, ухвалені в різних полях для різних адресатів. NAT переписує зовнішню адресацію по дорозі, але не переписує автентифіковану ідентичність у те, що очікує віддалений партнер. Більшість збоїв фази 1 у такій схемі стаються через те, що правильне значення ставлять у неправильне поле.

Три значення, три власники

Почніть із того, щоб назвати три значення й власника кожного. local-gw — це адреса, яку FortiGate використовує як джерело IKE на зовнішньому інтерфейсі, і вона має бути адресою, якою пристрій справді володіє. Публічний кінцевий пункт — це адреса пристрою NAT, і нею володіє той, хто виконує трансляцію. Ідентичність IKE — це рядок, який партнер порівнює зі своєю конфігурацією, і він зовсім не мусить бути IP-адресою.

Назви полів досить близькі, щоб провокувати підміну, і в цьому пастка. localid і localid-type описують ідентифікацію; local-gw описує локальне прив'язування.

Приклад робить різницю конкретною. На FortiGate відкрийте config vpn ipsec phase1-interface, потім set interface "wan1" і set local-gw 10.0.0.2 — адреса, якою володіє пристрій, і саме це дає змогу сокету IKE успішно прив'язатися. Залиште local-gw на 0.0.0.0, і використовуватиметься адреса інтерфейсу, що зазвичай те саме, але менш явно. Не задавайте local-gw рівним 198.51.100.40, бо пристрій не володіє цією адресою і сокет до неї не прив'яжеться. Зробити два значення однаковими на папері — це не конфігурація.

Крок 1: виберіть ідентичність, яку прийме партнер

Тепер ідентичність, а це інше рішення. set localid приймає значення, яке партнер порівнюватиме, а set localid-type повідомляє FortiGate, як його тлумачити: адреса, FQDN, користувацький FQDN або ключовий ID. З auto пристрій виводить його, зазвичай з адреси вихідного інтерфейсу, а це саме те значення, яке пристрій NAT збирається змінити.

Саме цей вивід і пояснює, чому в цій топології важлива явна ідентичність. Якщо партнер очікує адресну ідентичність, задайте localid-type address і localid рівними публічній адресі, яку побачить партнер, а потім переконайтеся, що партнер приймає це значення як ідентичність, а не як ціль маршрутизації. Якщо партнер очікує FQDN, використовуйте localid-type fqdn і ім'я, з яким його було налаштовано. Перевірте, що фактично надіслано, командою diagnose vpn ike gateway list, яка показує стан шлюзу та використовувані ідентифікатори, а не те, що ви збиралися ввести. Не припускайте, що опція типу ідентичності приймає довільну нелокальну адресу; спершу перевірте документовану семантику випуску.

Крок 2: переспрямуйте UDP 500 і 4500 на пристрій

Третє значення належить пристрою NAT, і саме його люди забувають перевірити. Публічний кінцевий пункт має переспрямовувати UDP 500 і UDP 4500 на FortiGate, бо виявлення NAT-T і наступний інкапсульований ESP обидва залежать від надходження цих портів. Ця схема передбачає взаємно однозначне зіставлення; поділ однієї публічної адреси за портами між кількома партнерами — це інша топологія з іншими обмеженнями.

Підтвердьте переспрямування захопленням, а не надією: diagnose sniffer packet any "udp port 500 or udp port 4500" 4 показує, чи приходять пакети і чи виходять відповіді.

Google Cloud VPN документує NAT один-до-одного з NAT-T як підтримувану схему для партнера за NAT, і саме це обмеження треба враховувати, якщо віддалений бік — шлюз Cloud VPN. Поділ один-до-багатьох або за портами — це не та сама підтримувана топологія, і жодне локальне налаштування ідентичності цього не змінює. Якщо віддалений бік — інший пристрій, його власна документація визначає, що він прийме як ідентичність і чи терпить трансльовану адресу партнера. Прочитайте це, перш ніж змінювати локальне поле, бо локальний бік не може узгодити правило, якого віддалений бік не реалізує.

Крок 3: перевірте, чого не вирішує фаза 1

Проходження NAT піднімає тунель, згода щодо ідентичності вирішує, чи прийме його партнер, а маршрутизація внутрішнього префікса вирішує, що насправді проходить. Правильний локальний ID не може забезпечити відсутній статичний маршрут або відсутній селектор трафіку.

Тож перевіряйте пошарово. get vpn ipsec tunnel details показує, чи піднято тунель і які селектори узгоджено, а розбіжність між налаштованою віддаленою підмережею та узгодженим селектором — це проблема маршрутизації в костюмі фази 2. execute vpn ike gateway clear примусово запускає переузгодження, тож ви перевіряєте поточну конфігурацію, а не сеанс, установлений до вашої останньої зміни. Потім надішліть трафік на хост у віддаленому префіксі й переконайтеся, що лічильники рухаються, бо піднятий тунель, який нічого не пропускає, виглядає так само, як робочий, доки ви не перевірите.

Тримайте три значення в одному місці в нотатках: локальну адресу, якою володіє пристрій, публічний кінцевий пункт, який подає пристрій NAT, і рядок ідентичності, який очікує партнер. Вони змінюються з різних причин і в різний час.

Перенумерування пристрою NAT — не привід чіпати local-gw на FortiGate, а зміна ідентичності — не привід будь-що перенумеровувати. Змішувати ці дві речі — це спосіб перебудувати робочий тунель під час не пов'язаного вікна обслуговування. Настанова Cloud VPN щодо NAT — це довідка щодо підтримуваної топології на тому боці.

Тест, який усе вирішує, нудний і швидкий: зніміть захоплення на зовнішньому інтерфейсі, переконайтеся, що UDP 500 і 4500 приходять від партнера, переконайтеся, що ідентичність в обміні IKE збігається з тим, що партнер був налаштований очікувати, потім переконайтеся, що узгоджені селектори покривають потрібні вам підмережі. Якщо перша перевірка не вдалася, підозрюваний — пристрій NAT. Якщо друга — поля ідентичності. Якщо третя — то ні NAT, ні ідентичність ніколи не були проблемою.