Ĉu TCP 443 vere helpas? Nur se la servilo aŭskultas tie

TCP 443 estas rezerva solvo kun antaŭkondiĉo, ne kamuflaĵo, kiu glitas tunelon preter ajna filtrilo. Ĝi helpas, kiam la funkciiganto jam publikigas TCP-aŭskultanton ĉe tiu pordo kaj la vojo toleras konekton, kiu restas malfermita dum horoj. Ĝi malsukcesas, kutime kiel tempolimo, kiam unu el la du mankas, kaj la tempolimo malofte diras kiu. Decidi, ĉu ŝanĝi, postulas tri demandojn, kaj nur unu el ili temas pri la pordnumero.

Pordnumero ne estas promeso pri transporto

Pordo nomas finpunkton; TCP igas ĝin ordigita bajtfluo; OpenVPN decidas, kio vojaĝas ene de tiu fluo. Reteja servilo ĉe la sama numero uzas tute alian aplikaĵan aranĝon, do la komuna pordo 443 igas la du similaj por filtrilo kaj nenio pli. La numero estas signo, kiun filtrilo legas, ne eco, kiu ŝanĝas tion, kion enhavas la pakaĵoj. Trakti la du kiel la saman ĉar ili dividas pordon estas la eraro malantaŭ la plejparto de la konfuzo ĉi tie.

Interaj aparatoj malofte faras simplan decidon permesi aŭ malpermesi pri pordo. Multaj ekzamenas la unuajn bajtojn, kelkaj fiksas celon, kaj kelkaj restarigas konektojn, kiuj restas malfermitaj tro longe. Tial la sama profilo povas funkcii el unu reto kaj tempolimi el alia, kaj tial indas testi rezervan solvon kiel subtenatan opcion anstataŭ fidi ĝin kiel promeson. Kiam filtrilo ekzamenas trafikon, la pordnumero estas nur la unua afero, kiun ĝi rigardas.

Konfirmu la aŭskultanton antaŭ ol tuŝi la profilon

La servilo devas esti agordita por TCP ĉe la pordo, kaj la klienta profilo devas peti la saman transporton. Reskribi UDP-profilon por peti TCP ne kreas la aŭskultanton, kaj la rezulta tempolimo ne distingiĝas de fajroŝirmilo, kiu forĵetas la pordon. Elŝutu la propran TCP-profilon de la funkciiganto, kiam ekzistas unu, ĉar kelkaj servoj publikigas apartan finpunkton kaj apartajn identecajn agordojn por ĉiu transporto. Mana redaktado estas bona por kontrolita testo kaj malbona maniero diveni la celitan agordon de provizanto.

La du flankoj de tiu kongruo aperas en la agordo, kaj la ligaj opcioj de la OpenVPN-projekto dokumentas ambaŭ formojn. La minimuma paro aspektas tiel:

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

Tri kondiĉoj decidas, ĉu la rezerva solvo valoras sian koston

La unua kondiĉo estas, ke la funkciiganto entute proponu la transporton; sen ĝi nenio alia gravas. La dua estas, ke la vojo tenu longdaŭran seancon viva, ĉar kelkaj retoj restarigas konektojn, kiuj restas malfermitaj, anstataŭ tute bloki la pordon. La tria estas, ĉu la rezerva solvo estas intenca escepto aŭ provizora solvo, kiu kaŝas difekton, kiun vi ne riparis.

Ĉiu kondiĉo havas malmultekostan kontrolon. Malsukceso ĉe ajna el ili aspektas same de la klienta flanko:

Antaŭ ol kompari transportojn, finu ajnan ensaluton ĉe kaptita portalo. Reto, kiu ne akceptis vian aparaton, blokas ambaŭ transportojn, kaj tiam la komparo mezuras la portalon anstataŭ la tunelon. Ensalutu, konfirmu, ke ordinara retumo funkcias, kaj nur poste komencu la teston.

La kosto, kiun vi akceptas: TCP ene de TCP

TCP reelsendas perditajn segmentojn kaj konservas ilian ordon. Kiam aplikaĵo, kiu ankaŭ uzas TCP, funkcias ene de TCP-tunelo, du riparaj tavoloj reagas al la sama perdo, kaj ĝuste tiu interago igas la tunelon sentiĝi malrapida sur vojo kun perdoj. La simptomo estas prokrasto kaj jitter anstataŭ pura malsukceso, kio faciligas kulpigi la malproksiman finon. Mezuru de la klienta flanko sub ambaŭ transportoj antaŭ ol konkludi.

UDP evitas tiun nestadon, kaj tio estas la ĉefa kialo, kial funkciigantoj preferas ĝin kaj proponas TCP nur kiel alternativon. Stabila TCP-konekto ankoraŭ pli utilas ol neatingebla UDP-konekto, do la komparo estas inter du realaj kostoj, ne inter bona kaj malbona opcio. Tenu la aparaton kaj la alirreton senŝanĝaj dum vi komparas, alie la rezulto priskribas la malĝustan variablon.

Kelkaj klientaj trajtoj estas dokumentitaj nur por unu transporto, do rezerva profilo povas silente forlasi konduton, kiun vi bezonis. Legu la transportan postulon de la opcio antaŭ ol trakti la TCP-profilon kiel simplan anstataŭigon.

Difektoj, kiujn alia transporto ne tuŝas

Eksdata atestilo ankoraŭ bezonas horloĝan kontrolon aŭ renovigon, kaj rifuzita konto ankoraŭ bezonas la ĝustajn legitimilojn. Konservu la servilidentecajn kontrolojn, kiujn la funkciiganto donis, ĉar konata pordnumero aŭtentikigas neniun. Pordo, kiu respondas, diras nur ke io aŭskultas.

Se la tunelo ekfunkcias kaj celoj ankoraŭ malsukcesas, la restanta problemo estas enkursigado aŭ nomresolvo post la konekto, ne la transporto. Sekvu tiun vojon anstataŭ cikli tra pordoj, ĉar tiel perdiĝas posttagmezo. La profilo diras al vi, kiun transporton provi; ĝi neniam diras, kial la UDP-vojo malsukcesis.