Cisco, VPN i debugowanie
Tym razem będzie o routerach…
Mam w firmie pudełko, które odpowiada wyłącznie za terminowanie tuneli VPN do klientów. Nic nadzwyczajnego, ot „czarna skrzynka”, która robi swoje i się nie psuje. Ale czasami zdarza się tak, że jakiś tunel przestaje nagle działać, sam się nie umie zestawić ponownie, a „druga strona” twierdzi, że nic nie dotykała i nic nie wie. Najprostszą i najbardziej podstawową metodą diagnozowania takich problemów jest włączenie na routerze debuga (debug crypto ipsec/isakmp) i oglądanie co się dzieje podczas próby podniesienia tunelu. Problem w tym, że tuneli jest wiele, a ja tylko jeden i od ilości danych, które przelatują nagle przez ekran można dostać oczopląsu. Szczęśliwie Cisco udostępnia bardzo fajną komendę: debug crypto condition peer ipv4 A.B.C.D. Nie robi ona chyba nic więcej, jak tylko ogranicza ilość zbieranych i wyświetlanych przez router informacji do jednego tylko peer’a. I jest to dokładnie to, o co mi chodzi – na monitorze widzę, jak routerki gadają ze sobą i próbują wynegocjować jakieś wartości, które byłby dla obu akceptowalne, a jednocześnie nie muszę oglądać tony innych, w danej chwili zupełnie mi niepotrzebnych rzeczy.
Aha, takie ograniczenie wyłącza się następująco: „debug crypto condition reset”.