Dlaczego Twoja reguła split tunnel przestała pasować do usługi

Split tunneling zwykle zawodzi na jeden z dwóch sposobów. Albo ruch, który powinien być wewnątrz tunelu, omija go, albo ruch, który powinien zostać na zewnątrz, jest wciągany do środka. Awaria z powodu nieaktualnej reguły to pierwszy przypadek, i jest ona bardziej myląca, ponieważ reguła jest egzekwowana dokładnie tak, jak została zapisana. Zmieniło się miejsce docelowe: usługa odpowiada teraz na adresie, którego reguła nigdy nie wskazała, a w tunelu nic nie jest nie tak.

Co ustala reguła i co zwraca DNS

Reguła split tunnel to statyczne stwierdzenie o miejscach docelowych, zwykle wyrażone jako prefiks, trasa lub lista adresów. Jest oceniana wobec miejsca docelowego pakietu w chwili wysyłania. Nazwa hosta to zapytanie, które zwraca zbiór adresów z czasem życia i pamięcią podręczną, a odpowiedź może się różnić w zależności od resolvera, typu zapytania i minuty.

Te dwa obiekty nigdy ze sobą nie negocjują. Reguła nadal pasuje do prefiksu, który otrzymała, usługa nadal zmienia adres, który wydaje, a luka między nimi po cichu się powiększa. Dlatego objaw pojawia się po migracji dostawcy lub odnowieniu certyfikatu, a nie po zmianie konfiguracji. Nikt nie edytował tunelu, więc nikt nie patrzy na tunel, a diagnoza dryfuje w stronę aplikacji zamiast polityki.

Trzy sposoby, na jakie dopasowanie się psuje

Oczywisty przypadek to przeniesiona usługa: operator dał jej nowy adres, DNS podążył, a wyjątek nie. Drugi to rodzina adresów, której reguła nigdy nie objęła, co zdarza się, gdy nazwa zaczyna zwracać rekordy AAAA, które wyjątek tylko dla IPv4 ignoruje. Trzeci to różnica resolvera: widok wewnętrzny i publiczny mogą zwracać różne adresy dla tej samej nazwy, więc adres używany przez Twoją aplikację nie jest tym, którym testowałeś.

Buforowane połączenie to czwarty wariant i łatwo je przeoczyć. Aplikacja może nadal rozmawiać z adresem, który rozwiązała godzinę temu, co oznacza, że Twoje świeże zapytanie i jej otwarty socket nie zgadzają się co do tego, gdzie mieszka usługa.

Odczytaj miejsce docelowe, którego aplikacja naprawdę używa

Zapytaj system operacyjny i tabelę socketów, nie kartę przeglądarki. Zapytanie odpowiada, na co nazwa rozwiązuje się teraz, a tabela socketów pokazuje adres, z którym proces jest połączony, który może być starszy. Uruchom oba przed sformułowaniem teorii, ponieważ różnica między nimi sama w sobie jest odpowiedzią w około połowie przypadków.

getent ahosts api.example.com
dig +short api.example.com A
dig +short api.example.com AAAA
ss -tnp | grep -F api
ip route get 203.0.113.40

Następnie porównaj z tym, co obejmuje reguła. Jeśli bieżący adres wypada poza wyjątkiem, a żądanie nadal zawodzi, znalazłeś przyczynę bez dotykania konfiguracji tunelu. Jeśli aplikacja jest połączona z adresem zgodnym z regułą, a żądanie nadal zawodzi, problem jest gdzieś za tunelem i to jest niewłaściwe dochodzenie.

Napraw mechanizm, nie objaw

Jeśli produkt obsługuje utrzymywane kierowanie oparte na domenach, użyj go i postępuj zgodnie z jego udokumentowanym zachowaniem odświeżania i zakresu. To zastępuje statyczne przypuszczenie utrzymywaną odpowiedzią, za cenę zależności od tego, że funkcja działa zgodnie z dokumentacją.

Jeśli projekt opiera się na statycznej liście, daj jej właściciela i plan aktualizacji. Plan powinien mówić, jak adres jest wykrywany, kto zatwierdza zmianę i jak szybko lista ma podążać za migracją dostawcy. Lista bez właściciela to przyszła awaria o znanej przyczynie.

Nie rozszerzaj wyjątku na dużą sąsiednią sieć tylko po to, aby złapać każdy adres, który widziałeś podczas krótkiego testu. To nie naprawa; to trwała zmiana granicy bezpieczeństwa, i po cichu pozwoli niepowiązanym usługom omijać tunel tak długo, jak długo istnieje reguła.

Zweryfikuj obie połowy intencji

Projekt split tunnel ma dwie intencje, a naprawa powinna zachować obie. Chroniona usługa musi przechodzić przez tunel, a wykluczone kategorie muszą dalej go omijać. Przetestuj świeże połączenie z naprawionym miejscem docelowym, a potem przetestuj coś, co powinno zostać na zewnątrz.

curl -sv --max-time 5 https://api.example.com/ -o /dev/null 2>&1 | grep -E 'Trying|Connected to'
curl -sS --max-time 5 https://public.example/ -o /dev/null -w '%{http_code}\n'

Zapisz nowy adres, wybrany mechanizm i datę. To właśnie ta notatka powstrzymuje następną osobę przed wnioskiem, że VPN losowo zignorował własną konfigurację.