Czy wrapper TLS daje prywatną sieć? Zwykle nie

TLS chroni kanał między dwoma końcami i nie mówi nic o tym, jakie usługi znajdują się w środku. Wrapper zamienia ten kanał w jeden skonfigurowany przekazujący, dla jednego odbiorcy, do jednego celu. Produkt sprzedawany jako SSL VPN zwykle dodaje interfejs, tablicę routingu i model dostępu wokół tego samego prymitywu. Mylenie obu rzeczy to sposób, w jaki działający tunel jest brany za dostęp do sieci.

Co właściwie łączy wrapper usługi

Wrapper nasłuchuje na lokalnym porcie i przekazuje to, co przychodzi, do skonfigurowanego celu — hosta i portu albo lokalnego programu. Ten cel wybiera ten, kto napisał plik konfiguracyjny, po jednym odbiorcy naraz. Instalacja pakietu nie tworzy tras, interfejsu wirtualnego ani osiągalności dla czegokolwiek, co nie jest wyraźnie wymienione. Czytaj konfigurację przed opisem pakietu, ponieważ opis obejmuje klasę użycia, a plik obejmuje twoją.

Zatem użyteczne pytanie o wrapper nie brzmi, czy szyfruje, ale co stoi na każdym końcu budowanego przez niego łańcucha.

application -> local listener -> TLS connection -> remote listener -> configured backend

Czytaj ten łańcuch z konfiguracji, a nie z nazwy marketingowej. Każda strzałka to osobny skok sieciowy z własnym adresem i własnymi regułami dostępu.

Znajdź, gdzie kończy się kanał TLS

Jeśli wrapper kończy TLS, wszystko, co dalej przekazuje, jest nowym połączeniem o nowych właściwościach. Strumień może być jawnym tekstem w prywatnym segmencie albo nieść w sobie inny chroniony protokół. Zakładanie jednego lub drugiego bez czytania konfiguracji backendu to sposób, w jaki ludzie dochodzą do wniosku, że zewnętrzna warstwa chroni dane, których już nigdy nie widzi. Przekazany skok zasługuje na własne sprawdzenie, na własnym adresie i porcie.

Sprawdź odbiorcę i backend osobno, ponieważ udany uścisk dłoni przy przednich drzwiach nic nie mówi o usłudze za nimi.

ss -ltnp | grep -F 443
openssl s_client -connect svc.example.net:443 -servername svc.example.net </dev/null | openssl x509 -noout -subject -dates

Pierwsze polecenie pokazuje, który proces posiada port i na jakim adresie nasłuchuje. Drugie wypisuje certyfikat, który klient faktycznie otrzymuje, i to jest weryfikacja tożsamości, której numer portu nie może zastąpić.

Co dodaje routowana VPN, czego wrapper nie robi

Routowana VPN instaluje interfejs, przejmuje własność wybranych prefiksów i integruje się z routingiem oraz polityką dostępu hosta. Każda aplikacja na maszynie korzysta, nie wiedząc, że tunel istnieje. Wrapper daje ten zasięg jednemu skonfigurowanemu odbiorcy i na tym się zatrzymuje.

Dopuszczenie to znowu osobna sprawa. VPN uwierzytelniająca klienta nadal potrzebuje autoryzacji, która mówi, do jakich zasobów klient może dotrzeć, a wrapper uwierzytelniający partnera nadal potrzebuje backendu, który egzekwuje własne uprawnienia.

Istnieje uzasadnione połączenie: protokół VPN przenoszony wewnątrz wrappera TLS w celowo obsługiwanym układzie TCP. To układa dwie warstwy i nie czyni wrappera i VPN tym samym rodzajem obiektu.

Porównaj granicę, która zawodzi

Zapisz adres frontendu, odbiorcę, tożsamość partnera, cel backendu i operację aplikacji, zanim cokolwiek zmienisz. Potem porównuj porównywalne: sukces przez inną nazwę hosta lub port nie dowodzi, że warunki firewalla i certyfikatu były identyczne.

Odrzuconego żądania do backendu nigdy nie należy naprawiać przez wyłączenie weryfikacji tożsamości frontendu. To zamienia diagnozowalną awarię autoryzacji na niediagnozowalną awarię zaufania.

curl -sv --resolve svc.example.net:443:203.0.113.10 https://svc.example.net/health 2>&1 | head -30

Przypięcie nazwy do wybranego adresu oddziela rozwiązywanie nazw od osiągalności, co zwykle jest najszybszym sposobem ustalenia, które z tych dwóch jest zepsute.

Porównanie, które ma znaczenie, nazywa chronioną parę punktów końcowych, przenoszone obciążenie, aplikacje, które go używają, i uprawnienie egzekwowane w miejscu docelowym. TLS wnosi wkład w ten opis, ale go nie uzupełnia.