Nowe połączenia na nowym wyjściu VPN, stare przepływy zostają w spokoju

Zaplanowane osuszenie przenosi tylko nieklasyfikowane przepływy. Porównaj to z podmianą trasy i zobacz znaczniki, tabele i stan conntrack, które to utrzymują.

Dwa zdrowe wyjścia VPN, jedno długie wysyłanie już trwa i wymóg, by następne połączenie korzystało z drugiego tunelu. Są dwa sposoby, by to spełnić, i tylko jeden jest bezpieczny na działającej bramie. Podmiana trasy domyślnej przenosi każdy pakiet, także te należące do wysyłania. Zaplanowane osuszenie zmienia wybór dla nowych połączeń, a śledzone przepływy zostawia na ścieżce, na której się zaczęły.

Dwa sposoby przełączenia wyjścia

Podmiana trasy to jedno polecenie i można ją cofnąć w kilka sekund, dlatego używa się jej podczas incydentów. Jest też bezrozróżnieniowa: pakiety istniejącego wysyłania nagle wychodzą innym tunelem, z innym publicznym adresem źródłowym i osobnym stanem translacji.

Jeśli zdalny koniec śledzi przepływy po adresie źródłowym, wysyłanie może po prostu przestać być rozpoznawane. Osuszenie unika tego, podejmując decyzję raz na połączenie i zapisując ją, dzięki czemu stare wysyłanie zachowuje swoje wyjście do końca. To cała wartość ćwiczenia: zdalny koniec nie widzi żadnej zmiany, którą musiałby interpretować. Nadal otrzymuje pakiety pasujące do połączenia, które już zna.

Kosztem jest złożoność: dwie tabele routingu, klasyfikator działający na właściwym hooku i znaczniki, które trzeba skoordynować ze wszystkim innym na maszynie, co ich używa.

Daj każdemu wyjściu własną tabelę

Zarezerwuj tabelę routingu dla każdego wyjścia i odrębne wartości znacznika lub bity dla obu opcji. Każda tabela potrzebuje tras odpowiednich do swojej roli, nie tylko nazwy, i potrzebuje celowego wyniku awarii dla brakującego przypadku. Pusta tabela, która po cichu wpada do tabeli głównej — tak ruch opuszcza wyjście, którego nikt nie wybrał.

ip rule add fwmark 0x10/0x10 table 101
ip rule add fwmark 0x20/0x20 table 102
ip route add default via 192.0.2.1 dev wg-a table 101
ip route add default via 198.51.100.1 dev wg-b table 102

Dodaj trasę blackhole na końcu każdej tabeli, aby wyszukiwanie bez dopasowania głośno zawodziło zamiast uciekać do domyślnego, którego nie wybrałeś.

Wybierz raz, przy pierwszym pakiecie

Klasyfikuj po powstaniu śledzenia połączeń i przed tym wyszukiwaniem trasy, które ma znaczenie. Dla nowego, nieklasyfikowanego połączenia LAN wybierz wyjście i zapisz je w stanie połączenia. W kolejnych pakietach przywróć zapisaną wartość do znacznika pakietu, który czyta routing polityki.

Subtelna część to znaczenie słowa nowy. Conntrack nadal może zgłaszać NEW dla wczesnych pakietów i retransmisji, zanim zobaczy odpowiedź, więc klasyfikator opierający się tylko na tym stanie może nadpisać już podjęty wybór. Przed przypisaniem sprawdź, że dla połączenia nie zapisano żadnego wyjścia.

nftables trzyma znaczniki pakietu i połączenia osobno, a przewodnik po metainformacjach dokumentuje jawną kopię między nimi. Znacznik połączenia sam nie staje się znacznikiem pakietu, na który pasuje twoja reguła, i to jest najczęstszy powód, dla którego starannie napisany klasyfikator nie działa.

Ogranicz przywracanie do kierunku i ruchu, o których myślisz. Zastosowanie znacznika wyjścia internetowego do pakietów powrotnych może wysłać odpowiedzi w stronę wyjścia zamiast LAN, a objawem jest połączenie jednokierunkowe wyglądające jak problem zapory. Przeczytaj ścieżkę odpowiedzi, zanim dotkniesz reguły zapory, bo pakiet jest routowany, tylko nie z powrotem do nadawcy.

Cztery fazy osuszenia

  1. Przygotuj B bez dotykania A: routing, przekazywanie, autoryzacja, NAT i ścieżka powrotna. Zainstaluj jego tabelę i politykę wyboru przez istniejącego właściciela konfiguracji bramy.

  2. Przełącz klasyfikator, aby nowe, nieklasyfikowane połączenia wybierały B, zachowując zapisane wybory. Atomowa transakcja nftables unika okna, w którym trzeba wyczyścić stary stan.

  3. Zostaw A włączone, aż jego przepływy się skończą. Jego interfejs, tabela, zdalne wyjście i mapowania NAT nadal są częścią tych przepływów, a edycja reguły NAT nie odbudowuje istniejących powiązań.

  4. Wycofaj A, gdy warunek osuszenia jest spełniony, oceniany na podstawie stanu połączeń i zachowania aplikacji, a nie jednego spokojnego przedziału.

Czego osuszenie nie może obiecać

Żądanie przeglądarki nie jest nowym połączeniem transportowym; łączenie nadal wysyła żądania starym. Odwrotnie, przepływ UDP może zestarzeć się poza conntrack, a późniejszy pakiet jest klasyfikowany od nowa. Osuszenie podąża za śledzonymi przepływami, nie za wyobrażeniem aplikacji o sesji.

Jeśli A zawiedzie, zanim jego przepływy się skończą, zapisany znacznik ich nie uratuje. Łączą się ponownie przez B albo w ogóle się nie łączą. Zaplanowane osuszenie kupuje ciągłość, dopóki pierwotna ścieżka jest zdrowa; to nie replikacja stanu między niezależnymi wyjściami.

Zweryfikuj obie połowy

Przed zmianą uruchom długotrwałe dozwolone połączenie, a po niej naprawdę nowe. Potwierdź, którego tunelu używa każde i jaki publiczny adres źródłowy widzi zdalny koniec, następnie sprawdź, czy ruch powrotny wraca.

Nie opróżniaj tabeli conntrack, aby nowy wybór się pojawił. To niszczy dokładnie ten stan, który osuszenie ma zachować, i zamienia kontrolowaną migrację w awarię z czysto wyglądającym testem.

Powiązane artykuły