MULTI: ongeldig bronadres van client: wiens adres was dat?

Het serverlog drukt MULTI: bad source address from client af, laat het pakket vallen en de sessie blijft verbonden. Die combinatie verwart mensen die het bericht als een mislukte authenticatie lezen. Dat is het niet: de client is geauthenticeerd en het aangekomen pakket droeg een intern bronadres dat de server niet aan dat clientexemplaar kon koppelen. De controle gebeurt vóór de aflevering, en daarom lijkt de tunnel gezond terwijl er niets nuttigs doorheen gaat.

Wat de server vóór de aflevering vergelijkt

Voor elk pakket dat van een client binnenkomt, kijkt de server in de gebruikersruimte naar het bronadres binnen de tunnel en vraagt zijn interne routeringsstatus aan welke client dat adres toebehoort. Als de eigenaar een ander exemplaar is, of er helemaal geen eigenaar is, wordt het pakket verworpen en wordt de waarschuwing uitgegeven.

Gewone aflevering via de tunnelinterface gebeurt nooit.

Die volgorde verklaart een detail dat mensen verbaast: de tellers van de host-firewall bewegen niet, omdat het pakket de firewall nooit heeft bereikt. Het aanpassen van reverse-path-filtering op de host verandert hier niets, omdat de afwijzing in de eigen koppelingscontrole van de daemon plaatsvond. Lees het bericht als een uitspraak over eigendom en zoek daarna uit welke van de drie situaties het heeft veroorzaakt.

Drie bronnen van een niet-passend intern adres

De client stuurt mogelijk vanaf een adres dat hem niet is toegewezen, vanuit een netwerk dat niemand als het zijne heeft verklaard, of vanaf een kopie van een identiteit die al een eigenaar heeft. Alle drie leveren dezelfde logregel op. Ze verschillen in wat je moet wijzigen. Begin met het adres en de huidige toewijzingslijst, en laat die twee feiten het geval kiezen.

Ze onderscheiden vraagt twee feiten: het afgewezen adres in het log en de toewijzingen die de server als actueel beschouwt. Het tweede is beschikbaar in de status- of beheerweergave van het draaiende exemplaar, en dat is de enige autoriteit die het raadplegen waard is, omdat een configuratiebestand bedoelingen vastlegt en niet de huidige toestand.

Noteer beide voordat je iets wijzigt, en classificeer daarna. Een screenshot die achteraf wordt gemaakt is geen registratie van de toestand die de waarschuwing veroorzaakte. Bewaar ook de tijdstempel, omdat toewijzingen tussen sessies verschuiven.

Het LAN achter een client en iroute

Wanneer een site-client zijn eigen privénetwerk routeert, moet dat netwerk als bij de client horend worden verklaard. Een clientspecifiek bestand met een iroute-regel doet dat, en de regel noemt het prefix dat de client mag dragen.

Een kernelroute die hetzelfde prefix naar de tunnel wijst is een aparte vereiste, en het toevoegen ervan verandert niets aan het interne eigendom van de daemon.

# /etc/openvpn/server/ccd/site-b
iroute 192.168.70.0 255.255.255.0

Bevestig dat de effectieve identiteit overeenkomt met de bestandsnaam, want een afwijking betekent dat het bestand nooit wordt geladen en het symptoom identiek is aan een ontbrekende regel. Voeg geen brede iroute toe om de waarschuwing te dempen, want dat maakt een onverwachte bron tot een geautoriseerde zonder te beantwoorden waarom de client hem stuurde. De OpenVPN 2.6-handleiding documenteert iroute, duplicate-cn en identiteitstoewijzing als afzonderlijke controles.

Dezelfde identiteit op twee machines

Een profiel dat naar een tweede laptop is gekopieerd, draagt hetzelfde certificaat en dezelfde common name. Afhankelijk van de serverinstellingen kan de nieuwere verbinding de oudere vervangen, en het exemplaar dat het eigendom heeft wint de koppelingscontrole.

Daardoor lijkt de fout periodiek en verschijnt hij alleen wanneer beide apparaten wakker zijn.

Dubbele common names toestaan laat beide verbinden, maar geeft ze geen onafhankelijke statische adressen of onafhankelijk eigendom. Als twee apparaten samen moeten bestaan, registreer ze dan apart zodat elk zijn eigen identiteit en zijn eigen toewijzing heeft. De duplicaatinstelling als reparatie van deze waarschuwing behandelen laat het raadsel staan en voegt er een tweede aan toe.

Bewijs dat de koppeling is gewijzigd

Pas de correctie toe via de eigenaar van de configuratie en verbind daarna de betrokken client opnieuw zodat het nieuwe beleid wordt geladen.

Herhaal dezelfde stroom en bevestig drie dingen: de interne bron van het pakket, het clientexemplaar waarmee de server het koppelt, en het gedrag van de bestemming daarna.

Als de waarschuwing stopt maar de toepassing nog steeds faalt, is het probleem verschoven in plaats van verdwenen. Doorsturen, firewallregels en de terugweg zijn aparte fasen, en de koppelingscontrole doorstaan betekent alleen dat het pakket de tunnel mocht verlaten.