MULTI: dårleg kildeadresse frå klient: kven si adresse var det?
Den indre kjelda stemmer ikkje med klienten som leverte ho. Kople ho til ei tunneltildeling, eit LAN bak klienten eller ein duplisert identitet.
Serverloggen skriv ut MULTI: bad source address from client, slepp pakken og økta blir verande tilkopla. Den kombinasjonen forvirrar folk som les meldinga som ein mislukka autentisering. Det er han ikkje: klienten vart autentisert, og pakken som kom inn bar ei indre kildeadresse som serveren ikkje klarte å knyte til den klientinstansen. Kontrollen skjer før levering, og difor ser tunnelen sunn ut medan ingenting nyttig passerer gjennom han.
Kva serveren samanliknar før levering
For kvar pakke som kjem frå ein klient, ser serveren i brukarrommet på kildeadressa inne i tunnelen og spør den interne rutartilstanden sin kva klient den adressa høyrer til. Viss eigaren er ein annan instans, eller det ikkje finst nokon eigar i det heile, blir pakken forkasta og åtvaringa blir send ut.
Vanleg levering gjennom tunnelgrensesnittet skjer aldri.
Den rekkjefølgja forklarar ein detalj som forvirrar folk: teljarane på brannmuren til verten rører seg ikkje, fordi pakken aldri nådde brannmuren. Å justere omvendt-sti-filtrering på verten endrar ingenting her, sidan avvisinga skjedde i daemonen si eiga knytingskontroll. Les meldinga som ei utsegn om eigarskap, og finn deretter ut kva av tre situasjonar som skapte ho.
Tre kjelder til ei indre adresse som ikkje stemmer
Klienten kan senda frå ei adresse han ikkje har fått tildelt, frå eit nettverk ingen har erklært som sitt, eller frå ein kopi av ein identitet som alt har ein eigar. Alle tre gir same logglinje. Dei skil seg i kva du må endre. Byrja med adressa og den gjeldande tildelingslista, og lat dei to fakta velje saka.
Å skilje dei krev to fakta: den avviste adressa i loggen og tildelingane serveren reknar som gjeldande. Det andre er tilgjengeleg frå status- eller administrasjonsvisinga til den køyrande instansen, og det er den einaste autoriteten som er verdt å rådføre seg med, fordi ei konfigurasjonsfil registrerer intensjonar og ikkje dagens tilstand.
Noter begge før du endrar noko, og klassifiser deretter. Eit skjermbilete teke etterpå er ikkje ei registrering av tilstanden som skapte åtvaringa. Ta òg vare på tidsstempelet, fordi tildelingar flyttar seg mellom økter.
| 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-et bak ein klient og iroute
Når ein områdeklient rutar sitt eige private nettverk, må det nettverket erklærast som høyrer til klienten. Ei klientspesifikk fil med ei iroute-oppføring gjer det, og oppføringa namngir prefikset klienten har lov til å bere.
Ein kjernérute som peikar same prefiks mot tunnelen er eit separat krav, og å leggje han til endrar ingenting ved den interne eigarskapen til daemonen.
# /etc/openvpn/server/ccd/site-b
iroute 192.168.70.0 255.255.255.0Stadfest at den effektive identiteten samsvarar med filnamnet, sidan avvik betyr at fila aldri blir lasta og symptomet er identisk med ei manglande oppføring. Ikkje legg til ein brei iroute for å dempe åtvaringa, fordi det gjer ei uventa kjelde til ei autorisert utan å svare på kvifor klienten sende ho. OpenVPN 2.6-handboka dokumenterer iroute, duplicate-cn og identitetstilordning som separate kontrollar.
Same identitet på to maskinar
Ein profil kopiert til ein annan berbar PC ber same sertifikat og same vanlege namn. Avhengig av serverinnstillingane kan den nyare tilkoplinga erstatte den eldre, og den instansen som held eigarskapen vinn knytingskontrollen.
Det gjer feilen periodisk og han viser seg berre når begge einingane er vakne.
Å tillate dupliserte vanlege namn lèt begge kople til, men gir dei ikkje uavhengige statiske adresser eller uavhengig eigarskap. Viss to einingar må eksistere saman, registrer dei separat slik at kvar har sin eigen identitet og si eiga tildeling. Å handsame duplikatinnstillinga som ein reparasjon av denne åtvaringa lèt mysteriet stå og legg til eit nytt.
Prov at knytinga vart endra
Bruk rettinga gjennom eigaren av konfigurasjonen, og kople deretter den råka klienten til på nytt slik at den nye policyen blir lasta.
Gjenta same flyt og stadfest tre ting: den indre kjelda til pakken, klientinstansen serveren knyter han til, og åtferda til destinatoren etterpå.
Viss åtvaringa stoppar, men applikasjonen framleis feilar, har problemet flytta seg i staden for å forsvinne. Vidaresending, brannmurreglar og returvegen er separate trinn, og å klare knytingskontrollen betyr berre at pakken fekk lov til å forlate tunnelen.