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 и мапирањето на идентитетот како одделни контроли.

Истиот идентитет на две машини

Профилот копиран на втор лаптоп го носи истиот сертификат и истото заедничко име. Во зависност од поставките на серверот, поновата врска може да ја замени постарата, а проверката за поврзување ја добива изданието што ја има сопственоста.

Тоа го прави дефектот да изгледа повремен и се појавува само кога двата уреда се будни.

Дозволувањето дупли заеднички имиња им овозможува на двата да се поврзат, но не им дава независни статички адреси или независна сопственост. Ако два уреда мора да постојат заедно, регистрирајте ги одделно за секој да има свој идентитет и свое доделување. Третирањето на поставката за дупликати како поправка на ова предупредување ја остава мистеријата на место и додава втора.

Докажете дека поврзувањето се сменило

Применете ја исправката преку сопственикот на конфигурацијата, потоа повторно поврзете го погодениот клиент за да се вчита новата политика.

Повторете го истиот тек и потврдете три работи: внатрешниот извор на пакетот, изданието на клиентот со кое серверот го поврзува и однесувањето на одредиштето потоа.

Ако предупредувањето престане, но апликацијата сѐ уште не успева, проблемот се преместил, а не исчезнал. Проследувањето, правилата на огнениот ѕид и повратниот пат се одделни фази, а поминувањето на проверката за поврзување значи само дека на пакетот му е дозволено да го напушти тунелот.