MULTI: nesprávna zdrojová adresa od klienta: čia to bola adresa?
Vnútorný zdroj nezodpovedá klientovi, ktorý ho doručil. Spárujte ho s priradením tunela, sieťou LAN za klientom alebo duplicitnou identitou.
Protokol servera vypisuje MULTI: bad source address from client, zahodí paket a relácia zostáva pripojená. Táto kombinácia mätie ľudí, ktorí správu čítajú ako zlyhanie autentifikácie. Nie je to tak: klient sa autentifikoval a doručený paket niesol vnútornú zdrojovú adresu, ktorú server nedokázal priradiť k tejto inštancii klienta. Kontrola prebieha pred doručením, a preto tunel vyzerá zdravý, hoci cez neho nič užitočné neprechádza.
Čo server porovnáva pred doručením
Pri každom pakete prichádzajúcom od klienta sa server v používateľskom priestore pozrie na zdrojovú adresu vnútri tunela a opýta sa svojho vnútorného smerovacieho stavu, ktorému klientovi táto adresa patrí. Ak je vlastníkom iná inštancia alebo žiadny vlastník neexistuje, paket sa zahodí a vydá sa upozornenie.
Bežné doručenie cez rozhranie tunela nikdy nenastane.
Toto poradie vysvetľuje detail, ktorý ľudí mätie: počítadlá firewallu na hostiteľovi sa nehýbu, pretože paket sa k firewallu nikdy nedostal. Úprava filtrovania spätnej cesty na hostiteľovi tu nič nemení, pretože odmietnutie nastalo vo vlastnej kontrole priradenia démona. Čítajte správu ako tvrdenie o vlastníctve a potom zistite, ktorá z troch situácií ju vyvolala.
Tri zdroje nezhodnej vnútornej adresy
Klient môže odosielať z adresy, ktorá mu nebola priradená, zo siete, ktorú nikto nevyhlásil za jeho, alebo z duplikátu identity, ktorá už má vlastníka. Všetky tri vytvárajú rovnaký riadok protokolu. Líšia sa v tom, čo musíte zmeniť. Začnite adresou a aktuálnym zoznamom priradení a nechajte tieto dva fakty vybrať prípad.
Na ich rozlíšenie treba dva fakty: odmietnutú adresu v protokole a priradenia, ktoré server považuje za aktuálne. Druhý je dostupný z pohľadu stavu alebo správy bežiacej inštancie a je jedinou autoritou, ktorú sa oplatí konzultovať, pretože konfiguračný súbor zaznamenáva zámery, nie súčasný stav.
Zapíšte oboje, skôr než čokoľvek zmeníte, a potom klasifikujte. Snímka obrazovky vytvorená neskôr nie je záznamom stavu, ktorý upozornenie vyvolal. Uložte aj časovú značku, pretože priradenia sa medzi reláciami presúvajú.
| 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 klientom a iroute
Keď klientska lokalita smeruje svoju vlastnú privátnu sieť, táto sieť musí byť vyhlásená za patriacu klientovi. Súbor špecifický pre klienta so záznamom iroute to urobí a záznam pomenuje prefix, ktorý klient smie prenášať.
Jadrová trasa smerujúca rovnaký prefix do tunela je samostatná požiadavka a jej pridanie nič nemení na vnútornom vlastníctve démona.
# /etc/openvpn/server/ccd/site-b
iroute 192.168.70.0 255.255.255.0Overte, že efektívna identita zodpovedá názvu súboru, pretože nezhoda znamená, že sa súbor nikdy nenačíta a príznak je rovnaký ako pri chýbajúcom zázname. Nepridávajte široký iroute na utíšenie upozornenia, pretože to mení neočakávaný zdroj na povolený bez odpovede, prečo ho klient odoslal. Príručka OpenVPN 2.6 dokumentuje iroute, duplicate-cn a mapovanie identít ako samostatné kontroly.
Rovnaká identita na dvoch strojoch
Profil skopírovaný na druhý notebook nesie rovnaký certifikát a rovnaké bežné meno. Podľa nastavení servera môže novšie pripojenie nahradiť staršie a kontrolu priradenia vyhrá tá inštancia, ktorá drží vlastníctvo.
Preto chyba vyzerá prerušovane a objavuje sa len vtedy, keď sú obe zariadenia hore.
Povolenie duplicitných bežných mien nechá obe pripojiť, ale nedá im nezávislé statické adresy ani nezávislé vlastníctvo. Ak majú dve zariadenia existovať vedľa seba, zaregistrujte ich samostatne, aby každé malo svoju identitu a svoje priradenie. Považovať nastavenie duplicít za opravu tohto upozornenia necháva záhadu na mieste a pridáva druhú.
Dokážte, že sa priradenie zmenilo
Aplikujte opravu cez vlastníka konfigurácie a potom znova pripojte postihnutého klienta, aby sa načítala nová politika.
Zopakujte rovnaký postup a potvrďte tri veci: vnútorný zdroj paketu, inštanciu klienta, ku ktorej ho server priraďuje, a správanie cieľa potom.
Ak upozornenie ustane, ale aplikácia stále zlyháva, problém sa posunul, a nie zmizol. Preposielanie, pravidlá firewallu a spätná cesta sú samostatné fázy a prejdenie kontroly priradenia znamená len to, že paket smel opustiť tunel.