FortiGate za NAT: local-gw, localid i publiczny adres IP

FortiGate za NAT może posiadać 10.0.0.2 na swoim interfejsie WAN, podczas gdy internet prezentuje go jako 198.51.100.40, i obie liczby są prawdziwe. Adres, do którego urządzenie się wiąże, i tożsamość, którą wysyła podczas uwierzytelniania IKE, to osobne decyzje, podejmowane w osobnych polach, dla osobnych odbiorców. NAT przepisuje adresowanie zewnętrzne po drodze; nie przepisuje uwierzytelnionej tożsamości na to, czego oczekuje zdalny peer. Większość awarii fazy 1 w tej postaci wynika z umieszczenia właściwej wartości w niewłaściwym polu.

Trzy wartości, trzech właścicieli

Zacznij od nazwania trzech wartości i tego, kto jest właścicielem każdej. local-gw to adres, którego FortiGate używa jako źródła IKE na interfejsie zewnętrznym, i musi to być adres, który urządzenie faktycznie ma. Publiczny punkt końcowy to adres urządzenia NAT i należy do tego, kto wykonuje tłumaczenie. Tożsamość IKE to ciąg, który peer porównuje z własną konfiguracją, i wcale nie musi być adresem IP.

Nazwy pól są wystarczająco bliskie, by zachęcać do zamiany, i to jest pułapka. localid i localid-type opisują identyfikację; local-gw opisuje lokalne wiązanie.

Przykład czyni różnicę konkretną. Na FortiGate otwórz config vpn ipsec phase1-interface, następnie set interface "wan1" i set local-gw 10.0.0.2 — adres, który posiada urządzenie, i właśnie to pozwala gniazdu IKE poprawnie się związać. Zostaw local-gw na 0.0.0.0 a używany jest adres interfejsu, co zwykle jest tym samym, ale mniej jawnym. Nie ustawiaj local-gw na 198.51.100.40, ponieważ urządzenie nie posiada tego adresu i gniazdo się do niego nie zwiąże. Uczynienie dwóch wartości równymi na papierze nie jest konfiguracją.

Krok 1: wybierz tożsamość, którą peer zaakceptuje

Teraz tożsamość, która jest inną decyzją. set localid przyjmuje wartość, którą peer porówna, a set localid-type mówi FortiGate, jak ją interpretować: adres, FQDN, FQDN użytkownika lub ID klucza. Z auto urządzenie ją wywodzi, zwykle z adresu interfejsu wychodzącego, czyli dokładnie wartości, którą urządzenie NAT zaraz zmieni.

To wywodzenie jest powodem, dla którego jawna tożsamość ma znaczenie w tej topologii. Jeśli peer oczekuje tożsamości adresowej, ustaw localid-type address i localid na publiczny adres, który peer zobaczy, a następnie potwierdź, że peer akceptuje tę wartość jako tożsamość, a nie jako cel routingu. Jeśli peer oczekuje FQDN, użyj localid-type fqdn i nazwy, z którą został skonfigurowany. Sprawdź, co faktycznie zostało wysłane, poleceniem diagnose vpn ike gateway list, które pokazuje stan bramy i używane identyfikatory, a nie to, co zamierzałeś wpisać. Nie zakładaj, że opcja typu tożsamości akceptuje dowolny nie-lokalny adres; najpierw sprawdź udokumentowaną semantykę wydania.

Krok 2: przekieruj UDP 500 i 4500 do urządzenia

Trzecia wartość należy do urządzenia NAT i to jest ta, o której ludzie zapominają sprawdzić. Publiczny punkt końcowy musi przekierowywać UDP 500 i UDP 4500 do FortiGate, ponieważ wykrywanie NAT-T i następujący po nim enkapsulowany ESP zależą od dotarcia tych portów. Ten projekt zakłada mapowanie jeden do jednego; współdzielenie jednego publicznego adresu przez porty między wieloma peerami to inna topologia z innymi ograniczeniami.

Potwierdź przekierowanie zrzutem, a nie nadzieją: diagnose sniffer packet any "udp port 500 or udp port 4500" 4 pokazuje, czy pakiety przychodzą i czy odpowiedzi wychodzą.

Google Cloud VPN dokumentuje NAT jeden do jednego z NAT-T jako obsługiwany układ dla peera za NAT, i to jest ograniczenie, względem którego trzeba projektować, jeśli zdalna strona jest bramą Cloud VPN. Współdzielenie jeden do wielu lub przez porty nie jest tą samą obsługiwaną topologią, i żadne lokalne dostrajanie tożsamości tego nie zmienia. Jeśli zdalna strona jest innym urządzeniem, jej własna dokumentacja określa, co zaakceptuje jako tożsamość i czy toleruje przetłumaczony adres peera. Przeczytaj to przed zmianą lokalnego pola, ponieważ strona lokalna nie może wynegocjować reguły, której strona zdalna nie implementuje.

Krok 3: sprawdź, czego nie rozwiązuje faza 1

Przechodzenie przez NAT podnosi tunel, zgodność tożsamości decyduje, czy peer go zaakceptuje, a routing wewnętrznego prefiksu decyduje, co faktycznie przechodzi. Poprawny lokalny ID nie dostarczy brakującej trasy statycznej ani brakującego selektora ruchu.

Dlatego sprawdzaj warstwami. get vpn ipsec tunnel details pokazuje, czy tunel jest podniesiony i jakie selektory wynegocjowano, a niezgodność między skonfigurowaną zdalną podsiecią a wynegocjowanym selektorem to problem routingu w kostiumie fazy 2. execute vpn ike gateway clear wymusza ponowne negocjacje, więc testujesz bieżącą konfigurację, a nie sesję ustanowioną przed twoją ostatnią zmianą. Następnie wyślij ruch do hosta w zdalnym prefiksie i potwierdź, że liczniki się ruszają, ponieważ tunel, który jest podniesiony i nic nie przepuszcza, wygląda identycznie jak działający, dopóki nie sprawdzisz.

Trzymaj trzy wartości w jednym miejscu w notatkach: lokalny adres, który ma urządzenie, publiczny punkt końcowy prezentowany przez urządzenie NAT i ciąg tożsamości oczekiwany przez peera. Zmieniają się z różnych powodów i w różnym czasie.

Renumeracja urządzenia NAT nie jest powodem, by dotykać local-gw w FortiGate, a zmiana tożsamości nie jest powodem, by cokolwiek renumerować. Mieszanie obu to sposób, w jaki działający tunel jest odbudowywany podczas niezwiązanego okna serwisowego. Przewodnik Cloud VPN dotyczący NAT jest odniesieniem dla obsługiwanej topologii po tamtej stronie.

Test, który to rozstrzyga, jest nudny i szybki: wykonaj zrzut na interfejsie zewnętrznym, potwierdź, że UDP 500 i 4500 przychodzą od peera, potwierdź, że tożsamość w wymianie IKE zgadza się z tym, czego peer miał oczekiwać, a następnie potwierdź, że wynegocjowane selektory obejmują podsieci, na których ci zależy. Jeśli pierwsza kontrola zawiedzie, podejrzanym jest urządzenie NAT. Jeśli druga, to pola tożsamości. Jeśli trzecia, to ani NAT, ani tożsamość nigdy nie były problemem.