Geeft een TLS-wrapper je een privénetwerk? Meestal niet

TLS beschermt een kanaal tussen twee eindpunten en zegt niets over welke diensten erbinnen zitten. Een wrapper maakt van dat kanaal één geconfigureerde doorstuurder, voor één luisteraar, naar één bestemming. Een product dat als SSL VPN wordt verkocht, voegt meestal een interface, een routetabel en een toegangsmodel toe rond hetzelfde primitief. De twee verwarren is hoe een werkende tunnel voor netwerktoegang wordt aangezien.

Wat een service-wrapper werkelijk verbindt

Een wrapper luistert op een lokale poort en stuurt wat aankomt door naar een geconfigureerde bestemming, of dat nu een host en poort is of een lokaal programma. Die bestemming kiest wie het configuratiebestand heeft geschreven, één luisteraar tegelijk. Het installeren van het pakket maakt geen routes, geen virtuele interface en geen bereikbaarheid voor iets dat niet expliciet is vermeld. Lees de configuratie vóór de pakketbeschrijving, want de beschrijving dekt een klasse van gebruik en het bestand dekt het jouwe.

De nuttige vraag over een wrapper is dus niet of hij versleutelt, maar wat er aan elk uiteinde van de keten staat die hij bouwt.

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

Lees die keten uit de configuratie en niet uit de marketingnaam. Elke pijl is een aparte netwerksprong met zijn eigen adres en zijn eigen toegangsregels.

Vind waar het TLS-kanaal eindigt

Als de wrapper TLS beëindigt, is alles wat hij doorstuurt een nieuwe verbinding met nieuwe eigenschappen. De stroom kan platte tekst op een privé-segment zijn, of een ander beschermd protocol in zich dragen. Een van beide aannemen zonder de backend-configuratie te lezen is hoe mensen concluderen dat de buitenste laag gegevens beschermt die hij nooit meer ziet. De doorgestuurde sprong verdient zijn eigen inspectie, op zijn eigen adres en poort.

Controleer de luisteraar en de backend apart, want een geslaagde handdruk bij de voordeur zegt niets over de dienst erachter.

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

Het eerste commando laat zien welk proces de poort bezit en op welk adres het luistert. Het tweede drukt het certificaat af dat de client werkelijk ontvangt, en dat is de identiteitscontrole die een poortnummer niet kan vervangen.

Wat een gerouteerde VPN toevoegt en een wrapper niet

Een gerouteerde VPN installeert een interface, neemt het eigendom van geselecteerde prefixen over en integreert met het routeren en het toegangsbeleid van de host. Elke applicatie op de machine profiteert zonder te weten dat de tunnel bestaat. Een wrapper geeft dat bereik aan één geconfigureerde luisteraar en stopt daar.

Toelating is weer apart. Een VPN die een client authenticeert, heeft nog steeds een autorisatie nodig die zegt welke bronnen de client mag bereiken, en een wrapper die een peer authenticeert, heeft nog steeds een backend nodig die zijn eigen rechten afdwingt.

Er is een legitieme combinatie: een VPN-protocol vervoerd in een TLS-wrapper op een bewust ondersteunde TCP-opstelling. Dat stapelt twee lagen, en het maakt de wrapper en de VPN niet hetzelfde soort object.

Vergelijk de grens die faalt

Noteer het frontend-adres, de luisteraar, de peer-identiteit, het backend-doel en de applicatiebewerking voordat je iets verandert. Vergelijk daarna gelijk met gelijk: een succes via een andere hostnaam of poort bewijst niet dat de firewall- en certificaatvoorwaarden identiek waren.

Een afgewezen backend-verzoek mag nooit worden gerepareerd door de frontend-identiteitsverificatie uit te schakelen. Dat ruilt een diagnoseerbare autorisatiefout voor een niet-diagnoseerbare vertrouwensfout.

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

Het vastpinnen van de naam op een gekozen adres scheidt naamresolutie van bereikbaarheid, wat meestal de snelste manier is om te zien welke van de twee stuk is.

De vergelijking die ertoe doet, benoemt het beschermde eindpuntpaar, de vervoerde lading, de applicaties die ervan gebruikmaken en de toestemming die op de bestemming wordt afgedwongen. TLS draagt aan die beschrijving bij zonder die te voltooien.