Изисквания за портове на VPN: три реда, които се пишат преди сравнение

Списъците с портове за VPN услуги се копират между страници за сравнение без подробността, която решава дали имат значение: кой започва връзката. Правило, което разрешава изходящ TCP 443, не казва нищо за това дали друг хост може да достигне слушател на вашата машина. Напишете три отделни изисквания, преди да сравните дори един план, и отбележете кои от тях вашата задача наистина изисква. Повечето сравнения се свиват до един кратък въпрос, щом такъв лист съществува.

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

Три реда покриват почти всеки случай: достигане на дестинация отвъд тунела, публикуване на нещо, за да могат други да се свържат, и пренасяне на самия тунел. Всеки ред се проваля по различна причина и политика на доставчик, която удовлетворява един, може да остави другите два незасегнати. Подреждането на задачата ви в правилния ред отнема пет минути и спестява спор по-късно.

Маркетинговите твърдения замъгляват трите реда нарочно. Разрешението за P2P описва политика за дестинации, отделеният адрес описва адрес, а твърдението за липса на ограничения на портове обикновено означава, че планът не ги изброява. Никоя от тези фрази не отговаря на другите.

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

Изходящият достъп се проваля заради политика за дестинации, не заради тунела

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

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

Измерете, преди да спорите. Изпълнете това на машината, която ще стои зад тунела, веднъж с изключен тунел и веднъж с включен:

ss -lntup | sort
nc -vz -w 3 203.0.113.10 443
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://example.com

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

Входящото публикуване изисква преобразуване, адрес и срок на живот

Нищо отвън не може да започне връзка към вашия слушател, освен ако нещо от публичната страна не знае къде да я достави. Статична резервация на порт, държана от оператора, преобразуване по заявка на клиента през UPnP, NAT-PMP или PCP, и маршрутизиран публичен адрес са три различни продукта с три различни ограничения.

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

Потвърдете първо локалната половина, защото мъртъв слушател и блокиран входящ път изглеждат отвън еднакво:

ss -lntup | grep -E ':(8080|51820)\b'
python3 -m http.server 8080 --bind 0.0.0.0
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080

Когато локалната заявка върне 200, а заявка от мрежа, която не контролирате, все още изтича по време, разликата е от публичната страна. Това е моментът да назовете на оператора протокол и външен порт, вместо да описвате приложението по име.

Собственият транспорт на тунела е отделен въпрос

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

Мрежа, която изхвърля изходящ UDP, ще приеме тунел TCP 443 и ще откаже UDP, затова резервен режим принадлежи на листа с изисквания. Смяната на носителя не мести порт на приложение вътре в тунела и не разширява политика за дестинации; те остават на собствените си редове.

Фрагментацията заслужава една проверка, докато сте там, защото тунел, който се свързва и после засича при големи преноси, обикновено има грешен MTU, а не затворен порт:

ping -M do -s 1400 203.0.113.10
ping -M do -s 1372 203.0.113.10

В Windows същата проверка е ping -f -l 1400 203.0.113.10. Задайте MTU на тунела под най-големия размер, който минава, после тествайте отново преноса, който се провали.

Проверете трите реда, преди да платите за план

Сложете трите реда на една страница и попълнете всяка клетка с измерен резултат вместо обещание. Тези команди дават локалната половина на тази страница за около минута:

ss -lntup | sort
nc -vz -w 3 203.0.113.10 443
python3 -m http.server 8080 --bind 0.0.0.0
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080
ping -M do -s 1400 203.0.113.10

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

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