Czy sieć może zablokować Twój VPN, nie łamiąc szyfrowania?
Szyfrowanie chroni treść, a nie dostarczenie. Porównaj listy blokad, listy dozwolonych i wyłączenia, a potem zapytaj, co naprawdę może potwierdzić jedna obserwacja.
Żaden operator nie potrzebuje klucza sesji, aby zatrzymać tunel: wyrzuć pakiety na ścieżce i tunel zawodzi, podczas gdy kryptografia pozostaje dokładnie tak silna, jak obiecywał jej projekt. Szyfrowanie chroni to, co niesie rozmowa, a nie gotowość dowolnej sieci do niesienia jej. Rozdzielenie tych dwóch właściwości zamienia spór o nieblokowalność w pytanie, która polityka obowiązuje i jak daleko sięga. Porównanie poniżej trzyma dostępność i poufność osobno, ponieważ większość pewnych twierdzeń o blokowaniu VPN po cichu je scala.
Osiągalność to decyzja podejmowana przez ścieżkę
Każdy transport zależy od ścieżki, która przekazuje pakiety, a każde pytanie o politykę tutaj sprowadza się do tej decyzji o przekazywaniu. Reguła, która odrzuca pakiety, zmienia dostępność, nie dotykając poufności, i właśnie tak tunel może być bezbłędnie zaszyfrowany i jednocześnie całkowicie bezużyteczny. Nic w tym wyniku nie wymaga złamania szyfru ani odzyskania klucza. Wymaga tylko kontroli nad ścieżką.
Zamieszanie zwykle zaczyna się od tego, że dwie właściwości dzielą jedno słowo. Silna kryptografia mówi, kto może czytać strumień; nie mówi nic o tym, czy urządzenie pośredniczące go przepuści. Twierdzenie, że VPN nie da się zablokować, wymaga więc drugiego twierdzenia pod nim, mianowicie że nikt na ścieżce nie jest gotów wyrzucić pakietów.
Style egzekwowania i cena każdego z nich
Trzy style obejmują większość rzeczywistych polityk i różnią się tym, co muszą wiedzieć, ile kosztuje ich prowadzenie i kto jeszcze cierpi. Każdy z nich może odmówić tunelowi, nie odszyfrowując niczego. Różnice mają znaczenie, ponieważ to samo słowo, blokowanie, jest używane dla wszystkich trzech.
| Style | Default | What it must know | Who else is affected |
|---|---|---|---|
| Blocklist | Allow, minus listed destinations | Addresses and ports of known endpoints | Unrelated tenants on a listed address |
| Allowlist | Deny, plus approved destinations | A maintained definition of permitted traffic | Anything outside the approved set |
| Shutdown | Deny broadly for a period | Nothing about the protocol | Ordinary services along the same path |
Ta tabela to mapa kosztów, a nie ranking. Lista blokad jest tania na start i droga w utrzymaniu dokładności; lista dozwolonych wymienia odkrywanie na utrzymanie dozwolonego zbioru, a wyłączenie nie wymaga żadnej klasyfikacji. Nie dzieli ich techniczna finezja, lecz to, gdzie każdy z nich umieszcza stały wysiłek. Polityka, która na papierze wygląda prosto, zwykle ma gdzie indziej ukryty wiersz utrzymania.
Lista blokad jest ograniczona tym, jak dobrze adres nazywa usługę
Lista blokad odmawia celom już zidentyfikowanym, a resztę pozostawia ogólnie dostępną. Do jej egzekwowania potrzebne są adresy i porty, nie czysty tekst, i to czyni ją na początku tanią w utrzymaniu. Koszt przychodzi później, bo zakres, który kiedyś wskazywał jednego dostawcę, może później hostować tuzin niepowiązanych najemców. Każda zmiana adresu wymusza edycję listy, a każdy nieaktualny wpis zabiera ze sobą niewinny ruch.
Precyzja w tym modelu jest ograniczona tym, jak dobrze cel identyfikuje usługę, a zajęty współdzielony punkt końcowy jest słabym identyfikatorem. To ograniczenie strukturalne, a nie wada implementacji, więc lepsze narzędzia go nie usuwają. To wyjaśnia też, dlaczego listy blokad mają tendencję do wzrostu: każdy nowy punkt końcowy wygląda jak mały dodatek, a szkody uboczne rosną wraz z listą.
Lista dozwolonych przenosi ciężar utrzymania
Lista dozwolonych odwraca domyślne ustawienie, tak że przechodzą tylko wybrane z góry cele lub typy ruchu. Nie musi wyliczać każdego zabronionego punktu końcowego, co pomaga, gdy zabroniony zbiór jest duży lub szybko się zmienia. Potrzebuje natomiast utrzymywanej definicji tego, co dozwolone, plus egzekwowania zgodnego z tą definicją.
Numery portów to zwykły słaby punkt w takiej definicji. Zezwolenie na port nie jest tym samym co zidentyfikowanie każdej aplikacji, która może go użyć, więc lista dozwolonych oparta na portach często przepuszcza więcej, niż zamierzał jej autor. Odciski protokołów mają ten sam problem z innego kąta, bo identyfikują kształt ruchu, a nie intencję. Lista dozwolonych nie jest więc automatycznie precyzyjniejsza od listy blokad; jest precyzyjna w odniesieniu do czegoś innego.
Co jedna obserwacja może potwierdzić, a czego nie
Każde twierdzenie o blokowaniu należy czytać z czterema pytaniami w ręku: które sieci dostępowe, które cele, które protokoły i jaki okres obserwacji. Awaria widziana dziś w jednej sieci komórkowej nic nie mówi o tym samym punkcie końcowym jutro z innej sieci. Tunel, który raz zadziałał, też nic nie mówi o trwałej dostępności.
Kształt awarii można zaobserwować, zanim zacznie się teoretyzować o jej przyczynie. Ciche zawieszenie, natychmiastowa odmowa i reset po połączeniu wskazują na różne style egzekwowania, a dwa polecenia je rozdzielają:
curl -sS -m 8 https://vpn.example.com/ -o /dev/null -w "%{http_code}\n"
traceroute -n -m 8 vpn.example.comZawieszenie kończące się przekroczeniem czasu sugeruje ciche odrzucanie, szybka odmowa sugeruje urządzenie odrzucające na ścieżce, a reset po połączeniu sugeruje ingerencję ze stanem, a nie brakującą trasę. Przegląd technik cenzury RFC 9505 opisuje punkty kontroli i wzorce ingerencji stojące za tymi kształtami. Żaden z nich nie mówi jednak, jak szeroko polityka obowiązuje. Trwałość to twierdzenie silniejsze niż osiągalność: punkty końcowe, oprogramowanie, polityki i dozwolone usługi wszystkie się zmieniają, więc nieograniczona skuteczność wymaga założeń o dalszym egzekwowaniu, a nie listy adresów widzianych w jednej chwili.