În majoritatea explicațiilor două fapte despre SSTP se contopesc, iar tocmai această contopire face capturile confuze. Pachetul aplicației supraviețuiește în interiorul canalului protejat, iar conexiunea TCP care transportă acel canal își păstrează propriile adrese pe tot parcursul. Pe fir circulă un purtător împreună cu încărcătura sa, niciodată un substitut pentru vreunul dintre ele. Parcurgeți stiva dinspre exterior spre interior și etichetați fiecare graniță pe care o traversați.

Începeți cu purtătorul exterior

Primul lucru pe fir este o conexiune TCP obișnuită către portul 443, cu adrese reale pe care routerele le transmit mai departe. Această conexiune este cea care supraviețuiește traducerii adreselor de rețea și cea pe care un furnizor de acces o poate număra. Protejarea încărcăturii nu elimină purtătorul, și nu ascunde volumul sau momentul.

Tot ce urmează după acest punct este purtat, nu rutat. Purtătorul continuă să funcționeze chiar și atunci când schimbul interior eșuează.

Urmați încapsularea spre interior

În interiorul canalului protejat se află un schimb de control SSTP, apoi o sesiune PPP, apoi pachetul de rețea pe care clientul vrea să îl primească. Fiecare strat are propria negociere, propriile mesaje de eroare și propria mașină de stări. De aceea o defecțiune poate arăta ca o defecțiune TLS dintr-un punct de vedere și ca o defecțiune PPP din altul. Citirea straturilor în ordine spune care mașină de stări s-a oprit.

O singură captură arată rareori toată stiva. Antetele exterioare sunt vizibile doar în afara punctului final, iar cele interioare doar după decapsulare. Această asimetrie vine din locul în care stați, nu din protocol.

Diagrama de mai jos grupează straturile pentru ca despre ele să se poată vorbi măcar. Nu este o dispunere de octeți, nu promite o înregistrare pe pachet și nu spune nimic despre câte operații criptografice execută o implementare.

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

Etichetați observatorul înainte de a citi o captură

Două capturi ale aceleiași sesiuni răspund la întrebări diferite, iar interfața pe care au fost luate decide la care. Pe calea de acces vedeți purtătorul și înregistrările TLS, și puteți măsura dimensiuni și intervale fără a vedea o adresă interioară. La punctul final, după decapsulare, pachetul interior este trafic obișnuit sub politica privată de transmitere.

Scrieți interfața și direcția pe fiecare captură înainte de a o interpreta. O urmă luată de pe un adaptor fizic nu va arăta niciodată adresele aplicației interioare ca câmpuri exterioare obișnuite, iar citirea acestei absențe ca o defecțiune de criptare este o greșeală frecventă. O urmă luată din interiorul tunelului nu arată niciun purtător, așa că nu poate răspunde la o întrebare despre viziunea furnizorului. Aceeași disciplină se aplică jurnalelor punctului final, care notează ordinea negocierii, nu conținutul.

Păstrați verificările pe care diagrama nu le poate dovedi

Ordinea straturilor nu stabilește că o implementare validează certificatul serverului, negociază o versiune TLS acceptată sau autorizează contul. Fiecare dintre acestea este o decizie de configurare care eșuează independent de încapsulare.

Verificați-le cu un client care raportează ce a negociat, în loc să raționați pornind de la un desen. Începeți cu strângerea de mână TLS, apoi schimbul SSTP, apoi PPP, și opriți-vă la prima etapă care raportează o eroare. Prima comandă afișează lanțul și versiunea negociată, iar a doua enumeră strângerile de mână prezente într-o captură.

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

Articole similare