Ping z bramy IPsec używa innego adresu źródłowego

Wyślij ping na drugą stronę z bramy IPsec, nie otrzymaj odpowiedzi i uznaj, że tunel jest zepsuty, chociaż każde obciążenie za bramą normalnie przepuszcza ruch. Te dwa wyniki nie są sprzeczne. Ping uruchomiony na bramie to pakiet z lokalnym źródłem, a brama wybiera adres źródłowy z własnej tablicy routingu. Ten wybór może różnić się od adresów używanych przez rzeczywisty ruch witryny, co zmienia, która polityka pasuje i która trasa powrotna obowiązuje. Zdecyduj, co test ma dowieść, zanim wyciągniesz cokolwiek z jego wyniku.

Trzy różne pytania, na które ping może odpowiedzieć

Pierwsze pytanie brzmi, czy druga strona jest w ogóle osiągalna z tego hosta. Drugie, czy selektory tunelu lub polityka oparta na trasach przepuszczają ruch z określonego źródła. Trzecie, czy ruch przekazywany z obciążenia za bramą działa od końca do końca. Jedno polecenie nie odpowie na wszystkie trzy, a adres źródłowy jest tym, co je rozdziela.

Najpierw wybierz pytanie. Inaczej nieudany ping staje się dowodem na teorię, którą już miałeś.

Dlaczego brama wybiera adres, którego się nie spodziewałeś

Gdy pingujesz cel, lokalny stos wybiera źródło z trasy, która do niego pasuje. W tunelu opartym na trasach może to być adres łącza interfejsu tunelu, który w wielu projektach witryny jest parą 169.254.x.x wybraną dla przeskoku punkt-punkt. Te adresy istnieją, aby łącze działało; po drugiej stronie nie są ogłaszane jako sieci źródłowe aplikacji.

Druga strona może więc otrzymać żądanie echa z adresu, do którego nie ma trasy powrotnej, albo z takiego, do którego nie pasuje żaden selektor. Tunel może być zdrowy, a ping mimo to zawieść, i to jest dokładnie ten fałszywie negatywny wynik, o którym jest ten artykuł.

Wybierz źródło świadomie

Na kontrolowanej bramie Linux wybierz źródło, które jest już przypisane lokalnie: ping -c 4 -I 10.30.0.1 10.40.0.20. Adresy tutaj są przykładowe, więc zastąp je rzeczywistym wewnętrznym adresem bramy i rzeczywistym celem zdalnym, i potwierdź, że wybrane źródło należy do tego urządzenia i jest dopuszczane przez politykę witryny.

Nie pożyczaj adresu obciążenia do testu. Podszywanie się pod hosta, który nie jest przypisany do bramy, tworzy wynik, którego nikt nie może powtórzyć, a na niektórych stosach zawodzi w sposób, który wygląda jak usterka tunelu.

Czytaj trasę powrotną, nie tylko żądanie

Sprawdź, które źródło faktycznie dociera do celu zdalnego, łącznie z ewentualnym celowym tłumaczeniem po drodze. Następnie sprawdź trasę powrotną drugiej strony do tego źródła oraz selektory lub politykę, które ją dopuszczają. Żądanie, które dociera z nieoczekiwanym źródłem, jest kwestią routingu i polityki, a nie kryptografii.

Tutaj również przechwycenie pakietów pomaga bardziej niż kolejny ping: pokazuje źródło, które widziała druga strona, a to jest adres, do którego musi dotrzeć jej odpowiedź.

Następnie przetestuj obciążenie

Decydujący test to ping ze zwykłego hosta za bramą do zwykłego hosta za zdalną bramą. Ćwiczy on rolę przekazywania bramy, rzeczywiste źródło aplikacji i prawdziwą trasę powrotną, a to jest przepływ, na którym zależy użytkownikom.

Trzymaj wyniki osobno w notatkach: osiągalność z bramy, dopuszczenie przez politykę dla wybranego źródła i ruch przekazywany. Udany przypięty ping jest użytecznym dowodem, że tunel coś przenosi; nie jest dowodem, że każdy przekazywany przepływ działa. A automatycznie wybrane źródło bramy, do którego nie można dotrzeć, nie jest dowodem, że tunel witryny jest wyłączony.

Nie dodawaj ogólnej trasy dla 169.254.0.0/16 tylko po to, aby uzyskać jedną odpowiedź diagnostyczną. To wymienia mylący test na trwałą decyzję routingu, a następna osoba dziedziczy ją bez kontekstu.