MULTI: felaktig källadress från klienten: vems adress var det?
Den inre källan stämmer inte med klienten som levererade den. Koppla den till en tunneltilldelning, ett LAN bakom klienten eller en dubblerad identitet.
Serverloggen skriver ut MULTI: bad source address from client, släpper paketet och sessionen förblir ansluten. Den kombinationen förvirrar folk som läser meddelandet som ett misslyckat autentisering. Det är det inte: klienten autentiserades och paketet som anlände bar en inre källadress som servern inte kunde koppla till den klientinstansen. Kontrollen sker före leverans, och därför ser tunneln frisk ut medan inget användbart passerar genom den.
Vad servern jämför före leverans
För varje paket som kommer från en klient tittar servern i användarutrymmet på källadressen inuti tunneln och frågar sin interna routingstatus vilken klient den adressen tillhör. Om ägaren är en annan instans, eller det inte finns någon ägare alls, kastas paketet och varningen skickas ut.
Vanlig leverans genom tunnelgränssnittet sker aldrig.
Den ordningen förklarar en detalj som förbryllar folk: värdens brandväggsräknare rör sig inte, eftersom paketet aldrig nådde brandväggen. Att justera omvänd-väg-filtrering på värden ändrar inget här, eftersom avvisningen skedde i daemonens egen kopplingskontroll. Läs meddelandet som ett påstående om ägandeskap och ta sedan reda på vilken av tre situationer som skapade det.
Tre källor till en inre adress som inte stämmer
Klienten kan skicka från en adress som den inte tilldelats, från ett nätverk som ingen har förklarat som sitt, eller från en kopia av en identitet som redan har en ägare. Alla tre ger samma logglinje. De skiljer sig i vad du måste ändra. Börja med adressen och den aktuella tilldelningslistan, och låt de två fakta välja fallet.
Att skilja dem åt kräver två fakta: den avvisade adressen i loggen och de tilldelningar som servern anser vara aktuella. Det andra finns i status- eller administrationsvyn för den körande instansen, och det är den enda auktoritet som är värd att rådfråga, eftersom en konfigurationsfil registrerar avsikter och inte det aktuella tillståndet.
Anteckna båda innan du ändrar något och klassificera sedan. En skärmbild som tas efteråt är inte en registrering av det tillstånd som skapade varningen. Spara även tidsstämpeln, eftersom tilldelningar flyttar sig mellan 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 bakom en klient och iroute
När en platsklient routar sitt eget privata nätverk måste det nätverket förklaras tillhöra klienten. En klientspecifik fil med en iroute-post gör det, och posten namnger det prefix som klienten får bära.
En kärnrutt som pekar samma prefix mot tunneln är ett separat krav, och att lägga till den ändrar inget i daemonens interna ägandeskap.
# /etc/openvpn/server/ccd/site-b
iroute 192.168.70.0 255.255.255.0Bekräfta att den effektiva identiteten stämmer med filnamnet, eftersom en avvikelse innebär att filen aldrig laddas och symptomet är identiskt med en saknad post. Lägg inte till en bred iroute för att tysta varningen, eftersom det gör en oväntad källa till en auktoriserad utan att svara på varför klienten skickade den. OpenVPN 2.6-handboken dokumenterar iroute, duplicate-cn och identitetsmappning som separata kontroller.
Samma identitet på två maskiner
En profil som kopierats till en andra bärbar dator bär samma certifikat och samma vanliga namn. Beroende på serverns inställningar kan den nyare anslutningen ersätta den äldre, och den instans som har ägandeskapet vinner kopplingskontrollen.
Det gör felet intermittent och det visas bara när båda enheterna är vakna.
Att tillåta dubblerade vanliga namn låter båda ansluta, men ger dem inte oberoende statiska adresser eller oberoende ägandeskap. Om två enheter måste samexistera, registrera dem separat så att var och en har sin egen identitet och sin egen tilldelning. Att behandla dubblettinställningen som en reparation av denna varning lämnar mysteriet kvar och lägger till ett andra.
Bevisa att kopplingen ändrades
Använd rättelsen via konfigurationens ägare och återanslut sedan den berörda klienten så att den nya policyn laddas.
Upprepa samma flöde och bekräfta tre saker: paketets inre källa, den klientinstans som servern kopplar det till, och destinationens beteende efteråt.
Om varningen upphör men programmet fortfarande misslyckas har problemet flyttat sig i stället för att försvinna. Vidarebefordran, brandväggsregler och returvägen är separata steg, och att klara kopplingskontrollen betyder bara att paketet fick lämna tunneln.