Tożsamość IKE czy adres punktu końcowego: nie mieszaj ich
Tożsamość IKE typu FQDN to dosłowna wartość uwierzytelniania, a nie odwrotne wyszukiwanie DNS. Trzymaj osobno adres punktu końcowego, tożsamość lokalną i oczekiwanego peera.
Czytaj pole oznaczone jako tożsamość FQDN jako dosłowny ciąg znaków, a nie jako żądanie odwrotnej nazwy DNS twojego publicznego adresu. W parserze strongSwan to jest dokładnie to, ciąg znaków, i odczyt nigdy nie rozwiązuje go na punkt końcowy. Sam ten fakt usuwa najczęstszą rozpraszającą rzecz, gdy wybierasz identyfikatory dla peera. Poniższe kontrole nie pozwalają trzem zaangażowanym wartościom zlać się w jedną.
Etykieta to nie wyszukiwanie
Interfejsy dostawców używają słów takich jak FQDN i hostname swobodnie, a etykieta na pudełku nic nie mówi o kodowaniu za nią. Urządzenie, które nazywa pole Client FQDN, może wysłać FQDN, ciąg w formie adresu e-mail lub goły adres. Traktuj tekst i typ jako dwie osobne decyzje i zapisz obie.
Nic w dosłownej tożsamości nie wymaga DNS. To twierdzenie, które sprawdza druga strona, a nie nazwa, którą sieć musi rozwiązać.
Trzy osobne wartości, zapisane osobno
Za jednym ekranem konfiguracji stoją trzy zadania, a ich scalenie to kosztowny błąd. Jedna wartość to adres punktu końcowego, który decyduje, dokąd trafiają pakiety. Inna to tożsamość lokalna, którą przedstawia ten peer, a trzecia to tożsamość, której oczekujesz od drugiego końca, zanim go uwierzytelnisz. Zapisz je jako trzy wiersze w bilecie zmiany, bo cokolwiek mniej opisuje VPN, a nie relację.
| Job | Example | What it decides |
|---|---|---|
| Where the packets go | 198.51.100.7 | The endpoint address |
| What this peer claims | gw.branch.internal | The local IKE identity |
| Who should answer | ike.hub.internal | The expected remote identity |
Przykładowe tożsamości trzeba wybrać i autoryzować jako część wdrożenia. To twierdzenia, które weryfikuje uwierzytelnianie, a nie poświadczenia czyniące dowolnego peera godnym zaufania, więc wiarygodnie wyglądający ciąg niczego nie autoryzuje.
Typ jest częścią wartości
odnośnik do tożsamości strongSwan rozdziela FQDN, wartości w formie adresu e-mail, adresy IP i inne kodowania, więc kodowanie liczy się tak samo jak znaki. Dwa urządzenia mogą zaakceptować ten sam tekst pod różnymi typami i nadal się wzajemnie odrzucać. Notatka zapisująca wartość bez jej typu to połowa konfiguracji.
Zapytaj dostawcę, jaki typ urządzenie faktycznie wysyła, i potwierdź to dekodowaniem, a nie etykietą interfejsu. Zgadnięty typ to niezgodność czekająca na następną zmianę.
Każda strona musi zadowolić drugą
Lokalna tożsamość każdej strony musi przejść politykę uwierzytelniania drugiej strony. To nie to samo co wklejenie jednego ciągu w każde pole tożsamości na obu urządzeniach, czyli skrót, który daje konfigurację, której nikt nie potrafi odpluskwić.
Uwierzytelnianie certyfikatem dodaje własne wymagania, bo tożsamość certyfikatu i warunki zaufania stoją obok wpisanej tożsamości IKE. Sama zgodność tożsamości IKE nie autoryzuje peera z certyfikatem.
Gdzie DNS ma znaczenie i co wymusza twoja wersja
Nazwa hosta bramy używana do wykrywania naprawdę wymaga działającego DNS, a to wymaganie należy do znalezienia punktu końcowego, a nie do jakiegokolwiek odwrotnego wyszukiwania wpisanej tożsamości. Trzymaj oba osobno w bilecie, bo awaria wykrywania i niezgodność tożsamości czytają się podobnie w logu klienta i są naprawiane w różnych miejscach.
Przeczytaj parser produktu i wersji, którą naprawdę uruchamiasz, zanim skopiujesz składnię wymuszającą typ, ponieważ starsze wydania strongSwan zachowywały się inaczej, a inni dostawcy dodają własne ograniczenia. Porównując oba końce, trzymaj razem cztery rzeczy: oczekiwaną tożsamość, przedstawioną tożsamość, typ i błąd uwierzytelniania. Ten zestaw zamienia niezgodność w dowód, a nie w opinię.