Rozszerzenie witryny VPN: podążaj trasą powrotną za bramą

Ruch z oddziału kończy się na bramie, której LAN nie zawiera aplikacji, do której mieliście dotrzeć. Serwer znajduje się w drugim centrum danych, za łączem wewnętrznym, którego VPN nigdy nie skonfigurował. Dodanie kolejnego prefiksu do bliskiej bramy niczego w tym przypadku nie zmienia, ponieważ daleka brama jest punktem końcowym szyfrowania, a nie ostatnim routerem. Ścieżka wymaga trasy dalej, dopuszczenia na dalekiej granicy bezpieczeństwa i decyzji o powrocie w samej sieci miejsca docelowego.

Daleka brama jest punktem końcowym szyfrowania

IPsec między bramami chroni ruch między dwoma urządzeniami bezpieczeństwa, a adresy wewnętrzne wędrują przez ten segment zaszyfrowane. Za daleką bramą przejmuje zwykłe trasowanie, łącznie z dowolną polityką istniejącą między centrami danych. Chroniony segment obejmuje więc część podróży, a nie resztę. Zakładanie odwrotności to sposób, w jaki projekt kończy się zdrowym tunelem i nieosiągalną aplikacją.

Narysujcie ścieżkę w trzech częściach: oddział do bliskiej bramy, bliska do dalekiej, daleka brama do aplikacji. Każda część ma swojego właściciela i swój tryb awarii.

Przeczytajcie oba kierunki polityki tunelu

Polityka tunelu jest zwykle pisana z perspektywy strony lokalnej i właśnie z tego nawyku biorą się częściowe konfiguracje. Obie strony muszą wymienić źródło oddziału i miejsce docelowe tak, jak pojawią się wewnątrz tunelu, łącznie z każdym tłumaczeniem, które projekt przewiduje. Aktualizacja tylko bliskiego końca daje niezgodność drugiej fazy, która wygląda jak awaria trasowania. Porównajcie oba zestawy polityk, zanim dotkniecie jakiejkolwiek trasy.

Zapisujcie źródło i miejsce docelowe jako adresy, a nie nazwy witryn. Niejednoznaczność tutaj powróci później jako zastanawiająca asymetria.

Dodajcie trasę dalej i potwierdźcie dopuszczenie

Daleka brama potrzebuje trasy do podsieci aplikacji, a każdy router pomiędzy nimi musi dopuścić źródło oddziału. Sprawdźcie, co daleka brama naprawdę ma, a nie co twierdzi diagram.

ip route get 10.30.5.10 from 10.10.1.50
traceroute -n -s 10.10.1.50 10.30.5.10

Pierwsze polecenie raportuje interfejs wyjściowy i następny skok, które daleka brama wybrałaby dla tego źródła, a to pytanie, na które zwykła tablica trasowania nie potrafi odpowiedzieć. Ślad pokazuje, gdzie zatrzymują się pakiety, a przerwa za daleką bramą wskazuje na tranzyt wewnętrzny, a nie na tunel. Gdy trasa istnieje, a ruch nadal znika, przechwyćcie pakiety na dalekiej bramie i odczytajcie przychodzący adres źródłowy, ponieważ nieoczekiwany adres oznacza, że tłumaczenie odbywa się gdzieś nieplanowanie. Wszystkie adresy tutaj są symbolami zastępczymi, więc zastąpcie je prawdziwymi podsieciami oddziału, tranzytu i aplikacji.

Testujcie z oddziału, a następnie ponownie przetestujcie starą ścieżkę

Akceptacja wymaga prawdziwego źródła, a nie sondy z dalekiej bramy. Uruchomcie kontrolę z hosta w oddziale i zachowajcie wcześniej działające cele w tym samym teście.

curl -sS -m 5 http://10.30.5.10:8080/health
ping -c 3 10.20.1.1

Odpowiedź z aplikacji dowodzi razem drogi w przód i drogi powrotnej, a ping do starego celu dowodzi, że zmiana nie zepsuła tego, co już działało. Przechwyćcie adres źródłowy, który rejestruje aplikacja, ponieważ jej reguły dostępu i każda trasa powrotna muszą odpowiadać tej wartości. Tam, gdzie oddział tłumaczy przed tunelem, adres polityki i adres widziany przez aplikację różnią się z założenia, więc zapiszcie oba. Powtórzcie test po odnowieniu klucza lub zmianie trasowania, ponieważ te ścieżki zwykle są weryfikowane raz, a potem zapominane.

Przypiszcie właściciela każdemu z trzech segmentów oraz trasie powrotnej w sieci miejsca docelowego. Ścieżka z czterema właścicielami zawodzi w lukach między nimi.