MULTI: foutiewe bronadres van kliënt – wie se adres was dit?
Die binneste bron stem nie ooreen met die kliënt wat dit afgelewer het nie. Pas dit by 'n tonneltoewysing, 'n LAN agter die kliënt of 'n dubbele identiteit.
Die bedienerlog druk MULTI: bad source address from client, laat die pakket val, en die sessie bly verbind. Daardie kombinasie verwar mense wat die boodskap as 'n mislukte verifikasie lees. Dit is nie: die kliënt het geverifieer, en die pakket wat aangekom het, het 'n binneste bronadres gedra wat die bediener nie met daardie kliëntinstansie kon assosieer nie. Die kontrole vind voor aflewering plaas, en daarom lyk die tonnel gesond terwyl niks nuttigs daardeur beweeg nie.
Wat die bediener voor aflewering vergelyk
Vir elke pakket wat van 'n kliënt af kom, kyk die gebruikerspasie-bediener na die bronadres binne die tonnel en vra sy interne roetestaat aan watter kliënt daardie adres behoort. As die eienaar 'n ander instansie is, of glad geen eienaar nie, word die pakket geskrap en die waarskuwing uitgestuur.
Gewone aflewering deur die tonnelkoppelvlak vind nooit plaas nie.
Daardie volgorde verduidelik 'n detail wat mense verbaas: die telwerk van die gasheer se vuurmuur beweeg nie, want die pakket het nooit die vuurmuur bereik nie. Die aanpassing van die omgekeerde-padfiltering op die gasheer verander hier niks, want die verwerping het in die daemon se eie assosiasiekontrole gebeur. Lees die boodskap as 'n stelling oor eienaarskap en vind dan uit watter van drie situasies dit veroorsaak het.
Drie bronne van 'n wanaangepaste binneste adres
Die kliënt stuur dalk vanaf 'n adres wat nie aan hom toegewys is nie, vanaf 'n netwerk wat niemand as syne verklaar het nie, of vanaf 'n duplikaat van 'n identiteit wat reeds 'n eienaar het. Al drie lewer dieselfde logreël. Hulle verskil in wat jy moet verander. Begin met die adres en die huidige toewysingslys, en laat daardie twee feite die geval kies.
Om hulle te onderskei verg twee feite: die verwerpte adres in die log, en die toewysings wat die bediener as huidig beskou. Die tweede is beskikbaar uit die status- of bestuursaansig van die lopende instansie, en dit is die enigste gesag wat die moeite werd is om te raadpleeg, want 'n konfigurasielêer teken bedoelings aan eerder as die huidige toestand.
Teken albei aan voordat jy enigiets verander, en klassifiseer dan. 'n Skermbeeld wat daarna geneem word, is nie 'n rekord van die toestand wat die waarskuwing veroorsaak het nie. Hou ook die tydstempel, want toewysings skuif tussen sessies.
| 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 |
Die LAN agter 'n kliënt en iroute
Wanneer 'n werf-kliënt sy eie private netwerk roeteer, moet daardie netwerk as aan die kliënt behorend verklaar word. 'n Kliëntspesifieke lêer met 'n iroute-inskrywing doen dit, en die inskrywing noem die voorvoegsel wat die kliënt mag dra.
'n Kernroete wat dieselfde voorvoegsel na die tonnel wys, is 'n aparte vereiste, en om dit by te voeg verander niks aan die daemon se interne eienaarskap nie.
# /etc/openvpn/server/ccd/site-b
iroute 192.168.70.0 255.255.255.0Bevestig dat die effektiewe identiteit met die lêernaam ooreenstem, want 'n wanaanpassing beteken die lêer laai nooit en die simptoom is identies aan 'n ontbrekende inskrywing. Moenie 'n breë iroute byvoeg om die waarskuwing stil te maak nie, want dit verander 'n onverwagte bron in 'n gemagtigde een sonder om te antwoord waarom die kliënt dit gestuur het. Die OpenVPN 2.6-handleiding dokumenteer iroute, duplicate-cn en identiteitstoewysing as aparte kontroles.
Dieselfde identiteit op twee masjiene
'n Profiel wat na 'n tweede skootrekenaar gekopieer is, dra dieselfde sertifikaat en dieselfde algemene naam. Afhangend van die bediener se instellings kan die nuwer verbinding die ouer een vervang, en watter instansie ook al die eienaarskap hou, wen die assosiasiekontrole.
Dit laat die fout onderbroke lyk en slegs verskyn wanneer albei toestelle wakker is.
As dubbele algemene name toegelaat word, kan albei verbind, maar dit gee hulle nie onafhanklike statiese adresse of onafhanklike eienaarskap nie. As twee toestelle saam moet bestaan, skryf hulle afsonderlik in sodat elkeen sy eie identiteit en sy eie toewysing het. Om die duplikaatinstelling as 'n herstel vir hierdie waarskuwing te behandel, laat die raaisel in plek en voeg 'n tweede by.
Bewys dat die assosiasie verander het
Pas die regstelling deur die konfigurasie-eienaar toe en verbind dan die betrokke kliënt weer sodat die nuwe beleid laai.
Herhaal dieselfde vloei en bevestig drie dinge: die pakket se binneste bron, die kliëntinstansie wat die bediener daarmee assosieer, en die bestemming se gedrag daarna.
As die waarskuwing ophou maar die toepassing steeds misluk, het die probleem geskuif eerder as verdwyn. Aanstuur, vuurmuurreëls en die terugpad is aparte fases, en om die assosiasiekontrole te slaag beteken net dat die pakket toegelaat is om die tonnel te verlaat.