SSTP-lagen uitgelegd: wat het binnenste pakket nog verraadt

Twee feiten over SSTP vloeien in de meeste uitleg samen, en juist die samenvloeiing maakt opnames verwarrend. Het applicatiepakket overleeft binnen het beveiligde kanaal, en de TCP-verbinding die dat kanaal draagt, houdt al die tijd zijn eigen adressen. Wat over de lijn gaat, is een drager plus zijn lading, nooit een vervanging van een van beide. Loop de stapel van buiten naar binnen door en label elke grens die u oversteekt.

Begin bij de buitenste drager

Het eerste op de lijn is een gewone TCP-verbinding naar poort 443, met echte adressen die routers doorsturen. Die verbinding is wat netwerkadresvertaling overleeft en wat een toegangsprovider kan tellen. Het beschermen van de lading verwijdert de drager niet, en het verbergt ook geen volume of timing.

Alles na dit punt wordt gedragen in plaats van gerouteerd. De drager blijft werken, ook wanneer de binnenste uitwisseling mislukt.

Volg de inkapseling naar binnen

Binnen het beveiligde kanaal zit een SSTP-besturingsuitwisseling, dan een PPP-sessie, dan het netwerkpakket dat de client geleverd wil krijgen. Elke laag heeft zijn eigen onderhandeling, zijn eigen foutmeldingen en zijn eigen toestandsmachine. Een storing kan er dus vanuit het ene gezichtspunt als een TLS-storing uitzien en vanuit het andere als een PPP-storing. De lagen in volgorde lezen vertelt welke toestandsmachine stopte.

Eén opname toont zelden de hele stapel. Buitenste headers zijn alleen buiten het eindpunt zichtbaar, en binnenste pas na het uitpakken van de inkapseling. Die asymmetrie komt van waar u staat, niet van het protocol.

Het diagram hieronder groepeert de lagen zodat er überhaupt over gesproken kan worden. Het is geen byte-indeling, het belooft niet één record per pakket, en het zegt niets over hoeveel cryptografische bewerkingen een implementatie uitvoert.

outer IP header
  TCP to port 443
    TLS record layer
      SSTP control and data packets
        PPP frames
          inner IP packet
            application transport and payload

Label de waarnemer voordat u een opname leest

Twee opnames van dezelfde sessie beantwoorden verschillende vragen, en de interface waarop ze zijn gemaakt bepaalt welke. Op het toegangspad ziet u de drager en de TLS-records, en kunt u groottes en tussenpozen meten zonder een binnenste adres te zien. Op het eindpunt, na het uitpakken, is het binnenste pakket gewoon verkeer onder het particuliere doorstuurbeleid.

Schrijf de interface en de richting op elke opname voordat u die interpreteert. Een spoor van een fysieke adapter zal de adressen van de binnenste applicatie nooit als gewone buitenste velden tonen, en het ontbreken daarvan als een versleutelingsfout lezen is een veelgemaakte fout. Een spoor van binnen de tunnel toont helemaal geen drager, dus het kan geen vraag over de kijk van de provider beantwoorden. Dezelfde discipline geldt voor de logboeken van het eindpunt, die de volgorde van de onderhandeling vastleggen en niet de inhoud.

Behoud de controles die het diagram niet kan bewijzen

De laagvolgorde bewijst niet dat een uitrol het servercertificaat valideert, een ondersteunde TLS-versie onderhandelt of het account autoriseert. Elk daarvan is een configuratiebeslissing die onafhankelijk van de inkapseling mislukt.

Controleer ze met een client die rapporteert wat hij heeft onderhandeld in plaats van te redeneren vanuit een tekening. Begin met de TLS-handshake, dan de SSTP-uitwisseling, dan PPP, en stop bij de eerste fase die een fout meldt. Het eerste commando drukt de keten en de onderhandelde versie af, en het tweede somt de handshakes op die in een opname voorkomen.

openssl s_client -connect vpn.corp.internal:443 -servername vpn.corp.internal
tshark -r sstp.pcap -Y "tls.handshake.type == 1"