SSTP transporton PPP brenda një lidhjeje HTTPS, prandaj duket si trafik web për çdo gjë në mes. TLS dhe HTTP vendosin kanalin e jashtëm, pastaj mesazhet e kontrollit SSTP përgatisin tunelin, dhe PPP ofron sjelljen e sesionit. Një shfletues që ngarkon një faqe në të njëjtën adresë ka përfunduar vetëm një pjesë të fazës së parë. Ta trajtosh atë si test VPN është mënyra se si një proxy që funksionon fajësohet për një mospërputhje protokolli.

Kaloni nëpër katër fazat sipas radhës, dhe dështimi që shihni do të bjerë në njërën prej tyre.

Faza 1: TCP dhe TLS

Klienti hap një lidhje TCP drejt portës 443 dhe kryen një shtrëngim duarsh TLS. Zinxhiri i certifikatave duhet të përputhet me emrin e hostit me të cilin klienti u konfigurua. Një mospërputhje emri këtu prodhon një dështim para se të shkëmbehet ndonjë mesazh SSTP, dhe specifikimi i SSTP supozon se ky kanal i jashtëm HTTPS ekziston tashmë. Asgjë në fazat e mëvonshme nuk mund të kompensojë një dështim besimi këtu.

Një server web i zakonshëm mund ta përfundojë këtë fazë në mënyrë të përsosur dhe prapë të dështojë në të ardhmen. Suksesi i TLS është provë për certifikatën, jo për protokollin pas saj.

Faza 2: kërkesa HTTPS

SSTP e bën kërkesën e tij me një metodë të veçantë, SSTP_DUPLEX_POST, dhe e mban shkëmbimin të hapur në vend që të kthejë një dokument. Një server ose proxy i konfiguruar për kërkesa të zakonshme faqesh mund ta pranojë lidhjen dhe pastaj ta refuzojë metodën. Ai refuzim është problemi i përputhshmërisë që njerëzit zakonisht e përshkruajnë si portë 443 e bllokuar.

Lexoni kodin e përgjigjes dhe metodën në regjistrin e serverit. Një refuzim në këtë fazë është një problem tjetër nga një skadim kohe TCP, dhe të dy çojnë në rregullime të ndryshme.

Faza 3: mesazhet e kontrollit

Pasi kërkesa pranohet, SSTP shkëmben mesazhe kontrolli që negociojnë dhe përgatisin tunelin. Këto janë mesazhe protokolli brenda trupit HTTPS, jo kërkesa HTTP, prandaj një proxy që inspekton dhe rishkruan trupat mund t'i thyejë ato duke i lënë kërkesat e faqeve të paprekura.

Këtu një pajisje e inspektimit të thellë fiton reputacionin e saj. Nëse faqet ngarkohen dhe VPN dështon, kontrolloni nëse trupi po modifikohet në vend që të kontrolloni nëse porta është e hapur.

Faza 4: PPP merr kontrollin

Pastaj PPP ofron sjelljen e sesionit: negocimin e lidhjes, autentikimin dhe konfigurimin e shtresës së rrjetit që vjen më pas. Autentikimi PPP është i ndarë nga kontrolli TLS që klienti ka kaluar tashmë. Një certifikatë serveri që klienti e pranon nuk thotë asgjë për faktin nëse kredencialet e përdoruesit janë të vlefshme ose llogaria është e autorizuar.

Një certifikatë e pranuar dhe një hyrje e refuzuar nuk janë kontradiktore. Janë faza të njëpasnjëshme me rezultate të pavarura.

Autentikimi ka disa role

Klienti vërteton identitetin e serverit TLS ndaj magazinës së tij të besimit dhe emrit të konfiguruar. Pastaj PPP autentikon përdoruesin ose makinën, në varësi të vendosjes. Serveri mund të shtojë politikën e tij për atë se kush mund të lidhet dhe çfarë mund të arrijë. Mbani emrin e hostit në përputhje me identitetin e certifikatës, sepse zëvendësimi me një adresë të papërpunuar e kthen një konfigurim që funksionon në një dështim kontrolli emri.

Shkruani cila fazë raportoi dështimin. Certifikatë, metodë, mesazh kontrolli, autentikim PPP, pastaj rrugët: pesë vende, pesë rregullime.

Çfarë mund dhe çfarë nuk mund të tregojë një test në shfletues

Ngarkimi i një faqe në adresë provon zgjidhjen DNS, arritshmërinë TCP dhe se diçka po dëgjon dhe flet HTTP. Nuk provon se metoda pranohet, se shkëmbimi i kontrollit mbijeton ose se autentikimi PPP është konfiguruar. Përdorni një klient që implementon SSTP në vend që të konvertoni një profil tjetër duke ndryshuar portën.

Pasi sesioni ngrihet, rrugët, DNS dhe përcjellja nga ana e serverit ende vendosin çfarë mund të arrijë përdoruesi. Tuneli është një rrugë, jo një autorizim.

Artikuj të ngjashëm