proto udp или tcp-client: кой от двата чува сървърът ви?

Профил, който работеше миналия месец, сега изтича по таймаут и някой предлага да смените proto udp с proto tcp-client. Понякога това е правилният ход, а понякога се получава клиент, който се свързва с порт, където нищо не слуша, защото сървърът никога не е бил настроен за другия транспорт. Директивата описва как говори вашата страна; тя не може да създаде слушател в отсрещната. Прочетете профила и сървъра заедно, преди да променяте което и да е от двете.

Прочетете транспорта, който използва избраната връзка

Профилът може да носи няколко записа remote и всеки от тях да посочва свой транспорт. Клиентът ги обхожда по ред, така че редът, който виждате първи, не е непременно приложимият.

Намерете записа, който действително се опитва, после прочетете транспорта му. Редът е важен, защото клиентът не преминава към следващия безшумно. Някои сборки опитват следващия запис само след таймаут, така че работеща алтернатива в края на файла се достига секунди по-късно, отколкото очаквате. Следете в дневника крайната точка, която се опитва, вместо да предполагате, че първият ред е спечелил.

Ако файлът има един ред proto близо до началото и няколко записа remote под него, този ред е стойността по подразбиране за всеки remote, който не я отменя. Локална промяна на стойността по подразбиране не прави нищо за запис remote, който посочва своя транспорт.

grep -nE '^(remote|proto)\b' client.ovpn

UDP и TCP не са настройка за скорост

UDP изпраща дейтаграми, без да изгражда подреден поток, затова собственият трафик на тунела не се обвива във втори надежден транспорт. TCP ви дава път през мрежи, които изхвърлят или блокират UDP, срещу цената на вложени повторни предавания, които могат да направят загубена връзка да се усеща по-зле.

Това е компромис за достъпност, а не универсална класация. Правилният избор е този, който мрежата пред клиента позволява. Път, който изхвърля UDP на VPN порта, никога няма да преговаря, колкото и добре да е написан профилът. Тествайте пътя, после изберете транспорта.

Изборът между тях само по резултат от измерване е грешка, защото отговорът зависи от това какво позволява мрежата пред вас. Хотел или корпоративно прокси може да позволява изходящ TCP на 443 и нищо друго, затова доставчиците предлагат този вариант. Това остава връзка OpenVPN на този порт, а не HTTPS сесия, дори номерът на порта да е познатият.

Какво всъщност означава tcp-client

Директивата от страна на клиента назовава иницииращата страна на TCP връзка. Сървърната страна използва своята форма за слушане и копирането на думата на клиента в сървърна конфигурация създава слушател, който очаква да бъде набиран, а не такъв, който приема.

Съвпадението означава, че двете страни се съгласяват за транспорта, а не че споделят един и същ низ.

grep -nE '^proto\b' /etc/openvpn/server/server.conf
ss -lntp | grep openvpn

Попитайте сървъра на какво слуша, преди да приемете, че профилът е грешен. UDP слушател не се появява в списък на TCP сокети и обратното също е вярно, затова проверявайте изгледа, специфичен за протокола, а не общия.

Когато профилът се импортира, но никога не се свързва

Импортиран профил, който веднага изтича по таймаут, обикновено се проваля преди каквато и да е автентикация. Пакетът отива към порт без слушател или мрежата го изхвърля безшумно.

Тествайте пътя по най-простия възможен начин: свържете се със същия хост и порт с транспорта, който профилът твърди, от същата мрежа като клиента, който се проваля.

Ако UDP проба не получи нищо, а TCP проба се свърже, сървърът предлага другия транспорт и профилът просто е остарял. Ако нито една не отговори, проблемът е над избора на транспорт и никаква промяна в профила няма да го поправи. Различаването на тези два случая отнема минута и спестява час от отстраняване на грешки със сертификати, което никога не е било уместно.

Запишете работещия транспорт

Щом комбинация заработи, запишете я със сървъра, порта и протокола и отбележете от коя мрежа е тествана.

Иначе следващият човек, който попадне на таймаут, ще опита същия експеримент в обратната посока и може би ще промени сървър, който е бил наред.

Ако доставчикът публикува и двата варианта, пазете и двата файла и ги обозначете според мрежата, за която са подходящи. Два ясно именувани профила предотвратяват случайното смесване на клиентски транспорт със сървърен слушател, който никога не е бил настроен за него.