UDP не е секогаш побрз: избор на транспортот на OpenVPN

Секој водич вели дека UDP е подобар од TCP за OpenVPN, а тој совет е стандардно поставување, не мерење. Транспортот менува како се доставуваат пакетите и што се случува кога патот ги фрла, а не како се шифрира тунелот. Зад заробен портал или прокси што дозволува само порта 443, побавната опција е онаа што воопшто се поврзува. Следното го одделува она што го прави протоколот од она што го дозволува вашата пристапна мрежа.

Што всушност менува транспортот

TCP доставува сигурен, подреден тек од бајти и повторно го праќа сето изгубено, како што одредува RFC 9293. UDP ги предава датаграмите на мрежата, а OpenVPN води сопствен слој за сигурност над тој сокет. Вгнездувањето на TCP во TCP наредува две јамки за обнова, па еден изгубен сегмент може да го задржи внатрешниот тек додека не пристигне надворешното повторно праќање. Токму таа интеракција е вистинскиот аргумент за UDP и се појавува како доцнење, а не како пропусност.

Ефектот расте со загубите и времето на одење и враќање. На чист локален пат двата транспорта се чувствуваат исто, затоа лабораторискиот тест ретко ја повторува поплаката. На пренатоварена мобилна врска разликата се гледа во интерактивни сесии многу пред големиот пренос да забележи нешто.

Ништо од ова не ја допира доверливоста или интегритетот. Ракувањето TLS и шифрата на податочниот канал се исти за двата транспорта, така што префрлањето не може да спаси слаб збир на шифри.

Каде TCP го заслужува своето место

Пристапните мрежи се вообичаената причина да се избере TCP. Хотел, аеродром или гостинска мрежа може да дозволува излезна 443 и да го отфрла сето друго, а TCP слушател на таа порта е единствениот профил што работи. Тоа е достапност, а не перформанси, и само по себе е доволно добра причина.

TCP помага и кога патот е стабилен, но посредните уреди се непријателски. Некои мрежи ресетираат долготрајни UDP текови додека толерираат TCP сесии што личат на обичен веб сообраќај. Дали таа сличност успева е својство на конкретната мрежа и ниеден водич не може да го вети за сите. Тестирајте внатре во мрежата што не успева пред да го обвините протоколот.

Одбиеното најавување не е транспортен проблем. Исклучувањето на проверката на сертификатот за да се пробие врската е друга промена со многу полош исход.

Држењето подготвен TCP профил е практичниот компромис. Повеќето клиенти ги чуваат двата и дозволуваат префрлање кога мрежата го одбива UDP патот, што не чини ништо додека не ви треба. Она што не треба да го правите е да испорачате два профила насочени кон различни крајни точки, зашто тогаш споредбата ги мери серверите.

Проверете кој слушател всушност го имате

Пред да споредувате перформанси, потврдете дека двата краја се согласуваат за транспортот и портата. Менувањето на proto udp во proto tcp во клиентска датотека не создава серверски слушател. Серверот мора да биде конфигуриран за тој протокол, а профилот мора да се совпаѓа со него.

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

grep го печати она што му е кажано на серверот да го користи, додека двата списка на сокети покажуваат на што е врзан. UDP слушател се појавува само во првиот список, а TCP слушател само во вториот, така што линијата што недостасува е најбрзиот начин да се најде профил што никогаш не бил применет. Споредете ја и портата, зашто TCP профилот на 1194 се однесува поинаку од оној на 443 во повеќето пристапни мрежи. По промената рестартирајте ја услугата и прочитајте ја линијата во дневникот што известува за поврзувањето.

Потврдата на страната на клиентот е евтина: стартувајте ја врската со --verb 4 и прочитајте ја линијата за транспортот во дневникот. Ако клиентот вели UDP додека серверот слуша на TCP, ракувањето никогаш не започнува и никакво дотерување не помага.

Споредете го работното оптоварување, не ознаката на транспортот

Праведната споредба држи сето друго постојано освен транспортот. Ист уред, иста пристапна мрежа, ист целен домаќин, иста апликација и идеално ист сервер. Ако двата профила покажуваат на различни домаќини, ги мерите и тие домаќини.

Забележете три исходи за секое стартување: дали тунелот се воспоставува, дали останува и дали задачата се завршува. Малите барања што работат додека големите преноси заглавуваат укажуваат на големината на пакетот и MTU, а не на транспортот. Повторените повторни поврзувања укажуваат на патот или на истекот на времето на посреден уред.

Задржете го профилот што работи во условите со кои навистина се среќавате, а другиот зачувајте го. Изборот им припаѓа на мрежата, не на човекот, и затоа секој единствен стандарден одговор е некаде погрешен.