OpenVPN: локален адрес срещу адрес на тунела — два различни сокета

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

Грешката при обвързване назовава локален адрес

Когато OpenVPN съобщи, че не може да обвърже локален адрес, той говори за транспортния сокет: крайната точка UDP или TCP, която носи криптираната връзка към партньора.

Явна директива local иска от демона да обвърже този сокет към конкретен локален адрес. Адресът трябва да съществува в мрежовото пространство от имена, където работи процесът, и трябва да може да бъде зададен в момента на стартиране на клиента.

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

Какво всъщност избират local и remote

remote назовава партньора, с когото да се свържем. local обвързва близкия край на същия сокет. nobind оставя операционната система да избере както локалния адрес, така и порта, поради което клиентите зад домашни рутери обикновено работят без нито една от двете директиви.

Нито една от директивите няма нищо общо с адреса вътре в тунела.

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

ip -brief address show
ip route get 203.0.113.10

Вътрешният адрес идва от сървъра

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

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

Интерфейсите, които трябва да се четат, също са различни. Параметрите ifconfig и конфигурацията на пула описват вътрешността, докато remote, local, proto и nobind описват външността. Разделянето на двата списъка обяснява почти всеки объркващ пример, който ще намерите във форум. Ръководството на OpenVPN 2.6 ги документира в отделни раздели точно поради тази причина.

Капанът: пълен тунел, който улавя собствения си транспорт

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

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

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

Навик, който предотвратява объркването

Прочетете всеки адрес в профила и решете към кой слой принадлежи, преди да го редактирате.

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

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