Który VRF dociera do peera VPN, a który niesie pakiet?

Każdy tunel wewnątrz kontekstu routingu klienta nadal musi dotrzeć do swojego zdalnego peera, a to wyszukiwanie może odbywać się w zupełnie innej tabeli. Błąd tutaj daje jedną z najbardziej mylących awarii w IPsec świadomym VRF: tunel się podnosi, trasy wydają się istnieć, a ruch ginie, ponieważ jedno z dwóch wyszukiwań użyło niewłaściwego kontekstu. Wykonaj cztery kroki poniżej po kolei i zapisz oba cele osobno.

Dwa wyszukiwania, jeden tunel

Zewnętrzny pakiet w kapsule jest adresowany do adresu transportowego peera i jest routowany, zanim istnieje jakakolwiek ochrona. Wewnętrzny pakiet jest adresowany do serwera klienta i jest routowany po dekapsulacji, wewnątrz kontekstu klienta. To dwa cele, dwa wyszukiwania i często dwie różne tabele.

Dokumentacja Cisco dla IPsec świadomego VRF nazywa je VRF przednich drzwi i VRF wewnętrznym. Przednie drzwi niosą zaszyfrowany transport, a kontekst wewnętrzny niesie chroniony ruch. Nic w nazwaniu tunelu po kliencie nie sprawia, że któraś z tras się pojawia.

Zanim zmienisz konfigurację, wypisz cztery fakty: adres transportowy peera i kontekst, który do niego dociera, następnie prefiks serwera i kontekst, który do niego dociera. Jeśli nie potrafisz wypełnić wszystkich czterech, zaraz zaczniesz zgadywać. Zgadywanie w tej dziedzinie jest kosztowne, bo trasa dodana do niewłaściwej tabeli może sprawić, że jeden przepływ zadziała, a inny po cichu się zepsuje. Zebranie czterech faktów zajmuje dziesięć minut i oszczędza dzień analizy przechwyconego ruchu.

Potwierdź wyszukiwanie transportowe peera

Zacznij od przednich drzwi, bo tunel, który nie dociera do peera, nigdy nie przepuści ani jednego chronionego pakietu. W IOS pytaj o trasę do peera wewnątrz VRF transportowego, a nie w tabeli globalnej.

show ip route vrf wan-blue 203.0.113.20
show ip vrf brief
show crypto ikev2 sa

Pierwsze polecenie odpowiada, czy adres peera jest osiągalny w tym kontekście, drugie wymienia VRF, które naprawdę istnieją, a trzecie pokazuje, czy powstało stowarzyszenie bezpieczeństwa. Adres peera rozwiązywany tylko w tabeli globalnej to klasyczny błąd przednich drzwi i objawia się jako negocjacja IKE, która nigdy się nie zaczyna.

Sprawdź także przypisanie interfejsu. Udokumentowane zachowanie wymaga, aby VRF przednich drzwi tunelu i VRF interfejsu WAN były zgodne; niezgodność może pozwolić pakietowi wyjść, a mimo to uniemożliwić przetworzenie odpowiedzi we właściwym kontekście.

Potwierdź wyszukiwanie wewnętrzne serwera

Gdy przednie drzwi są udowodnione, przejdź do kontekstu klienta i zadaj to samo pytanie o prefiks serwera. To wyszukiwanie decyduje, czy zdekapsulowany pakiet można przekazać dalej.

show ip route vrf customer-blue 10.60.4.0
show crypto session detail

Pierwsze polecenie pokazuje trasę wewnętrzną, a drugie stan sesji wraz z kontekstami, które platforma z nią powiązała. Jeśli trasa istnieje, ale szczegóły sesji wskazują niewłaściwy kontekst wewnętrzny, tunel przekazuje do tabeli, która nie zna prefiksu klienta.

Trasa w tabeli globalnej nie jest dowodem dla żadnego z dwóch wyszukiwań. Trasy globalne są używane, gdy pakiet nie jest powiązany z VRF, a interfejs tunelu przypisany do kontekstu klienta zmienia to powiązanie. Jeśli brakuje trasy wewnętrznej, pakiet jest dekapsulowany, a następnie odrzucany z powodu braku wpisu przekazywania, co wygląda na utratę pakietów, a nie na błąd routingu.

Umieść ustawienie tam, gdzie model go oczekuje

Ta sama dokumentacja rozróżnia modele konfiguracji, a ustawienie należące do jednego nie musi należeć do drugiego. W interfejsach tunelu korzystających z ochrony tunelu wewnętrzny VRF jest definiowany na interfejsie tunelu. W rozwiązaniach opartych na crypto map wewnętrzny VRF jest częścią wpisu crypto map. Przenoszenie podobnie nazwanego polecenia między modelami bez sprawdzenia jego roli to sposób, w jaki działający projekt staje się niestabilny.

Routing i tożsamość to odrębne sprawy. Osiągalność nigdy nie zastępuje profilu peera, który urządzenie zaakceptuje, a zmiana nazwy VRF nie może zmieniać oferowanych poświadczeń. Sprawdzaj oba po każdej zmianie, bo tunel negocjujący z niewłaściwym profilem nadal może utworzyć stowarzyszenie i niczego nie przekazać.

Na koniec zapisz cztery fakty i polecenia, które je udowodniły, w rejestrze zmian. Następny inżynier odziedziczy tunel, a nie rozumowanie, a krótka notatka nazywająca oba konteksty jest warta więcej niż diagram, którego nikt nie aktualizuje.