TLS skyddar en kanal mellan två ändpunkter och säger ingenting om vilka tjänster som finns inuti. En wrapper gör den kanalen till en enda konfigurerad vidarebefordrare, för en enda lyssnare, till en enda destination. En produkt som säljs som SSL VPN lägger vanligtvis till ett gränssnitt, en routingtabell och en åtkomstmodell kring samma primitiv. Att blanda ihop de två är hur en fungerande tunnel tas för nätverksåtkomst.

Vad en servicewrapper faktiskt kopplar samman

En wrapper lyssnar på en lokal port och vidarebefordrar det som anländer till en konfigurerad destination, antingen ett värdnamn och en port eller ett lokalt program. Den destinationen väljs av den som skrev konfigurationsfilen, en lyssnare i taget. Installation av paketet skapar inga rutter, inget virtuellt gränssnitt och ingen nåbarhet för något som inte uttryckligen listas. Läs konfigurationen före paketbeskrivningen, eftersom beskrivningen täcker en användningsklass och filen täcker din.

Så den användbara frågan om en wrapper är inte om den krypterar, utan vad som står i varje ände av kedjan den bygger.

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

Läs den kedjan ur konfigurationen och inte ur marknadsnamnet. Varje pil är ett separat nätverkshopp med egen adress och egna åtkomstregler.

Hitta var TLS-kanalen slutar

Om wrappern avslutar TLS är allt den vidarebefordrar en ny anslutning med nya egenskaper. Strömmen kan vara klartext på ett privat segment, eller den kan bära ett annat skyddat protokoll inuti sig. Att anta det ena eller andra utan att läsa backend-konfigurationen är hur folk drar slutsatsen att det yttre lagret skyddar data det aldrig ser igen. Hoppet som vidarebefordras förtjänar sin egen granskning, på sin egen adress och port.

Kontrollera lyssnaren och backend separat, eftersom ett lyckat handslag vid ytterdörren inte säger något om tjänsten bakom.

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

Det första kommandot visar vilken process som äger porten och på vilken adress den lyssnar. Det andra skriver ut certifikatet som klienten faktiskt får, och det är identitetskontrollen som ett portnummer inte kan ersätta.

Vad en routad VPN tillför som en wrapper inte gör

En routad VPN installerar ett gränssnitt, tar över ägandet av utvalda prefix och integreras med värdens routing och åtkomstpolicy. Varje applikation på maskinen drar nytta av det utan att veta att tunneln finns. En wrapper ger den räckvidden till en enda konfigurerad lyssnare och stannar där.

Tillträde är återigen separat. En VPN som autentiserar en klient behöver fortfarande ett bemyndigande som säger vilka resurser klienten får nå, och en wrapper som autentiserar en peer behöver fortfarande en backend som upprätthåller sina egna behörigheter.

Det finns en legitim kombination: ett VPN-protokoll buret inuti en TLS-wrapper på ett medvetet stött TCP-arrangemang. Det staplar två lager, och det gör inte wrappern och VPN:en till samma slags objekt.

Jämför gränsen som fallerar

Skriv ned frontend-adressen, lyssnaren, peer-identiteten, backend-målet och applikationsåtgärden innan du ändrar något. Jämför sedan likt med likt: en framgång via ett annat värdnamn eller en annan port bevisar inte att brandväggs- och certifikatvillkoren var identiska.

En avvisad backend-begäran bör aldrig repareras genom att stänga av frontend-identitetsverifieringen. Det byter ett diagnostiserbart auktoriseringsfel mot ett odiagnostiserbart förtroendefel.

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

Att fästa namnet vid en vald adress skiljer namnuppslagning från nåbarhet, vilket oftast är det snabbaste sättet att avgöra vilket av de två som är trasigt.

Jämförelsen som spelar roll namnger det skyddade ändpunktsparet, nyttolasten som bärs, applikationerna som använder den och behörigheten som upprätthålls vid destinationen. TLS bidrar till den beskrivningen utan att fullborda den.

Relaterade artiklar