Publikowanie usługi wewnętrznej przez VPN typu site-to-site na ASA

Publikowanie usługi, która żyje za VPN typu site-to-site, to jedno zadanie z pięcioma punktami awarii, i zawodzą one w ustalonej kolejności. Tunel wstaje, translacja się zgadza, oddział odpowiada, a odpowiedź wraca tą samą ścieżką. Gdy którykolwiek z nich jest błędny, przeglądarka pokazuje to samo: połączenie, które wisi lub jest resetowane. Przejdź listę od góry do dołu i zatrzymaj się na pierwszej kontroli, która zawiedzie.

Kontrola 1: tunel chroni adres źródłowy

Zacznij od tunelu, który już przepuszcza ruch, a potem potwierdź, że adres, który zamierzasz opublikować, leży w chronionym zakresie. Na ASA ten zakres pochodzi z ACL kryptograficznego albo z tras VTI, i musi obejmować rzeczywisty adres źródła, a nie podsieć, której oddział używa do zarządzania. Selektor, który mija źródło, daje tunel, który stoi, i przepływ, który nigdy do niego nie wchodzi.

Potwierdź to licznikami tunelu i tabelą tras, zanim dotkniesz translacji. Jeśli źródło nie jest osiągalne z koncentratora przez tunel, nic później na tej liście tego nie naprawi.

Zatrzymaj się tutaj, jeśli chroniony zakres i adres źródłowy się nie zgadzają.

Kontrola 2: zdecyduj, które źródło zobaczy oddział

Oddział widzi albo oryginalny adres klienta, albo adres przetłumaczony, i ten wybór decyduje o ścieżce powrotnej. Zachowanie adresu klienta czyta się czyściej w logach źródła, ale wtedy oddział musi odsyłać odpowiedzi dla klientów publicznych przez tunel; zwykła domyślna trasa internetowa wysyła je w drugą stronę i połączenie ginie w jednym kierunku. Translacja źródła na adres, który oddział już trasuje przez tunel, usuwa to wymaganie.

Translacja zmienia też to, co źródło może logować i z czym mogą się zgadzać reguły oparte na źródle. Jeśli aplikacja musi znać osobę stojącą za żądaniem, miejsce na to jest w uwierzytelnionym odwrotnym proxy, a nie w decyzji NAT.

Kontrola 3: pisz translację pod rzeczywiste interfejsy

ASA ocenia reguły translacji po kolei i zgłasza, która pasowała, więc para interfejsów w regule nie jest kosmetyczna. Reguła napisana dla ścieżki z zewnątrz do wewnątrz nie pasuje do przepływu, którego wejście i wyjście różnią się od założonych.

Ścieżka, którą budujesz, ma cztery odcinki, i wszystkie cztery muszą się zgadzać:

Traktuj zakresy w tej tabeli jako miejsca zastępcze. Liczy się to, że krotka po translacji jest adresem, który oddział akceptuje przez tunel, i że odwrotne mapowanie istnieje w stanie NAT, dzięki czemu odpowiedź jest odtwarzana na wyjściu.

Kontrola 4: ogranicz regułę dostępu do opublikowanego portu

Publikuj port, nie host. Reguła, która zezwala źródłu na każdej usłudze, zamienia jedną opublikowaną aplikację w ścieżkę do wszystkiego, co uruchamia źródło, łącznie z interfejsem zarządzania, który celowo trzymałeś poza internetem. Zezwól na opublikowany port od przetłumaczonego źródła do źródła, a usługi administracyjne zostaw na ich ścieżce tylko przez VPN.

Sprawdź jednocześnie kolejność reguł. Szerokie zezwolenie nad twoją konkretną regułą czyni konkretną regułę niewidoczną.

Kontrola 5: prześledź jedno żądanie i jego odpowiedź

Nie zaczynaj od przeglądarki, bo przeglądarka ukrywa, który odcinek zawiódł. Prześledź przepływ na koncentratorze i przeczytaj wynik, zanim cokolwiek zmienisz.

packet-tracer input outside tcp 198.51.100.25 50000 203.0.113.20 443 detailed
show nat detail
show xlate
show vpn-sessiondb l2l

Ślad wskazuje pasującą translację, regułę dostępu, która przepływ przepuściła lub odrzuciła, oraz to, czy pakiet został skierowany do tunelu. Jeśli pokazuje przepływ wychodzący interfejsem, którego się nie spodziewałeś, para interfejsów w regule NAT jest błędna. Jeśli pokazuje odmowę, kolejność reguł jest błędna. Jeśli dociera do tunelu, ale źródło nigdy nie odpowiada, problemem jest ścieżka powrotna oddziału.

Następnie wyślij jedno prawdziwe żądanie z zewnątrz i potwierdź, że odpowiedź wraca tym samym tunelem. Zapisz opublikowany wpis, translację, chronioną parę adresów i trasę powrotną jako rekord publikacji.