Tryb promiscuous na adapterze VPN zabija połączenie
Przechwytywanie na adapterze tunelu może zatrzymać jego przekazywanie. Wyłącz tryb promiscuous, wybierz warstwę, która odpowiada na pytanie, i traktuj plik jak tajemnicę.
Wireshark zachowuje się bezbłędnie na interfejsie Ethernet, a potem, na adapterze VPN, tunel przestaje przepuszczać ruch w chwili, gdy rozpoczyna się przechwytywanie. Okno przechwytywania nadal się zapełnia, więc narzędzie wygląda zdrowo, podczas gdy połączenie pod nim umiera. Tryb promiscuous jest zwykłą przyczyną, ponieważ sterownik tunelu, od którego żąda się każdej ramki w segmencie, którego nie ma, może trafić w stan, w którym nic nie wychodzi.
Najpierw wyłącz tę opcję, a potem zdecyduj, którą warstwę naprawdę musisz zobaczyć.
Dwa adaptery, dwa różne widoki
Klient VPN zwykle przedstawia dwa interfejsy: fizyczny, który przenosi zaszyfrowany transport, oraz wirtualny, który przenosi odszyfrowany ruch wewnętrzny. Odpowiadają na różne pytania. Przechwytywanie fizyczne pokazuje punkty końcowe, porty i rozmiary pakietów, a wirtualne pokazuje protokoły aplikacji tak, jak dostarcza je tunel. Wybór jednego bez wiedzy, jakie pytanie stawiasz, marnuje przechwytywanie.
Żaden widok nie jest nadzbiorem drugiego, a jedno przechwytywanie rzadko odpowiada na oba pytania naraz.
Wybieraj interfejs według pytania, a nie według kolejności na liście, ponieważ klient w stylu PPP może przedstawić swój adapter jako urządzenie Ethernet, a wyświetlana nazwa nie powie ci, którą warstwę wybrałeś. Przechwytywanie na bramie lub porcie lustrzanym dodaje trzeci widok, który pokazuje ścieżkę po przekazaniu, i właśnie tam routing asymetryczny i filtrowanie stają się widoczne.
| Capture point | What it shows | What it cannot show |
|---|---|---|
| Physical interface | Outer endpoints, ports, packet sizes | Any inner payload |
| Tunnel interface | Decrypted inner traffic | What the VPN added around it |
| Gateway or mirror | Forwarded path after the tunnel | The client's own decision process |
Dlaczego tryb promiscuous psuje adapter tunelu
Tryb promiscuous prosi sterownik o dostarczanie ramek, które nie są adresowane do hosta, co ma sens w współdzielonym segmencie Ethernet i bardzo mało sensu w tunelu punkt-do-punkt. Niektóre sterowniki przyjmują żądanie spokojnie; inne przestają wyjmować z kolejki ruch wysyłany, a interfejs po cichu staje się czarną dziurą. Przechwytywanie nadal zapisuje to, co przychodzi, więc plik wygląda jak dowód działającego łącza. Właśnie ta luka między tym, co pokazuje plik, a tym, co zrobił interfejs, jest całą pułapką.
Wyłącz opcję przed pierwszym pakietem, utrzymuj wąski filtr przechwytywania i używaj małego bufora. Duży bufor pierścieniowy na zajętym interfejsie gubi właśnie te ramki, które miały znaczenie, co daje przechwytywanie kompletne wszędzie poza miejscem, w którym była usterka.
Jeśli łącze zatnie się w połowie przechwytywania, zatrzymaj je i obserwuj odzyskiwanie. Ta jedna obserwacja oddziela efekt uboczny przechwytywania od prawdziwej usterki tunelu i zajmuje mniej czasu niż jakiekolwiek dostrajanie filtrów.
Jak uczynić przechwytywanie IPsec czytelnym
Przechwytywanie IPsec samo w sobie nie jest czytelne, ponieważ ESP szyfruje ładunek. Wireshark może je zdekodować, gdy podasz klucze sesji, albo gdy może śledzić negocjację IKE, która je wytworzyła, co oznacza, że uścisk dłoni musi znajdować się w tym samym pliku.
Klucze wygasają. Po odnowieniu kluczy przez strony zestaw starych kluczy przestaje działać w połowie przechwytywania, a wynik wygląda na błąd dekodera, a nie na granicę czasową.
Trzymaj się udokumentowanego formatu kluczy producenta, zamiast importować materiał z niepowiązanego źródła, i licz się z tym, że niektóre platformy całkowicie odrzucą ten sposób pracy. Gdy brama nie wydaje kluczy ani nie pozwala na przechwytywanie, zaakceptuj, że ładunku nie da się zbadać z twojego miejsca. Dzienniki punktów końcowych i liczniki interfejsu to pozostałe dowody i zwykle wystarczają do pytania o routing.
Przechwytywanie, którym możesz bezpiecznie się podzielić
Przechwytywanie wewnętrzne jest bliższe zrzutowi danych logowania niż logowi. Może zawierać nazwy, adresy i tekst jawny z protokołów pisanych przy założeniu, że nikt nigdy ich nie przeczyta, co czyni plik samym w sobie wrażliwym artefaktem, a nie analizę.
Upewnij się, że host i sieć są takie, na których wolno ci przechwytywać, zanotuj zarówno interfejs, jak i filtr razem z wynikiem, ogranicz sesję do kilku minut, które odpowiadają na pytanie, i usuń plik po zakończeniu. Jeśli trzeba go udostępnić, najpierw opisz przepływ lub usuń ładunek.
Następnie powtórz pierwotne zadanie użytkownika. Przechwytywanie dowodzące, że pakiet dotarł, nie jest dowodem, że aplikacja przyjęła odpowiedź, a różnica między tymi dwoma rzeczami jest zwykle tam, gdzie leży prawdziwa usterka.