Tényleg segít a TCP 443? Csak ha a kiszolgáló ott figyel

A TCP 443 egy előfeltétellel járó tartalék megoldás, nem álca, amely bármely szűrő mellett átcsúsztat egy alagutat. Akkor segít, ha a szolgáltató már közzétett egy TCP-figyelőt azon a porton, és az útvonal elvisel egy órákig nyitva maradó kapcsolatot. Akkor viszont elbukik, általában időtúllépésként, ha valamelyik hiányzik, és az időtúllépés ritkán mondja meg, melyik. A váltás eldöntéséhez három kérdés kell, és ezek közül csak egy szól a portszámról.

A portszám nem szállítási ígéret

A port egy végpontot nevez meg; a TCP rendezett bájtfolyammá alakítja; OpenVPN dönti el, mi utazik abban a folyamban. Egy webszerver ugyanazon a számon teljesen más alkalmazáselrendezést használ, ezért a 443-as port közös használata csak hasonlóvá teszi a kettőt egy szűrő számára, és semmi többet. A szám egy nyom, amelyet a szűrő olvas, nem olyan tulajdonság, amely megváltoztatja, mit tartalmaznak a csomagok. Az, hogy azonosnak tekintjük őket, mert közös portot használnak, az a hiba, amely az itteni zavar nagy része mögött áll.

A köztes eszközök ritkán hoznak egyszerű engedélyez-vagy-tilt döntést egy portról. Sokuk az első bájtokat vizsgálja, némelyik célpontot rögzít, és némelyik visszaállítja a túl sokáig nyitva maradó kapcsolatokat. Ezért működhet ugyanaz a profil az egyik hálózatból és futhat időtúllépésbe a másikból, és ezért érdemes a tartalék megoldást támogatott lehetőségként tesztelni, nem pedig ígéretként megbízni benne. Amikor egy szűrő vizsgálja a forgalmat, a portszám csak az első dolog, amire néz.

Erősítse meg a figyelőt, mielőtt a profilhoz nyúl

A kiszolgálót TCP-re kell beállítani a porton, és az ügyfélprofilnak ugyanazt a szállítást kell kérnie. Egy UDP-profil átírása TCP kérésére nem hozza létre a figyelőt, és az így kapott időtúllépés nem különböztethető meg egy portot eldobó tűzfaltól. Töltse le a szolgáltató saját TCP-profilját, ha van ilyen, mert egyes szolgáltatások külön végpontot és külön identitásbeállításokat tesznek közzé minden szállításhoz. A kézi szerkesztés jó egy ellenőrzött teszthez, és rossz módja a szolgáltató szándékolt beállításának kitalálására.

Az egyezés két oldala a konfigurációban látszik, és az OpenVPN-projekt összekapcsolási beállításai mindkét formát dokumentálják. A minimális pár így néz ki:

# server: accept TCP on this port
proto tcp-server
port 443
# client: request the same transport
proto tcp
remote vpn.example.com 443

Három feltétel dönti el, hogy megéri-e a tartalék

Az első feltétel, hogy a szolgáltató egyáltalán kínálja a szállítást; enélkül semmi más nem számít. A második, hogy az útvonal életben tart egy hosszú élettartamú munkamenetet, mivel egyes hálózatok visszaállítják a nyitva maradó kapcsolatokat, ahelyett hogy a portot egyenesen blokkolnák. A harmadik, hogy a tartalék szándékos kivétel-e, vagy olyan kerülő megoldás, amely elrejt egy Ön által nem javított hibát.

Minden feltételnek van egy olcsó ellenőrzése. Bármelyikük kudarca az ügyfél felől ugyanúgy néz ki:

Mielőtt összehasonlítja a szállításokat, fejezzen be minden bejelentkezést egy fogoly portálon. Egy hálózat, amely nem engedte be az eszközét, mindkét szállítást blokkolja, és akkor az összehasonlítás a portált méri, nem az alagutat. Jelentkezzen be, erősítse meg, hogy a szokásos böngészés működik, és csak utána kezdje el a tesztet.

Az ár, amelyet elfogad: TCP a TCP-ben

A TCP újraküldi az elveszett szegmenseket, és megőrzi sorrendjüket. Amikor egy szintén TCP-t használó alkalmazás TCP-alagúton belül fut, két helyreállítási réteg reagál ugyanarra a veszteségre, és ez a kölcsönhatás teszi lassúvá az alagutat a veszteséges útvonalon. A tünet késleltetés és remegés, nem tiszta meghibásodás, ami megkönnyíti a távoli vég hibáztatását. Mérjen az ügyfél felől mindkét szállítás alatt, mielőtt következtetést von le.

Az UDP elkerüli ezt a beágyazást, és ez a fő oka annak, hogy a szolgáltatók előnyben részesítik, és a TCP-t csak alternatívaként kínálják. Egy stabil TCP-kapcsolat továbbra is hasznosabb, mint egy elérhetetlen UDP-kapcsolat, tehát az összehasonlítás két valódi költség között zajlik, nem jó és rossz lehetőség között. Összehasonlítás közben tartsa változatlanul az eszközt és a hozzáférési hálózatot, különben az eredmény a rossz változót írja le.

Egyes ügyfélfunkciók csak egy szállításhoz vannak dokumentálva, ezért egy tartalék profil csendben elhagyhat olyan viselkedést, amelyre támaszkodott. Olvassa el a lehetőség szállítási követelményét, mielőtt a TCP-profilt egyszerű cserének tekinti.

Hibák, amelyekhez más szállítás nem nyúl

A lejárt tanúsítvány továbbra is óraellenőrzést vagy megújítást igényel, az elutasított fiók pedig továbbra is a helyes hitelesítő adatokat igényli. Tartsa meg a szolgáltató által adott kiszolgáló-identitás ellenőrzéseket, mert egy ismerős portszám senkit nem hitelesít. Egy válaszoló port csak azt mondja, hogy valami figyel.

Ha az alagút feljön, és a célok továbbra is hibáznak, a fennmaradó probléma a kapcsolat utáni útválasztás vagy névfeloldás, nem a szállítás. Kövesse azt az utat ahelyett, hogy portokat próbálgatna, mert így tűnik el egy délután. A profil megmondja, melyik szállítást próbálja; soha nem mondja meg, miért hibázott az UDP-útvonal.