MULTI: napačen izvorni naslov od odjemalca: čigav je bil ta naslov?
Notranji vir se ne ujema z odjemalcem, ki ga je dostavil. Povežite ga z dodelitvijo predora, omrežjem LAN za odjemalcem ali podvojeno identiteto.
Dnevnik strežnika izpiše MULTI: bad source address from client, zavrže paket in seja ostane povezana. Ta kombinacija zmede ljudi, ki sporočilo berejo kot neuspešno preverjanje pristnosti. Ni tako: odjemalec se je preveril, prispeli paket pa je nosil notranji izvorni naslov, ki ga strežnik ni mogel povezati s to instanco odjemalca. Preverjanje se zgodi pred dostavo, zato je predor videti zdrav, medtem ko skozenj ne gre nič koristnega.
Kaj strežnik primerja pred dostavo
Za vsak paket, ki pride od odjemalca, strežnik v uporabniškem prostoru pogleda izvorni naslov znotraj predora in vpraša svoje notranje stanje usmerjanja, kateremu odjemalcu pripada ta naslov. Če je lastnik druga instanca ali lastnika sploh ni, se paket zavrže in izda opozorilo.
Običajna dostava skozi vmesnik predora se nikoli ne zgodi.
Ta vrstni red pojasnjuje podrobnost, ki ljudi zmede: števci požarnega zidu na gostitelju se ne premaknejo, ker paket nikoli ni prišel do požarnega zidu. Prilagajanje filtriranja povratne poti na gostitelju tu nič ne spremeni, saj se je zavrnitev zgodila v lastnem preverjanju povezave demona. Sporočilo berite kot trditev o lastništvu in nato ugotovite, katera od treh situacij ga je povzročila.
Trije viri neujemajočega se notranjega naslova
Odjemalec lahko pošilja z naslova, ki mu ni bil dodeljen, iz omrežja, ki ga nihče ni razglasil za njegovo, ali iz kopije identitete, ki že ima lastnika. Vsi trije ustvarijo isto vrstico dnevnika. Razlikujejo se v tem, kaj morate spremeniti. Začnite z naslovom in trenutnim seznamom dodelitev ter pustite tema dvema dejstvoma, da izbereta primer.
Za razlikovanje sta potrebni dve dejstvi: zavrnjeni naslov v dnevniku in dodelitve, ki jih strežnik šteje za trenutne. Drugo je na voljo v pogledu stanja ali upravljanja delujoče instance in je edini organ, ki se ga velja posvetovati, ker konfiguracijska datoteka beleži namere in ne trenutnega stanja.
Zapišite oboje, preden karkoli spremenite, in nato razvrstite. Posnetek zaslona, narejen pozneje, ni zapis stanja, ki je povzročilo opozorilo. Shranite tudi časovni žig, ker se dodelitve med sejami premikajo.
| 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 |
Omrežje LAN za odjemalcem in iroute
Ko odjemalec lokacije usmerja svoje zasebno omrežje, je treba to omrežje razglasiti za njegovo. Datoteka, specifična za odjemalca, z vnosom iroute to stori, vnos pa navaja predpono, ki jo odjemalec sme prenašati.
Jedrna pot, ki isto predpono usmerja v predor, je ločena zahteva in njeno dodajanje ne spremeni ničesar pri notranjem lastništvu demona.
# /etc/openvpn/server/ccd/site-b
iroute 192.168.70.0 255.255.255.0Potrdite, da se dejanska identiteta ujema z imenom datoteke, saj neujemanje pomeni, da se datoteka nikoli ne naloži in je simptom enak kot pri manjkajočem vnosu. Ne dodajajte širokega iroute za utišanje opozorila, ker to nepričakovani vir spremeni v dovoljenega, ne da bi odgovorilo, zakaj ga je odjemalec poslal. Priročnik OpenVPN 2.6 dokumentira iroute, duplicate-cn in preslikavo identitet kot ločene kontrole.
Ista identiteta na dveh strojih
Profil, kopiran na drugi prenosnik, nosi isto potrdilo in isto skupno ime. Glede na nastavitve strežnika lahko novejša povezava nadomesti starejšo, preverjanje povezave pa dobi tista instanca, ki ima lastništvo.
Zato je napaka videti občasna in se pojavi le, ko sta obe napravi budni.
Dovoljenje podvojenih skupnih imen omogoči povezavo obema, ne daje pa jima neodvisnih statičnih naslovov ali neodvisnega lastništva. Če morata dve napravi sobivati, ju registrirajte ločeno, da ima vsaka svojo identiteto in svojo dodelitev. Obravnavanje nastavitve podvajanja kot popravila tega opozorila pusti uganko na mestu in doda drugo.
Dokažite, da se je povezava spremenila
Popravek uporabite prek lastnika konfiguracije in nato znova povežite prizadetega odjemalca, da se naloži nova politika.
Ponovite isti potek in potrdite tri stvari: notranji vir paketa, instanco odjemalca, s katero ga strežnik poveže, in vedenje cilja zatem.
Če se opozorilo ustavi, aplikacija pa še vedno ne deluje, se je težava premaknila, ne izginila. Posredovanje, pravila požarnega zidu in povratna pot so ločene stopnje, prehod preverjanja povezave pa pomeni le, da je paket smel zapustiti predor.