Трябва ли вашият клиент на OpenVPN да използва nobind или фиксиран порт?

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

Какво всъщност пропуска nobind

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

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

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

Три условия, които го решават

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

Този партньор ли инициира връзката? Ако осъществява изходяща връзка, динамичният порт на източника е безвреден и обикновено за предпочитане, защото отговорът следва същия поток обратно. Ако чака входящи връзки, динамичният порт го прави недостъпен, освен ако нещо отпред не публикува порта. Този един отговор разделя всеки клиентски профил от всеки сървърен.

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

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

Където закрепеният порт е правилният отговор

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

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

Сървърът и клиентът не са симетрични

Ръководството на OpenVPN 2.6 поставя nobind до lport, което е аргументът в един ред: едната опция казва, че ядрото избира, другата — че вие избирате. Динамичният локален порт работи само за партньора, който осъществява връзка, защото отговарящата страна не може да знае порта предварително. Затова копирането на клиентски профил върху сървър създава слушател, до когото никой не може да достигне.

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

Обобщението е за роли, а не за сигурност: който осъществява връзка, може да е гъвкав относно собствения си източник, а който отговаря, не може. Нито един избор не променя това, което другият край научава за самоличността ви. Затова директивата се среща в клиентски примери и почти никога в сървърни.

Проверете порта, който ядрото избра

След свързване четете сокета, а не конфигурацията, защото конфигурацията заявява намерение, а сокетът — какво се е случило. Фактите, които си струва да запишете, са локалният порт, отдалечената крайна точка и дали нещо още слуша. На Linux хост и трите са на една команда разстояние.

ss -unp | grep openvpn
ss -lunp | grep openvpn
sudo lsof -nP -i | grep openvpn

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