MULTI: chybná zdrojová adresa od klienta: čí adresa to byla?
Vnitřní zdroj neodpovídá klientovi, který ho doručil. Spárujte ho s přiřazením tunelu, LAN za klientem nebo duplicitní identitou.
Protokol serveru vypisuje MULTI: bad source address from client, zahodí paket a relace zůstává připojená. Tato kombinace mate lidi, kteří zprávu čtou jako selhání autentizace. Není to tak: klient se autentizoval a doručený paket nesl vnitřní zdrojovou adresu, kterou server nedokázal přiřadit k této instanci klienta. Kontrola probíhá před doručením, a proto tunel vypadá zdravě, i když přes něj nic užitečného neprochází.
Co server před doručením porovnává
U každého paketu přicházejícího od klienta se server v uživatelském prostoru podívá na zdrojovou adresu uvnitř tunelu a zeptá se svého vnitřního směrovacího stavu, kterému klientovi tato adresa patří. Je-li vlastníkem jiná instance, nebo žádný vlastník neexistuje, paket se zahodí a vydá se varování.
Běžné doručení přes rozhraní tunelu nikdy neproběhne.
Toto pořadí vysvětluje detail, který lidi mate: počítadla firewallu na hostiteli se nehýbou, protože paket se k firewallu nikdy nedostal. Úprava filtrování zpětné cesty na hostiteli zde nic nemění, protože odmítnutí proběhlo ve vlastní kontrole přiřazení démona. Čtěte zprávu jako tvrzení o vlastnictví a poté zjistěte, která ze tří situací ji způsobila.
Tři zdroje neodpovídající vnitřní adresy
Klient může odesílat z adresy, která mu nebyla přiřazena, ze sítě, kterou nikdo neprohlásil za jeho, nebo z duplikátu identity, která už vlastníka má. Všechny tři vytvářejí stejný řádek protokolu. Liší se v tom, co musíte změnit. Začněte adresou a aktuálním seznamem přiřazení a nechte tyto dva údaje vybrat případ.
Rozlišení vyžaduje dva údaje: odmítnutou adresu v protokolu a přiřazení, která server považuje za aktuální. Druhý je dostupný ze stavového nebo správcovského pohledu běžící instance a je jedinou autoritou, kterou stojí za to konzultovat, protože konfigurační soubor zaznamenává záměry, nikoli současný stav.
Zapište obojí, než cokoli změníte, a poté klasifikujte. Snímek obrazovky pořízený potom není záznamem stavu, který varování vyvolal. Uložte i časové razítko, protože přiřazení se mezi relacemi přesouvají.
| 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 za klientem a iroute
Když klientská lokalita směruje svou vlastní privátní síť, musí být tato síť prohlášena za patřící klientovi. Soubor specifický pro klienta se záznamem iroute to udělá a záznam pojmenovává prefix, který klient smí přenášet.
Jaderná trasa směrující stejný prefix do tunelu je samostatný požadavek a její přidání nic nemění na vnitřním vlastnictví démona.
# /etc/openvpn/server/ccd/site-b
iroute 192.168.70.0 255.255.255.0Ověřte, že efektivní identita odpovídá názvu souboru, protože neshoda znamená, že se soubor nikdy nenačte, a symptom je shodný s chybějícím záznamem. Nepřidávejte široký iroute, abyste varování umlčeli, protože tím se neočekávaný zdroj změní na povolený, aniž by se odpovědělo, proč ho klient odeslal. V příručce OpenVPN 2.6 jsou iroute, duplicate-cn a mapování identit popsány jako samostatné kontroly.
Stejná identita na dvou strojích
Profil zkopírovaný na druhý notebook nese stejný certifikát a stejné běžné jméno. Podle nastavení serveru může novější připojení nahradit starší a v kontrole přiřazení vyhraje ta instance, která drží vlastnictví.
Proto závada vypadá přerušovaně a objevuje se jen tehdy, když jsou obě zařízení vzhůru.
Povolení duplicitních běžných jmen nechá obě připojit, ale nedá jim nezávislé statické adresy ani nezávislé vlastnictví. Pokud mají dvě zařízení existovat vedle sebe, zaregistrujte je zvlášť, aby každé mělo svou identitu a své přiřazení. Považovat nastavení duplicit za opravu tohoto varování nechává záhadu na místě a přidává druhou.
Dokažte, že se přiřazení změnilo
Aplikujte opravu prostřednictvím vlastníka konfigurace a poté znovu připojte postiženého klienta, aby se načetla nová politika.
Zopakujte stejný postup a potvrďte tři věci: vnitřní zdroj paketu, instanci klienta, kterou k němu server přiřazuje, a chování cíle poté.
Pokud varování ustane, ale aplikace stále selhává, problém se přesunul, místo aby zmizel. Přesměrování, pravidla firewallu a zpětná cesta jsou samostatné fáze a projití kontroly přiřazení znamená jen to, že paket směl opustit tunel.