Domain fronting to nie VPN: dwie nazwy, jedno żądanie

Obie techniki trafiają na jedną półkę, bo obie angażują pośrednika i obie brzmią jak ukrywanie. Działają jednak na różnych obiektach. Domain fronting dotyczy tego, która nazwa pojawia się na której warstwie jednego żądania HTTPS. VPN dotyczy tego, które pakiety idą określoną drogą do peera. Nazywanie frontingu rodzajem VPN prowadzi do projektów, które nie mogą działać, i do przeglądów, które zadają niewłaściwe pytanie.

Dwie nazwy, dwie warstwy

Połączenie TLS może nieść nazwę serwera w swoim uzgadnianiu. Gdy połączenie istnieje, żądanie HTTP identyfikuje władzę, której chce, zwykle w nagłówku Host. To dwa pola czytane w dwóch różnych momentach przez dwa różne fragmenty oprogramowania.

Domain fronting wykorzystuje różnicę między pierwszymi dwoma, tak że usługa frontingu przyjmuje połączenie, a następnie kieruje żądanie gdzie indziej. Działa tylko tam, gdzie ta usługa jest gotowa je skierować, a to kwestia polityki dostawcy, nie sztuczki protokołu.

Fronting zależy od dostawcy, nie od techniki

Jako ograniczony przykład, Najczęstsze pytania o Front Door przewodnik Azure dokumentuje zabezpieczenia przed domain frontingiem. Opisuje dozwoloną niezgodność dla domen w ramach tej samej subskrypcji i skonfigurowanych tras oraz odpowiedź 421 Misdirected Request, gdy ochrona przed niezgodnością blokuje żądanie.

Ta jedna udokumentowana polityka obala oba hasła naraz. Nie każda para różnych nazw działa i nie każda niezgodność jest zabroniona. Inne usługi mają własne kontrole, własne wymagania wdrożeniowe i własne kody błędów.

To nie jest też instrukcja omijania ograniczeń innej sieci. Czytanie reguł trasowania dostawcy, by zrozumieć, co dopuszcza, jest pracą architektoniczną; traktowanie tych reguł jako przepisu na obejście to inna czynność o innych skutkach. Trzymaj te dwie czynności osobno w dokumencie, który piszesz. To ta druga sprawia, że projekt jest odrzucany w przeglądzie.

Co VPN faktycznie wybiera

W sieciowym VPN trasowanie i polityka platformy wybierają ruch wewnętrzny do tunelu prowadzącego do peera. W zależności od układu może to obejmować kilka aplikacji lub zdefiniowany podzbiór, a także przenosić protokoły, które w ogóle nie mają żądania HTTP.

Fronting nie robi nic z tego. Zorganizowanie jednego żądania HTTPS przez usługę frontingu nie instaluje trasy do sieci prywatnej, nie przenosi dowolnych aplikacji UDP i nie sprawia, że każdy program na urządzeniu korzysta z usługi. Jeśli potrzebujesz takiego pokrycia, potrzebujesz proxy lub tunelu, a nie sztuczki z nazwą.

Dlatego oba mylą się w przeglądzie: oba opisuje się jako pośredników i oba pojawiają się w dokumentach o dostępie. Interfejs, który oferuje każde z nich, jest zupełnie różny, i tylko jedno z nich jest ścieżką sieciową.

Widoczność nie jest binarna

Porównanie też nie sprowadza się do ukrytego kontra widocznego. Zapytania DNS, adresy docelowe, cechy uzgadniania, rozmiary pakietów i czasy pozostają obserwowalne dla kogoś, kto jest w pozycji, by je zobaczyć, a to, czego ten obserwator się dowie, zależy od tego, gdzie siedzi.

Dane aplikacji są też widoczne w punktach końcowych, które je kończą. Usługa frontingu, która kieruje twoje żądanie, jest jednym z takich punktów, a peer VPN innym. Żaden z układów nie czyni treści nieprzejrzystą dla strony, która musi ją przeczytać, by cię obsłużyć.

Narysuj trzy pudełka

Do przeglądu architektury narysuj punkt końcowy TLS, usługę trasowania HTTP i aplikację końcową jako trzy osobne pudełka, a potem narysuj dowolnego peera VPN jeszcze gdzie indziej. Miejsce, które wybiera cel w sieci web, i miejsce, które transportuje pakiety sieci prywatnej, nie muszą być tym samym systemem, i zwykle nie są.

Gdy pudełka są osobno, pytania stają się odpowiadalne: jakie nazwy akceptuje ten dostawca, które protokoły wymagają przenoszenia i która strona może co widzieć. Diagram, który je scala, daje projekt, którego nikt nie może wdrożyć, i przegląd, który spiera się o słownictwo.