MULTI: dårlig kildeadresse fra klient: hvis adresse var det?
Den indre kilde svarer ikke til den klient, der leverede den. Knyt den til en tunneludpegning, et LAN bag klienten eller en dubleret identitet.
Serverloggen udskriver MULTI: bad source address from client, dropper pakken, og sessionen forbliver forbundet. Den kombination forvirrer folk, der læser meddelelsen som en mislykket godkendelse. Det er den ikke: klienten blev godkendt, og pakken, der ankom, bar en indre kildeadresse, som serveren ikke kunne knytte til den klientinstans. Kontrollen sker før levering, og derfor ser tunnelen sund ud, mens intet nyttigt passerer igennem den.
Hvad serveren sammenligner før levering
For hver pakke, der ankommer fra en klient, ser serveren i brugerrummet på kildeadressen inde i tunnelen og spørger sin interne routingtilstand, hvilken klient den adresse tilhører. Hvis ejeren er en anden instans, eller der slet ikke er nogen ejer, kasseres pakken, og advarslen udsendes.
Almindelig levering gennem tunnelgrænsefladen sker aldrig.
Den rækkefølge forklarer en detalje, som folk finder uforståelig: værtsfirewallens tællere flytter sig ikke, fordi pakken aldrig nåede firewallen. Justering af omvendt-sti-filtrering på værten ændrer intet her, da afvisningen skete i dæmonens egen tilknytningskontrol. Læs meddelelsen som en udtalelse om ejerskab, og find derefter ud af, hvilken af tre situationer der frembragte den.
Tre kilder til en indre adresse, der ikke passer
Klienten kan sende fra en adresse, den ikke har fået tildelt, fra et netværk, som ingen har erklæret tilhører den, eller fra en dublet af en identitet, der allerede har en ejer. Alle tre giver den samme loglinje. De adskiller sig i, hvad du skal ændre. Begynd med adressen og den aktuelle tildelingsliste, og lad de to fakta vælge sagen.
At skelne dem kræver to fakta: den afviste adresse i loggen og de tildelinger, som serveren anser for aktuelle. Det andet fås fra status- eller administrationsvisningen af den kørende instans, og det er den eneste autoritet, der er værd at rådføre sig med, fordi en konfigurationsfil registrerer hensigter og ikke den nuværende tilstand.
Noter begge, før du ændrer noget, og klassificér derefter. Et skærmbillede taget bagefter er ikke en registrering af den tilstand, der frembragte advarslen. Gem også tidsstemplet, fordi tildelinger flytter sig mellem sessioner.
| 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 bag en klient og iroute
Når en site-klient ruter sit eget private netværk, skal det netværk erklæres som tilhørende klienten. En klientspecifik fil med en iroute-post gør det, og posten angiver det præfiks, som klienten må bære.
En kernrute, der peger samme præfiks mod tunnelen, er et separat krav, og at tilføje den ændrer intet ved dæmonens interne ejerskab.
# /etc/openvpn/server/ccd/site-b
iroute 192.168.70.0 255.255.255.0Bekræft, at den effektive identitet matcher filnavnet, da en uoverensstemmelse betyder, at filen aldrig indlæses, og symptomet er identisk med en manglende post. Tilføj ikke en bred iroute for at tysse på advarslen, fordi det gør en uventet kilde til en autoriseret uden at svare på, hvorfor klienten sendte den. OpenVPN 2.6-manualen dokumenterer iroute, duplicate-cn og identitetskortlægning som separate kontroller.
Den samme identitet på to maskiner
En profil, der kopieres til en anden bærbar, bærer det samme certifikat og det samme fællesnavn. Afhængigt af serverens indstillinger kan den nyere forbindelse erstatte den ældre, og den instans, der holder ejerskabet, vinder tilknytningskontrollen.
Det får fejlen til at virke periodisk og kun optræde, når begge enheder er vågne.
Tilladelse af dublerede fællesnavne lader begge oprette forbindelse, men giver dem ikke uafhængige statiske adresser eller uafhængigt ejerskab. Hvis to enheder skal sameksistere, skal de tilmeldes separat, så hver har sin egen identitet og sin egen tildeling. At behandle dubletindstillingen som en reparation af denne advarsel lader mysteriet stå og tilføjer et andet.
Bevis, at tilknytningen blev ændret
Anvend rettelsen gennem konfigurationens ejer, og genopret derefter forbindelsen for den berørte klient, så den nye politik indlæses.
Gentag samme flow, og bekræft tre ting: pakkens indre kilde, den klientinstans som serveren knytter den til, og destinationens adfærd bagefter.
Hvis advarslen stopper, men programmet stadig fejler, har problemet flyttet sig i stedet for at forsvinde. Videresendelse, firewallregler og returvejen er separate trin, og at bestå tilknytningskontrollen betyder kun, at pakken fik lov at forlade tunnelen.