MULTI: dårlig kildeadresse fra klient: hvis adresse var det?
Den indre kilden stemmer ikke med klienten som leverte den. Koble den til en tunneltildeling, et LAN bak klienten eller en duplisert identitet.
Serverloggen skriver ut MULTI: bad source address from client, slipper pakken og økten forblir tilkoblet. Den kombinasjonen forvirrer folk som leser meldingen som en mislykket autentisering. Det er den ikke: klienten ble autentisert, og pakken som kom inn bar en indre kildeadresse som serveren ikke klarte å knytte til den klientinstansen. Kontrollen skjer før levering, og derfor ser tunnelen sunn ut mens ingenting nyttig passerer gjennom den.
Hva serveren sammenligner før levering
For hver pakke som kommer fra en klient, ser serveren i brukerrommet på kildeadressen inne i tunnelen og spør sin interne rutertilstand hvilken klient den adressen tilhører. Hvis eieren er en annen instans, eller det ikke finnes noen eier i det hele tatt, forkastes pakken og advarselen sendes ut.
Vanlig levering gjennom tunnelgrensesnittet skjer aldri.
Den rekkefølgen forklarer en detalj som forvirrer folk: tellerne på vertens brannmur rører seg ikke, fordi pakken aldri nådde brannmuren. Å justere omvendt-sti-filtrering på verten endrer ingenting her, siden avvisningen skjedde i dæmonens egen tilknytningskontroll. Les meldingen som en uttalelse om eierskap, og finn deretter ut hvilken av tre situasjoner som frembrakte den.
Tre kilder til en indre adresse som ikke stemmer
Klienten kan sende fra en adresse den ikke har fått tildelt, fra et nettverk ingen har erklært som sitt, eller fra en kopi av en identitet som allerede har en eier. Alle tre gir samme logglinje. De skiller seg i hva du må endre. Begynn med adressen og den gjeldende tildelingslisten, og la de to fakta velge saken.
Å skille dem krever to fakta: den avviste adressen i loggen og tildelingene serveren anser som gjeldende. Det andre er tilgjengelig fra status- eller administrasjonsvisningen til den kjørende instansen, og det er den eneste autoriteten som er verdt å rådføre seg med, fordi en konfigurasjonsfil registrerer intensjoner og ikke dagens tilstand.
Noter begge før du endrer noe, og klassifiser deretter. Et skjermbilde tatt etterpå er ikke en registrering av tilstanden som frembrakte advarselen. Ta også vare på tidsstempelet, fordi tildelinger flytter 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 en klient og iroute
Når en områdeklient ruter sitt eget private nettverk, må det nettverket erklæres som tilhørende klienten. En klientspesifikk fil med en iroute-oppføring gjør det, og oppføringen navngir prefikset klienten har lov til å bære.
En kjernerute som peker samme prefiks mot tunnelen er et separat krav, og å legge den til endrer ingenting ved dæmonens interne eierskap.
# /etc/openvpn/server/ccd/site-b
iroute 192.168.70.0 255.255.255.0Bekreft at den effektive identiteten samsvarer med filnavnet, siden avvik betyr at filen aldri lastes og symptomet er identisk med en manglende oppføring. Ikke legg til en bred iroute for å dempe advarselen, fordi det gjør en uventet kilde til en autorisert uten å svare på hvorfor klienten sendte den. OpenVPN 2.6-håndboken dokumenterer iroute, duplicate-cn og identitetstilordning som separate kontroller.
Samme identitet på to maskiner
En profil kopiert til en annen bærbar PC bærer samme sertifikat og samme vanlige navn. Avhengig av serverinnstillingene kan den nyere tilkoblingen erstatte den eldre, og den instansen som holder eierskapet vinner tilknytningskontrollen.
Det gjør feilen periodisk og den vises bare når begge enhetene er våkne.
Å tillate dupliserte vanlige navn lar begge koble til, men gir dem ikke uavhengige statiske adresser eller uavhengig eierskap. Hvis to enheter må eksistere sammen, registrer dem separat slik at hver har sin egen identitet og sin egen tildeling. Å behandle duplikatinnstillingen som en reparasjon av denne advarselen lar mysteriet stå og legger til et nytt.
Bevis at tilknytningen ble endret
Bruk rettelsen gjennom konfigurasjonens eier, og koble deretter den berørte klienten til på nytt slik at den nye policyen lastes.
Gjenta samme flyt og bekreft tre ting: pakkens indre kilde, klientinstansen serveren knytter den til, og destinasjonens oppførsel etterpå.
Hvis advarselen stopper, men applikasjonen fortsatt feiler, har problemet flyttet seg i stedet for å forsvinne. Videresending, brannmurregler og returveien er separate trinn, og å bestå tilknytningskontrollen betyr bare at pakken fikk lov til å forlate tunnelen.