Помага ли наистина TCP 443? Само ако сървърът слуша на този порт
TCP профилът е резервен вариант, а не маскировка. Проверете дали сървърът слуша на този порт и след това претеглете двойната цена на TCP срещу недостъпност.
TCP 443 е резервен вариант с предварително условие, а не маскировка, която промъква тунел през всеки филтър. Той помага, когато операторът вече публикува TCP слушател на този порт и пътят понася връзка, която остава отворена с часове. Той се проваля, обикновено като изчакване, когато едно от двете липсва, и изчакването рядко казва кое. Решението дали да превключите изисква три въпроса и само един от тях е за номера на порта.
Номерът на порта не е обещание за транспорт
Портът именува крайна точка; TCP го превръща в подреден поток от байтове; OpenVPN решава какво пътува в този поток. Уеб сървър на същия номер използва напълно различна програмна уредба, така че споделеният порт 443 ги прави подобни за филтъра и нищо повече. Номерът е подсказка, която филтърът чете, а не свойство, което променя съдържанието на пакетите. Да ги третирате като едно и също, защото делят порт, е грешката зад повечето объркване тук.
Междинните устройства рядко вземат просто решение „разреши или забрани“ за даден порт. Много от тях преглеждат първите байтове, някои заковават дестинация, а други нулират връзки, които остават отворени твърде дълго. Затова един и същ профил може да работи от една мрежа и да изтече от друга и затова резервният вариант заслужава тестване като поддържана опция, а не доверие като обещание. Когато филтърът преглежда трафика, номерът на порта е само първото, към което гледа.
Потвърдете слушателя, преди да пипате профила
Сървърът трябва да е конфигуриран за TCP на порта, а клиентският профил трябва да поиска същия транспорт. Пренаписването на UDP профил да иска TCP не създава слушателя и полученото изчакване е неразличимо от защитна стена, която изхвърля порта. Изтеглете собствения TCP профил на оператора, когато има такъв, защото някои услуги публикуват отделна крайна точка и отделни настройки за идентичност за всеки транспорт. Ръчното редактиране е добро за контролиран тест и лош начин да гадаете каква конфигурация е имал предвид доставчикът.
Двете страни на това съответствие се виждат в конфигурацията и опциите за връзка на проекта OpenVPN документират двете форми. Минималната двойка изглежда така:
# server: accept TCP on this port
proto tcp-server
port 443
# client: request the same transport
proto tcp
remote vpn.example.com 443Три условия решават дали резервният вариант си заслужава цената
Първото условие е операторът изобщо да предлага транспорта; без него нищо друго няма значение. Второто е пътят да поддържа дълготрайна сесия, тъй като някои мрежи нулират връзки, които остават отворени, вместо да блокират порта напълно. Третото е дали резервният вариант е умишлено изключение, или заобиколно решение, което крие дефект, който не сте отстранили.
Всяко условие има евтина проверка. Провал при което и да е от тях изглежда еднакво от страна на клиента:
| 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 |
Преди да сравнявате транспортите, завършете всяко влизане през портал за прихващане. Мрежа, която не е допуснала устройството ви, блокира и двата транспорта и тогава сравнението измерва портала, а не тунела. Влезте, потвърдете, че обикновеното сърфиране работи, и едва след това започнете теста.
Цената, която приемате: TCP в TCP
TCP препредава загубените сегменти и запазва реда им. Когато приложение, което също използва TCP, работи в TCP тунел, два слоя за възстановяване реагират на една и съща загуба и точно това взаимодействие прави тунела да изглежда бавен по път със загуби. Симптомът е закъснение и трептене, а не чист провал, което улеснява обвиняването на далечната страна. Измерете от клиента при двата транспорта, преди да правите извод.
UDP избягва това вграждане и това е основната причина операторите да го предпочитат и да предлагат TCP само като алтернатива. Стабилна TCP връзка все пак е по-полезна от недостъпна UDP връзка, така че сравнението е между две реални цени, а не между добър и лош вариант. Дръжте устройството и мрежата за достъп непроменени, докато сравнявате, иначе резултатът описва грешната променлива.
Някои клиентски функции са документирани само за един транспорт, така че резервен профил може тихо да изхвърли поведение, на което сте разчитали. Прочетете изискването на опцията за транспорт, преди да приемете TCP профила за проста замяна.
Повреди, които друг транспорт не докосва
Изтекъл сертификат все още изисква проверка на часовника или подновяване, а отхвърлен акаунт все още изисква правилните идентификационни данни. Пазете проверките за идентичност на сървъра, които операторът е дал, защото познат номер на порт не удостоверява никого. Порт, който отговаря, казва само че нещо слуша.
Ако тунелът се вдигне, а дестинациите продължават да се провалят, оставащият проблем е маршрутизация или разрешаване на имена след връзката, а не транспортът. Следвайте този път, вместо да въртите портове, защото точно така изчезва един следобед. Профилът ви казва кой транспорт да опитате; той никога не казва защо UDP пътят се е провалил.