Domyślna trasa VPN w tabeli 200 ukrywa twoją trasę LAN

Cztery kontrole oddzielają usterkę tabeli polityk od usterki routingu: która reguła pasowała, którą tabelę ta reguła wskazała, co zawiera ta tabela i która trasa w niej wygrała. Główna tabela nie jest już odpytywana, gdy wcześniejsza tabela zwróci trasę, więc widoczny tam wpis LAN może być nieistotny dla testowanego pakietu. Wykonaj kontrole po kolei, a brakująca trasa pojawi się na trzecim kroku, a nie na czwartym.

Dopasowanie najdłuższego prefiksu odbywa się w obrębie jednej tabeli; nie porównuje tras wszystkich tabel jako jednej listy.

Wyszukiwanie kończy się na pierwszej tabeli, która odpowiada

Weź politykę, w której ruch z podsieci najpierw zagląda do tabeli 200, tabela 200 zawiera trasę domyślną przez tunel, a tabela główna zawiera prefiks LAN. Pakiet do adresu LAN może pasować do tej trasy domyślnej w tabeli 200 i tam się zatrzymać. Ponieważ wyszukiwanie zwróciło trasę, późniejsza reguła tabeli głównej nigdy nie ma szansy zaproponować swojego bardziej szczegółowego wpisu. Wynikiem jest pakiet, który wchodzi do tunelu, podczas gdy całkiem dobra trasa LAN pozostaje nieużywana.

Wcześniejsze reguły i własne wyszukiwanie adresów lokalnych przez maszynę nadal obowiązują, więc test musi używać źródła, znacznika i interfejsu, które niesie rzeczywisty przepływ. Zapytaj czymkolwiek innym, a LAN może zostać wybrany poprawnie, co ukrywa właśnie tę usterkę, której szukasz.

Umieść wyjątek LAN tam, gdzie należy

Wybrana tabela może nieść potrzebne trasy LAN, trasy połączone i trasę do punktu końcowego, co utrzymuje politykę samowystarczalną. Inny projekt używa jawnej wcześniejszej reguły dla prefiksu LAN albo celowej trasy odrzucającej, która przekazuje prefiks późniejszemu wyszukiwaniu. Każdy jest prawidłowym wzorcem z innym właścicielem. Wybieraj według zamierzonej polityki i tego, kto utrzymuje trasy, a nie według tego, która jest krótsza do wpisania.

Jakikolwiek jest wzorzec, wyjątek musi być widoczny tam, gdzie zdefiniowano politykę. Trasa dodana ręcznie i nieodnotowana zniknie przy następnym restarcie i zabierze ze sobą diagnozę.

Nie kopiuj tabeli głównej w całości

Kopiowanie każdej trasy z głównej do tabeli polityk wygląda jak naprawa, ale tworzy migawkę. Administrator może dynamicznie dodawać lub usuwać adresy i interfejsy, a kopia staje się nieaktualna, zanim ktokolwiek to zauważy. Trzymaj cykl życia tras u właściciela konfiguracji i regeneruj tabelę z konfiguracji, a nie z jednego momentu w czasie.

Skopiowana tabela niweczy też cel, ponieważ odtwarza zachowanie zapasowe, które polityka miała ograniczać.

Sprawdzaj odpowiedzi osobno od tras

Gdy wyszukiwanie wybierze zamierzoną ścieżkę, odpowiedzi nadal mogą zawieść z powodów niemających nic wspólnego z tabelą. Translacja może zostać zastosowana na złym interfejsie, walidacja trasy powrotnej może odrzucić pakiet, który przyszedł nieoczekiwaną ścieżką, albo punkt końcowy po prostu nie odpowie. To odrębne usterki z odrębnymi dowodami i żadnej z nich nie naprawia edycja wpisów tras.

Zapisz wyszukiwanie dla dokładnie tego przepływu po obu stronach zmiany, aby poprawka pozostała widoczna. Globalne wyłączenie walidacji trasy powrotnej albo wyczyszczenie reguł nie daje brakującej trasy i osłabia niepowiązane kontrole.

Zapisz regułę, tabelę, zwycięską trasę i ścieżkę odpowiedzi. Ten zapis oddziela błąd polityki od zepsutej usługi.