Shtresat e SSTP të shpjeguara: çfarë zbulon ende paketa e brendshme

Në shumicën e shpjegimeve dy fakte për SSTP bashkohen në një, dhe pikërisht ky bashkim i bën regjistrimet konfuzë. Paketa e aplikacionit mbijeton brenda kanalit të mbrojtur, dhe lidhja TCP që e mbart atë kanal i mban adresat e veta gjatë gjithë rrugës. Përgjatë telit kalon një bartës bashkë me ngarkesën e tij, kurrë një zëvendësues për ndonjërin prej tyre. Kaloni stivën nga jashtë brenda dhe etiketoni çdo kufi që kapërceni.

Filloni nga bartësi i jashtëm

Gjëja e parë në tel është një lidhje TCP e zakonshme drejt portës 443, me adresa reale që ruterat i përcjellin. Pikërisht kjo lidhje i mbijeton përkthimit të adresave të rrjetit dhe është ajo që një ofrues aksesi mund të numërojë. Mbrojtja e ngarkesës nuk e heq bartësin, dhe nuk fsheh vëllimin ose kohën.

Çdo gjë pas kësaj pike mbartet dhe nuk rrugëtohet. Bartësi vazhdon të punojë edhe kur shkëmbimi i brendshëm dështon.

Ndiqni inkapsulimin brenda

Brenda kanalit të mbrojtur qëndron një shkëmbim kontrolli SSTP, më pas një sesion PPP, më pas paketa e rrjetit që klienti dëshiron të dorëzohet. Çdo shtresë ka negociatat e veta, mesazhet e veta të gabimit dhe makinën e vet të gjendjes. Prandaj një defekt mund të duket si defekt TLS nga një këndvështrim dhe si defekt PPP nga një tjetër. Leximi i shtresave sipas radhës tregon cila makinë gjendjeje ndaloi.

Një regjistrim i vetëm rrallë tregon të gjithë stivën. Kryet e jashtme janë të dukshme vetëm jashtë pikës fundore, dhe ato të brendshme vetëm pas dekapsulimit. Kjo asimetri vjen nga vendi ku qëndroni, jo nga protokolli.

Diagrami më poshtë i grupon shtresat që të mund të flitet fare për to. Nuk është një renditje bajtesh, nuk premton një regjistrim për paketë dhe nuk thotë asgjë për sa operacione kriptografike kryen një implementim.

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

Etiketoni vëzhguesin përpara se të lexoni një regjistrim

Dy regjistrime të të njëjtit sesion përgjigjen pyetjeve të ndryshme, dhe ndërfaqja ku u morën vendos për cilat. Në rrugën e aksesit shihni bartësin dhe regjistrimet TLS, dhe mund të matni madhësi dhe intervale pa parë një adresë të brendshme. Në pikën fundore, pas dekapsulimit, paketa e brendshme është trafik i zakonshëm nën politikën private të përcjelljes.

Shkruani ndërfaqen dhe drejtimin në çdo regjistrim përpara se ta interpretoni. Një gjurmë e marrë në një përshtatës fizik nuk do të tregojë kurrë adresat e aplikacionit të brendshëm si fusha të zakonshme të jashtme, dhe leximi i kësaj mungese si defekt kriptimi është një gabim i zakonshëm. Një gjurmë e marrë nga brenda tunelit nuk tregon fare bartës, prandaj nuk mund t'i përgjigjet një pyetjeje për pamjen e ofruesit. E njëjta disiplinë vlen edhe për regjistrat e pikës fundore, të cilët shënojnë rendin e negociatave dhe jo përmbajtjen.

Mbani kontrollet që diagrami nuk mund t'i provojë

Rendi i shtresave nuk vërteton se një vendosje vërteton certifikatën e serverit, negocion një version TLS të mbështetur ose autorizon llogarinë. Secili prej tyre është një vendim konfigurimi që dështon në mënyrë të pavarur nga inkapsulimi.

Verifikoni ato me një klient që raporton për çfarë negocioi, në vend që të arsyetoni nga një vizatim. Filloni me shtrëngimin e duarve TLS, më pas shkëmbimin SSTP, më pas PPP, dhe ndaloni në fazën e parë që raporton një gabim. Komanda e parë printon zinxhirin dhe versionin e negociuar, dhe e dyta liston shtrëngimet e duarve të pranishme në një regjistrim.

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