UDP nuk është gjithmonë më i shpejtë: zgjedhja e transportit të OpenVPN

Çdo udhëzues thotë se UDP mund TCP për OpenVPN, dhe ky këshill është një parazgjedhje, jo një matje. Transporti ndryshon mënyrën se si dorëzohen paketat dhe çfarë ndodh kur rruga i hedh ato, jo mënyrën se si kriptohet tuneli. Pas një portali robërues ose një përfaqësuesi që lejon vetëm portën 443, opsioni më i ngadaltë është ai që lidhet qoftë edhe një herë. Ajo që vijon ndan atë që bën protokolli nga ajo që lejon rrjeti juaj i aksesit.

Çfarë ndryshon në të vërtetë transporti

TCP ofron një rrymë bajtesh të besueshme dhe të renditur dhe ritransmeton çdo gjë që humbet, siç përcakton RFC 9293. UDP i dorëzon datagramet rrjetit, dhe OpenVPN drejton shtresën e vet të besueshmërisë mbi atë socket. Inkapsulimi i TCP brenda TCP grumbullon dy cikle rikuperimi, prandaj një segment i humbur mund të mbajë rrymën e brendshme derisa të mbërrijë ritransmetimi i jashtëm. Ky ndërveprim është argumenti i vërtetë për UDP, dhe shfaqet si vonesë dhe jo si xhiro.

Efekti rritet me humbjen dhe kohën e udhëtimit vajtje-ardhje. Në një rrugë lokale të pastër të dy transportet ndihen njësoj, prandaj një test laboratori rrallë e riprodhon ankesën. Në një lidhje celulare të mbingarkuar diferenca duket në sesione interaktive shumë përpara se një transferim i madh të vërë re diçka.

Asnjë prej këtyre nuk prek konfidencialitetin ose integritetin. Dorëzimi TLS dhe shifra e kanalit të të dhënave janë të njëjta për të dy transportet, kështu që ndërrimi nuk mund të shpëtojë një grup shifrash të dobët.

Ku TCP e fiton vendin e vet

Rrjetet e aksesit janë arsyeja e zakonshme për të zgjedhur TCP. Një hotel, aeroport ose rrjet mysafirësh mund të lejojë 443 dalëse dhe të hedhë gjithçka tjetër, dhe një dëgjues TCP në atë portë është profili i vetëm që funksionon. Kjo është arritshmëri, jo performancë, dhe është arsye mjaft e mirë në vetvete.

TCP ndihmon edhe kur rruga është e qëndrueshme, por pajisjet e ndërmjetme janë armiqësore. Disa rrjete rivendosin rrymat UDP afatgjata ndërsa tolerojnë sesione TCP që ngjajnë me trafik normal web. Nëse ajo ngjashmëri ia del, është veti e rrjetit konkret, dhe asnjë udhëzues nuk mund ta premtojë për të gjithë. Testoni brenda rrjetit që dështon përpara se të fajësoni protokollin.

Një hyrje e refuzuar nuk është problem transporti. Çaktivizimi i verifikimit të certifikatës për të detyruar një lidhje është një ndryshim tjetër me një rezultat shumë më të keq.

Mbajtja gati e një profili TCP është kompromisi praktik. Shumica e klientëve ruajnë të dy dhe ju lejojnë të ndërroni kur një rrjet refuzon rrugën UDP, gjë që nuk kushton asgjë derisa t'ju duhet. Ajo që nuk duhet të bëni është të shpërndani dy profile që tregojnë pika fundore të ndryshme, sepse atëherë krahasimi juaj mat serverat.

Kontrolloni cilin dëgjues keni në të vërtetë

Përpara se të krahasoni performancën, konfirmoni që të dy skajet bien dakord për transportin dhe portën. Zëvendësimi i proto udp me proto tcp në një skedar klienti nuk krijon një dëgjues serveri. Serveri duhet të jetë konfiguruar për atë protokoll, dhe profili duhet t'i përputhet.

grep -E '^(proto|port|remote)' /etc/openvpn/server.conf
ss -lunp | grep openvpn
ss -ltnp | grep openvpn

grep shtyp atë që serverit iu tha të përdorte, ndërsa dy listat e socket-eve tregojnë se me çfarë është lidhur. Një dëgjues UDP shfaqet vetëm në listën e parë dhe një dëgjues TCP vetëm në të dytën, prandaj një rresht që mungon është mënyra më e shpejtë për të gjetur një profil që nuk u zbatua kurrë. Krahasoni edhe portën, sepse një profil TCP në 1194 sillet ndryshe nga një në 443 në shumicën e rrjeteve të aksesit. Rinisni shërbimin pas ndryshimit dhe lexoni rreshtin e regjistrit që raporton lidhjen.

Konfirmimi nga ana e klientit është i lirë: ekzekutoni lidhjen me --verb 4 dhe lexoni rreshtin e transportit në regjistër. Nëse klienti thotë UDP ndërsa serveri dëgjon në TCP, dorëzimi nuk fillon kurrë dhe asnjë rregullim nuk ndihmon.

Krahasoni ngarkesën e punës, jo etiketën e transportit

Një krahasim i drejtë mban gjithçka konstante përveç transportit. I njëjti pajisje, i njëjti rrjet aksesi, i njëjti host destinacioni, i njëjti aplikacion dhe në mënyrë ideale i njëjti server. Nëse dy profilet tregojnë hoste të ndryshëm, po matni edhe ata hoste.

Regjistroni tre rezultate për çdo ekzekutim: nëse tuneli krijohet, nëse qëndron dhe nëse detyra përfundon. Kërkesat e vogla që funksionojnë ndërsa transferimet e mëdha ngecin tregojnë madhësinë e paketës dhe MTU, jo transportin. Rilidhjet e përsëritura tregojnë rrugën ose një afat kohor të një pajisjeje të ndërmjetme.

Mbani profilin që funksionon në kushtet që hasni në të vërtetë, dhe ruani tjetrin. Zgjedhja i takon rrjetit, jo personit, prandaj çdo përgjigje e vetme parazgjedhur është e gabuar diku.