Ar TCP 443 tikrai padeda? Tik jei serveris ten klausosi
TCP profilis yra atsarginis kelias, o ne maskuotė. Patikrinkite, ar serveris klausosi to prievado, tada pasverkite dvigubo TCP kainą prieš nepasiekiamumą.
TCP 443 yra atsarginis kelias su išankstine sąlyga, o ne maskuotė, praleidžianti tunelį pro bet kurį filtrą. Jis padeda, kai operatorius jau skelbia TCP klausytoją tame prievade ir kelias atlaiko ryšį, kuris lieka atviras valandų valandas. Jis nepavyksta, dažniausiai kaip laukimo riba, kai trūksta vieno iš dviejų, o laukimo riba retai pasako, kurio. Sprendimas keisti reikalauja trijų klausimų, ir tik vienas jų apie prievado numerį.
Prievado numeris nėra transporto pažadas
Prievadas įvardija galinį tašką; TCP paverčia jį tvarkingu baitų srautu; OpenVPN nusprendžia, kas keliauja tame sraute. To paties numerio žiniatinklio serveris naudoja visiškai kitokią programos sandarą, todėl bendras 443 prievadas daro juos du panašius filtrui ir nieko daugiau. Numeris yra užuomina, kurią filtras skaito, o ne savybė, keičianti tai, ką talpina paketai. Laikyti juos vienu todėl, kad jie dalijasi prievadu, yra klaida, slypinti už didžiosios dalies čia tykančios painiavos.
Tarpinės dėžės retai priima paprastą leisti-ar-drausti sprendimą dėl prievado. Daugelis tikrina pirmuosius baitus, kai kurios prisega paskirties vietą, o kai kurios atstato ryšius, kurie lieka atviri per ilgai. Štai kodėl tas pats profilis gali veikti iš vieno tinklo ir pasiekti laukimo ribą kitame, ir štai kodėl atsarginį kelią verta bandyti kaip palaikomą parinktį, o ne pasitikėti juo kaip pažadu. Kai filtras tikrina srautą, prievado numeris yra tik pirmas dalykas, į kurį jis žiūri.
Patvirtinkite klausytoją prieš liesdami profilį
Serveris turi būti sukonfigūruotas TCP tam prievadui, o kliento profilis turi prašyti to paties transporto. UDP profilio perrašymas prašant TCP nesukuria klausytojo, o atsiradusi laukimo riba neatskiriama nuo ugniasienės, kuri meta prievadą. Atsisiųskite operatoriaus paties TCP profilį, kai toks yra, nes kai kurios paslaugos skelbia atskirą galinį tašką ir atskirus tapatybės nustatymus kiekvienam transportui. Rankinis redagavimas tinka kontroliuojamam bandymui ir yra blogas būdas spėlioti tiekėjo numatytą konfigūraciją.
Abi tos atitikties pusės matomos konfigūracijoje, o OpenVPN projekto ryšio parinktys dokumentuoja abi formas. Minimali pora atrodo taip:
# server: accept TCP on this port
proto tcp-server
port 443
# client: request the same transport
proto tcp
remote vpn.example.com 443Trys sąlygos nusprendžia, ar atsarginis kelias vertas savo kainos
Pirmoji sąlyga yra ta, kad operatorius apskritai siūlo šį transportą; be jos niekas kitas nesvarbu. Antroji – kad kelias išlaiko ilgalaikę sesiją gyvą, nes kai kurie tinklai atstato ryšius, kurie lieka atviri, o ne užblokuoja prievadą visiškai. Trečioji – ar atsarginis kelias yra sąmoninga išimtis, ar laikina išeitis, slepianti gedimą, kurio nesutvarkėte.
Kiekviena sąlyga turi pigų patikrinimą. Bet kurios jų nesėkmė iš kliento pusės atrodo vienodai:
| Condition | How to check it | What a failure decides |
|---|---|---|
| The server offers TCP | The operator's profile list, or a listening-socket check on the server | No client-side edit can help |
| The path keeps long sessions | A test connection left open for an hour | Reconnects will look like server faults |
| The fallback is deliberate | A change record naming the UDP fault | The underlying fault stays invisible |
Prieš lygindami transportus, užbaikite bet kokį prisijungimą prie belaisvio portalo. Tinklas, kuris neįsileido jūsų įrenginio, blokuoja abu transportus, ir tada palyginimas matuoja portalą, o ne tunelį. Prisijunkite, patvirtinkite, kad įprastas naršymas veikia, ir tik tada pradėkite bandymą.
Kaina, kurią priimate: TCP TCP viduje
TCP perduoda prarastus segmentus iš naujo ir išsaugo jų tvarką. Kai programa, kuri taip pat naudoja TCP, veikia TCP tunelio viduje, du atkūrimo sluoksniai reaguoja į tą patį praradimą, ir būtent ši sąveika daro tunelį lėtą kelyje su praradimais. Simptomas yra vėlavimas ir virpėjimas, o ne švarus gedimas, todėl lengva kaltinti tolimąjį galą. Matuokite iš kliento pusės abiem transportais prieš darydami išvadą.
UDP išvengia šio įdėjimo, ir tai yra pagrindinė priežastis, kodėl operatoriai jam teikia pirmenybę, o TCP siūlo tik kaip alternatyvą. Stabilus TCP ryšys vis dar naudingesnis už nepasiekiamą UDP ryšį, todėl palyginimas vyksta tarp dviejų realių kainų, o ne tarp geros ir blogos parinkties. Lygindami laikykite įrenginį ir prieigos tinklą nepakitusius, kitaip rezultatas aprašys ne tą kintamąjį.
Kai kurios kliento funkcijos dokumentuotos tik vienam transportui, todėl atsarginis profilis gali tyliai numesti elgseną, kuria rėmėtės. Perskaitykite parinkties transporto reikalavimą prieš laikydami TCP profilį paprastu pakeitimu.
Gedimai, kurių kitas transportas neliečia
Pasibaigęs sertifikatas vis dar reikalauja laikrodžio patikros ar atnaujinimo, o atmesta paskyra vis dar reikalauja teisingų prisijungimo duomenų. Išsaugokite operatoriaus pateiktas serverio tapatybės patikras, nes pažįstamas prievado numeris nieko neautentifikuoja. Atsakantis prievadas tik pasako, kad kažkas klausosi.
Jei tunelis pakyla, o paskirties vietos vis dar nepavyksta, likusi problema yra maršrutizavimas arba vardų sprendimas po ryšio, o ne transportas. Eikite tuo keliu, o ne sukite ratu per prievadus, nes taip dingsta popietė. Profilis pasako, kurį transportą išbandyti; jis niekada nepasako, kodėl UDP kelias nepavyko.