MULTI: няправільны адрас крыніцы ад кліента: чый гэта адрас?
Унутраная крыніца не супадае з кліентам, які яе даставіў. Супастаўце яе з прызначэннем тунеля, LAN за кліентам або дублікатам асобы.
Серверны журнал друкуе MULTI: bad source address from client, адкідвае пакет, а сеанс застаецца злучаным. Такая камбінацыя бянтэжыць людзей, якія чытаюць паведамленне як няўдалую аўтэнтыфікацыю. Гэта не так: кліент прайшоў аўтэнтыфікацыю, а пакет, што прыйшоў, нёс унутраны адрас крыніцы, які сервер не мог звязаць з гэтым асобнікам кліента. Праверка адбываецца перад дастаўкай, таму тунель выглядае здаровым, пакуль праз яго не праходзіць нічога карыснага.
Што сервер параўноўвае перад дастаўкай
Для кожнага пакета, які прыходзіць ад кліента, сервер у прасторы карыстальніка глядзіць на адрас крыніцы ўнутры тунеля і пытаецца ў свайго ўнутранага стану маршрутызацыі, якому кліенту належыць гэты адрас. Калі ўласнікам з'яўляецца іншы асобнік або ўласніка няма зусім, пакет адкідаецца і выдаецца папярэджанне.
Звычайная дастаўка праз інтэрфейс тунеля не адбываецца ніколі.
Гэты парадак тлумачыць дэталь, якая здзіўляе людзей: лічыльнікі міжсеткавага экрана на хасце не рухаюцца, бо пакет ніколі не дасягнуў экрана. Наладжванне фільтрацыі зваротнага шляху на хасце тут нічога не мяняе, бо адмова адбылася ва ўласнай праверцы сувязі дэмана. Чытайце паведамленне як сцверджанне пра ўласнасць, а затым высветліце, якая з трох сітуацый яго ўтварыла.
Тры крыніцы неадпаведнага ўнутранага адраса
Кліент можа дасылаць з адраса, які яму не прызначаны, з сеткі, якую ніхто не абвясціў ягонай, або з дубліката асобы, у якой ужо ёсць уласнік. Усе тры даюць адзін і той жа радок у журнале. Яны розняцца тым, што вам давядзецца змяніць. Пачніце з адраса і бягучага спісу прызначэнняў, і хай гэтыя два факты выберуць выпадак.
Каб іх адрозніць, патрэбны два факты: адкінуты адрас у журнале і прызначэнні, якія сервер лічыць бягучымі. Другі даступны з прадстаўлення стану або кіравання працуючага асобніка, і гэта адзіная крыніца, да якой варта звяртацца, бо файл канфігурацыі фіксуе намеры, а не бягучы стан.
Запішыце абодва, перш чым нешта змяняць, а потым класіфікуйце. Здымак экрана, зроблены пасля, не з'яўляецца запісам стану, які ўтварыў папярэджанне. Захавайце таксама адзнаку часу, бо прызначэнні перамяшчаюцца паміж сеансамі.
| Rejected source is | Likely cause |
|---|---|
| The client's own tunnel address | Static assignment conflict, wrong profile, or manual address change |
| A host behind that client | Missing internal ownership for that prefix |
| An address belonging to another session | Two devices sharing one identity or one static address |
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 і супастаўленне асоб як асобныя сродкі кантролю.
Адна і тая ж асоба на дзвюх машынах
Профіль, скапіяваны на другі ноўтбук, нясе той самы сертыфікат і тое самае агульнае імя. У залежнасці ад налад сервера больш новае злучэнне можа замяніць старэйшае, і перамагае ў праверцы сувязі той асобнік, які ўтрымлівае ўласнасць.
Гэта робіць збой падобным на перарывісты і паказвае яго толькі тады, калі абодва прыстасаванні ўключаны.
Дазвол дублікатных агульных імён дазваляе абедзвюм падключыцца, але не дае ім незалежных статычных адрасоў або незалежнай уласнасці. Калі два прыстасаванні павінны суіснаваць, зарэгіструйце іх асобна, каб кожнае мела сваю асобу і сваё прызначэнне. Калі разглядаць наладку дублікатаў як рамонт гэтага папярэджання, загадка застаецца на месцы, і да яе дадаецца другая.
Дакажыце, што сувязь змянілася
Ужыццявіце папраўку праз уласніка канфігурацыі, затым перападключыце пацярпелага кліента, каб загрузілася новая палітыка.
Паўтарыце той самы паток і пацвердзіце тры рэчы: унутраную крыніцу пакета, асобнік кліента, з якім сервер яго звязвае, і паводзіны пункту прызначэння пасля.
Калі папярэджанне спынілася, але праграма ўсё яшчэ не працуе, праблема перамясцілася, а не знікла. Перасыланне, правілы міжсеткавага экрана і зваротны шлях — гэта асобныя этапы, і праходжанне праверкі сувязі азначае толькі, што пакету дазволена пакінуць тунель.