Kompresja w OpenVPN: odmówić, tylko odbierać czy pełne LZO?
comp-lzo no nie jest ścisłą odmową. Porównaj odmowę kompresji, jednostronne akceptowanie podczas migracji i jej zachowanie, a potem sprawdź, co robi offload.
Trzy linie w profilu wyglądają, jakby wszystkie wyłączały kompresję, a naprawdę robi to tylko jedna z nich. Różnica ma znaczenie, bo ostrzeżenie, które chcesz wyciszyć, jest objawem, natomiast polityka decyduje, czy druga strona nadal może kompresować. Porównanie opcji na jednej osi, czyli tego, co każda dopuszcza po zmianie, usuwa większość niejasności. To, której chcesz, zależy od tego, czy migrujesz, czy się urządzasz.
Trzy polityki, które w pliku konfiguracyjnym wyglądają podobnie
Każda opcja odpowiada na inne pytanie. allow-compression no odrzuca skompresowane ładunki od razu, allow-compression asym dekompresuje to, co przychodzi, i nigdy nie kompresuje tego, co wychodzi, a stara comp-lzo no zostawia miejsce na push drugiej strony, który włączy kompresję. Tylko pierwsza jest polityką, której serwer nie może nadpisać.
Zapisz te trzy w tabeli przed wyborem, bo nazwy są dość bliskie, by zmylić recenzenta. Dwie z nich nadal uruchamiają kod dekompresji na odebranych pakietach i właśnie o tym jest argument bezpieczeństwa. Trzecia usuwa zdolność, zamiast ograniczać jej kierunek. Jeśli zapis zmiany mówi, że kompresja jest wyłączona, dokładnie jeden wiersz spełnia to zdanie.
Ostrzeżenie, które zapoczątkowało dochodzenie, nie jest celem. Wyciszenie go przy pozostawieniu permisywnej polityki daje czysty dziennik i niezmienioną ekspozycję.
| Setting | What it permits | When it is the right answer |
|---|---|---|
allow-compression no | No compressed payloads, and no compression framing under offload | Both ends can be changed now |
allow-compression asym | Decompress inbound only | A dated migration while peers catch up |
comp-lzo no | Off locally, still pushable by a peer | Legacy compatibility you can still justify |
Co znaczy no w starej opcji LZO
W przestarzałej opcji LZO no wyłącza kompresję po stronie lokalnej, nie zabraniając drugiej stronie włączenia jej tam, gdzie polityka na to pozwala. To przez tę asymetrię przeniesienie profilu na ścisłą odmowę zmienia zachowanie w sposób, którego test laboratoryjny z jednym serwerem może nigdy nie ujawnić.
Obawa o bezpieczeństwo jest warunkowa, nie absolutna. Gdy napastnik może umieścić wybrany tekst jawny obok sekretu i obserwować, jak kompresja zmienia rozmiar zaszyfrowanego ruchu, istnieje kanał informacyjny. Przejście z LZO na LZ4 zmienia algorytm i ramkowanie, a nie ten mechanizm.
Uczciwe ujęcie dotyczy więc tego, na co jesteś gotów pozwolić, a nie tego, który algorytm jest obecnie zalecany. Ścisła odmowa to jedyna opcja, która nie zależy od współpracy drugiej strony.
Tylko odbieranie to stan migracji, a nie cel
Asymetryczna akceptacja istnieje po to, by jedna strona mogła przestać kompresować, podczas gdy druga wciąż tego oczekuje. To most, a mosty potrzebują daty końcowej i właściciela. Zapisuj, które strony nadal wysyłają skompresowany ruch, bo polityka dopuszcza dokładnie taki ruch. Bez tej listy stan migracji z inercji staje się stałą konfiguracją.
Klient nie może zmusić niekompatybilnego serwera do porzucenia starego ramkowania, edytując własny plik. Kierunek push ustala się na serwerze, więc migracja faktycznie kończy się w konfiguracji serwera i jego plikach dla poszczególnych klientów.
Tryby stub zachowują ramkowanie, ale pomijają samą pracę kompresji, i nie są bezpośrednim odpowiednikiem starszej opcji. Przetestuj je na najstarszej stronie, którą jeszcze musisz obsługiwać, zanim wybierzesz jeden z nich.
Gdzie offload kanału danych zmienia odpowiedź
Offload kanału danych przenosi obsługę pakietów do jądra, a profil, który nadal zależy od ramkowania kompresji, może nie pasować do tej ścieżki. Awaria nie zawsze jest głośna: klient się łączy, a potem zachowuje się inaczej niż testowany tunel.
Sprawdź, która implementacja jest aktywna przed zmianą i po niej, a nie tylko czy połączenie się udaje. Gdy ścieżka z offloadem odrzuca ramkowanie kompresji, ścisła polityka odmowy i wdrożenie z offloadem są zgodne, natomiast permisywna polityka i wdrożenie z offloadem nie.
Ta kombinacja zasługuje na własny test, bo właśnie tam plik, który wygląda poprawnie, po cichu nie jest tym, który jest używany. Porównaj stan wynegocjowany z intencją zapisaną w profilu, bo tylko jedno z nich jest widoczne w dzienniku.
Wybierz politykę, a potem zweryfikuj wynegocjowany wynik
Wybierz ścisłą odmowę, gdy możesz zmienić obie strony, asymetryczną akceptację, gdy jeszcze nie możesz, a pełną kompresję tylko wtedy, gdy potrafisz uzasadnić, dlaczego ekspozycja jest akceptowalna. Potem zweryfikuj to, co wynegocjowano, a nie to, co mówi plik. Cichszy dziennik jest dowodem tylko wtedy, gdy odpowiada polityce, którą zamierzałeś wdrożyć.
Trzymaj decyzję obok profilu, którego dotyczy, z datą i stronami wciąż zwolnionymi. Po pół roku ta notatka jest różnicą między świadomym wyjątkiem a wypadkiem, którego nikt nie potrafi datować. Zapisz ją w tym samym repozytorium co profil, aby następny redaktor zobaczył powód przed dyrektywą.