SSTP TLS-t vizsgáló proxy mögött: hol szakad meg a munkamenet

A böngésző betölti a vállalati intranetet, a proxy tanúsítványa megbízható, és a SSTP-kliens mégis elszakad a kapcsolat vége felé. Ez a minta a webes kérés és az alagutazott munkamenet közti különbségre mutat, nem rossz jelszóra. Járja végig a kapcsolatot TCP-től felfelé, és jegyezze meg az első szakaszt, amelyik elbukik. A szakasz, nem a hibakód mondja meg, hogy a proxy-e az ok.

Ott kezdje, ahol a kliens megáll

A kliens rögzített sorrenden halad át: TCP-kapcsolat a 443-as portra, TLS-kézfogás, tanúsítvány-ellenőrzés, az SSTP HTTP-cseréje, PPP-tárgyalás és -hitelesítés, majd IP-konfiguráció. Minden szakasz hibája más nyomot hagy, és ezek összekeverése a rossz beállítási oldalra visz.

A TCP-hiba időtúllépés vagy visszaállítás, mielőtt egyetlen TLS-bájt megjelenne. A TLS-hiba riasztás vagy kézfogási időtúllépés. A tanúsítványhiba figyelmeztetést ad a láncról vagy a névről. A HTTP-hiba sikeres kézfogás után érkezik, gyakran állapotkódként vagy azonnali lezárásként. A PPP-hiba azután jön, hogy az alagút technikailag létrejött, ezért hitelesítési problémának tűnik.

A kliensnaplóban az utolsó sikeres szakaszt keresse, ne az első hibasort. A hibasor általában a következményt jelenti, míg a szakaszhatár az elutasító komponenst nevezi meg.

Mit kér az SSTP a hálózattól, hogy hordozzon

Az SSTP TLS fölött fut a TCP 443-on, majd elküld egy SSTP_DUPLEX_POST nevű HTTP-kérést, amelyet az SSTP-specifikáció határoz meg, egy /sra_{GUID}/ alakú útvonalra. A kérés gyakorlatilag korlátlan tartalomhosszt hirdet, és a munkamenet teljes élettartama alatt mindkét irányban nyitva tartja a folyamot. A PPP-keretek ezen a folyamon belül utaznak.

Ezért egy közönséges böngészést kezelő proxy is elbukhat. A véges testű GET vagy POST pufferelhető, vizsgálható és továbbítható; a soha véget nem érő testű duplex folyam nem. A proxy, amely a test befejezésére vár, örökké vár, és a kliens végül időtúllépésbe fut.

A metódusszűrés és a hitelesítés saját hibaformákat ad hozzá. Ha a proxy hitelesítő adatokat kér a kéréshez, a VPN-kliens esetleg nem válaszol, pedig a böngésző válaszolna. Ha eltávolítja vagy átírja a metódust, az átjáró még a PPP kezdete előtt elutasítja a kérést.

Miért változtatja meg a vizsgálat az identitást

A TLS-t vizsgáló proxy lezárja a kliens TLS-kapcsolatát, és külön kapcsolatot nyit az átjáró felé. Ezért a kliens a proxy tanúsítványát ellenőrzi, nem az átjáróét, és az átjáró a proxyt tekinti partnerének. Amikor a szervezet a saját gyökerét osztja ki, a böngésző és a VPN-kliens is elfogadhatja ezt a láncot, így a kézfogás sikerül, és a probléma a következő szakaszra kerül.

A sikeres ellenőrzés nem jelenti, hogy a proxy el tudja hordozni a munkamenetet. Továbbra is pufferelés nélkül kell továbbítania egy korlátlan kétirányú POST-ot, és órákig életben kell tartania mindkét kapcsolatot. Sok vizsgálati termék kérés-válasz forgalomra épül, és ezt az esetet rosszul vagy egyáltalán nem kezeli.

Ezért az ismeretlen gyökér hozzáadása vagy az ellenőrzés kikapcsolása a rossz javítás. Ez megváltoztatja, melyik tanúsítványt fogadja el a kliens; semmit nem tesz a folyamkezeléssel, amely valójában megtörte a munkamenetet.

A beállítások módosítása előtt azonosítsa a kibocsátót

Kérdezze meg a végpontot, milyen tanúsítványt mutat, és ki írta alá. Az alábbi parancsok VPN-munkamenet indítása nélkül mutatják a láncot és a kibocsátót:

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts
curl -vI https://vpn.example.com/

Ha a kibocsátó nyilvános CA, a kapcsolatot valószínűleg nem hallgatják le ennél a gazdagépnél, és a hiba máshol van. Ha a kibocsátó a szervezet saját CA-ja, a vizsgálat aktív, és az átjáróhoz proxyn keresztül lehet eljutni. Hasonlítsa össze az ujjlenyomatot azzal, amelyet a hálózati csapat vár, mielőtt pusztán a névből következtetne.

Egy böngészős teszt ugyanahhoz a gazdagéphez csak azt bizonyítja, hogy a proxy elfogad egy GET-et. Semmit nem mond az SSTP-metódusról, a kérés URI-járól vagy a test élettartamáról, ezért ne tekintsen egy működő intranetoldalt annak bizonyítékaként, hogy az alagútútvonal támogatott.

Válassza a támogatott útvonalat

Tegyen fel a hálózat tulajdonosának egy konkrét kérdést: engedélyezi-e a proxy a pufferelés nélküli duplex POST-ot ehhez az átjáróhoz a 443-as porton? Az igen proxikivételhez vagy dokumentált megkerüléshez vezet a VPN-gazdagép számára. A nem azt jelenti, hogy a vizsgált útvonal nem tudja hordozni az SSTP-t, és a támogatott javítás egy másik útvonal vagy protokoll, nem a kliens babrálása.

A lehetőségek általában a VPN-átjáró vizsgálat nélküli kimenetét, egy osztott alagút kialakítását, amely csak a vállalati forgalmat küldi a proxyn át, vagy egy alternatív protokollt foglalnak magukba, amelyet a szervezet másik porton támogat. Mindegyik a hálózati tervezéshez tartozik, és mindegyiket ugyanazzal az eszközzel és profillal kell tesztelni, hogy az összehasonlítás elkülönítse az útvonalat.

Dokumentálja az eredményt: kibocsátó, elbukó szakasz, proxy-szabály és választott útvonal. A következő ember, aki ugyanazt a 98 százalékos megakadást látja, egyetlen tényt ellenőrizhet a teljes végigjárás megismétlése helyett.