Защо UDP отговорът на OpenVPN излиза от грешен адрес

Клиент на OpenVPN набира един адрес, сървърът отговаря от друг и тунелът така и не се вдига. Журналът на сървъра показва пристигащия пакет, а записът на трафика — излизащ отговор, затова вината се стоварва върху клиента. На хост с няколко интерфейса или с няколко адреса на един интерфейс двете страни просто не са съгласни кой адрес се използва. Отговорът е коректен на ниво IP, но много клиенти изхвърлят датаграма, чийто източник не е адресът, до който са се обърнали.

Какво вижда клиентът, когато източникът се смени

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

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

Какво всъщност прави опцията multihome

Директивата се записва като multihome във файл за конфигурация и като --multihome на командния ред и кара UDP сървър да отговаря от адреса, до който е стигнал пакетът на клиента. Ядрото предава оригиналния адрес на местоназначението като допълнителни данни при приемането и OpenVPN използва тази стойност като източник на отговора. Така сървър, който слуша на общ адрес, local 0.0.0.0 за IPv4 или еквивалента му за IPv6, се държи сякаш всеки клиент е стигнал до отделен слушател. Клиентите, дошли през публичния адрес, получават отговори от публичния адрес, а клиентите на вътрешен адрес — от него. Нищо друго по пътя на пакета не се мести: маршрутът, правилата за филтриране и конфигурацията на тунела остават точно каквито са били.

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

Кога фиксираният локален адрес е грешната настройка по подразбиране

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

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

Докажете източника на отговора отвън

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

tcpdump -ni any udp port 1194
ss -lunp 'sport = :1194'
ip route get 203.0.113.10 from 198.51.100.20

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

Маршрутизацията, откриването и филтрирането остават отделни

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

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