Przekaźnik DHCP na ASA przez VPN typu site-to-site: przewodnik krok po kroku

Przekaźnik działa w trzech etapach i tylko środkowy przecina VPN. Klient rozgłasza w segmencie oddziału, ASA zamienia to rozgłoszenie na żądanie unicast do serwera DHCP, a serwer odpowiada na adres przekaźnika, a nie na adres klienta. Przejdź etapy w tej kolejności, a większość przypadków „przekaźnik jest zepsuty” sprowadza się do brakującej polityki lub źle odczytanej linii setroute.

Etap pierwszy: włącz przekaźnik na interfejsie zwróconym do klientów

Na ASA oddziału przekaźnik jest właściwością interfejsu patrzącego w stronę klientów. Serwer można zadeklarować globalnie z jego osiągalnym interfejsem albo pod tym interfejsem klienckim, aby tablica routingu wybrała wyjście. Te dwie formy nie są wymienne, a skopiowanie niewłaściwej to pierwsze miejsce, w którym przewodnik zbacza.

Przed zmianą czegokolwiek sprawdź bieżącą konfigurację: który interfejs ma włączony przekaźnik, która forma serwera jest obecna i czy setroute jest przypisany do interfejsu klienta. Jeśli ASA uruchamia też serwer DHCP dla innego segmentu, zatrzymaj się i przeczytaj listę ograniczeń; serwera i przekaźnika nie można włączyć jednocześnie na tym samym urządzeniu.

Przekaźnik wpisuje własny adres kliencki w pole adresu bramy. Na ten adres odpowie serwer, więc musi być osiągalny z odległej lokalizacji przez tunel, nie tylko lokalnie.

Etap drugi: przeprowadź ruch generowany przez ASA przez tunel

To krok, który ludzie pomijają. VPN typu site-to-site oparty na politykach buduje się zwykle dla ruchu między podsieciami, a żądanie przekaźnika generuje sama ASA. Jeśli lista dostępu tunelu i mapa kryptograficzna pasują tylko do przepływów od hosta oddziału do podsieci serwera, pakiet przekaźnika może nigdy nie wejść do tunelu. Sprawdź listę dostępu w obu kierunkach, nie tylko wiersz od oddziału do serwera.

Potwierdź, że ruch istotny obejmuje źródło przekaźnika ASA i adres serwera oraz że kierunek powrotny też jest dozwolony. W projekcie opartym na VTI decyzja routingu jest prostsza, ale obsługa przekaźnika przez VTI pojawiła się w konkretnym wydaniu; przewodnik DHCP firmy ASA wskazuje wersję 9.14(1), więc sprawdź obraz przed skopiowaniem przykładu VTI na starsze urządzenie.

Ping z ASA do serwera sam niewiele dowodzi. Może się udać inną drogą, z innego adresu źródłowego albo w ramach polityki, której pakiety przekaźnika nie spełniają.

Etap trzeci: odczytaj odpowiedź i opcję setroute

RFC 2131 mówi, że serwer wysyła odpowiedź na adres w polu giaddr, gdy to pole nie jest zerowe. Zatem ścieżka powrotna musi być routowana do adresu przekaźnika, a polityka tunelu musi zezwalać na kierunek od serwera do przekaźnika. Jeśli żądanie przeszło, ale oferta nigdy nie dociera, tu trzeba zajrzeć.

Następnie oddziel dwie rzeczy, które brzmią podobnie. Słowo kluczowe setroute zmienia lub dodaje opcję domyślnego routera, którą ASA przekazuje klientowi. Nie instaluje trasy na ASA i nie tworzy polityki VPN. Klient, który dostaje adres, ale do niczego nie dociera, często ma problem z setroute lub z zakresem, a nie z tunelem. Sprawdź to klientem bez statycznej bramy i zobacz, który domyślny router pojawia się w ofercie.

Przeczytaj ofertę od początku do końca: oferowany adres, maska, domyślny router, DNS i czas dzierżawy. Potem pozwól dzierżawie się odnowić. Przekaźnik, który działa raz i zawodzi przy odnowieniu, zwykle ma problem z zakresem, dzierżawą lub ścieżką powrotną, który ukryła pierwsza wymiana.

Co sprawdzam, zanim uznam to za naprawione

Zacznij od klienta i przechwyć rozgłoszenie, potem potwierdź, że ASA przekazała je z własnym adresem jako giaddr. Po stronie odległej potwierdź, że serwer widział to żądanie i wybrał zakres pasujący do oddziału. Po powrocie do oddziału potwierdź, że klient przyjął ofertę i dociera do swojej bramy.

Jeśli któryś etap milczy, sprawdź odpowiednią politykę lub trasę, zamiast dodawać kolejne polecenie przekaźnika. Konfiguracja przekaźnika jest zwykle już poprawna, gdy ktoś eskaluje; zmieniła się polityka tunelu albo trasa powrotna.

Zapisz trzy etapy w rejestrze zmian: interfejs kliencki, polityka VPN obejmująca ruch przekaźnika i trasa powrotna serwera do giaddr. To ten zapis czyni kolejną budowę oddziału powtarzalną pracą, a nie sesją debugowania. Mówi też następnemu inżynierowi, które wyjście polecenia zebrać najpierw.