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 и мапирање идентитета као засебне контроле.
Исти идентитет на два рачунара
Профил копиран на други преносни рачунар носи исти сертификат и исто уобичајено име. У зависности од подешавања сервера, новија веза може заменити старију, а проверу повезивања добија инстанца која држи власништво.
Због тога квар изгледа повремено и појављује се само када су оба уређаја будна.
Дозвољавање дуплих уобичајених имена пушта оба да се повежу, али им не даје независне статичке адресе ни независно власништво. Ако два уређаја морају да постоје заједно, региструјте их одвојено тако да сваки има свој идентитет и своју доделу. Третирање поставке дупликата као поправке овог упозорења оставља мистерију на месту и додаје другу.
Докажите да се повезивање променило
Примените исправку кроз власника конфигурације, а затим поново повежите погођеног клијента да би се нова политика учитала.
Поновите исти ток и потврдите три ствари: унутрашњи извор пакета, инстанцу клијента са којом га сервер повезује и понашање одредишта после тога.
Ако упозорење престане, али апликација и даље не успева, проблем се преместио, а није нестао. Прослеђивање, правила заштитног зида и повратни пут су засебне фазе, а пролазак провере повезивања значи само да је пакету дозвољено да напусти тунел.