MULTI: невалиден адрес на източник от клиент: чий беше този адрес?

Сървърният журнал отпечатва MULTI: bad source address from client, изхвърля пакета, а сесията остава свързана. Тази комбинация обърква хората, които четат съобщението като неуспешно удостоверяване. Не е така: клиентът се е удостоверил, а пристигналият пакет е носил вътрешен адрес на източник, който сървърът не е могъл да свърже с този екземпляр на клиента. Проверката се извършва преди доставянето, затова тунелът изглежда здрав, докато нищо полезно не преминава през него.

Какво сравнява сървърът преди доставяне

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

Обикновено доставяне през интерфейса на тунела никога не се случва.

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

Три източника на несъответстващ вътрешен адрес

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

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

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

LAN зад клиента и iroute

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

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

# /etc/openvpn/server/ccd/site-b
iroute 192.168.70.0 255.255.255.0

Потвърдете, че ефективната идентичност съвпада с името на файла, тъй като несъответствие означава, че файлът никога не се зарежда, а симптомът е идентичен с липсващ запис. Не добавяйте широк iroute, за да заглушите предупреждението, защото това превръща неочакван източник в разрешен, без да отговаря защо клиентът го е изпратил. В ръководството за OpenVPN 2.6 са описани iroute, duplicate-cn и съпоставянето на идентичност като отделни контроли.

Една и съща идентичност на две машини

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

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

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

Докажете, че свързването е променено

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

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

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