MULTI: malbona fontadreso de kliento: kies adreso ĝi estis?
La interna fonto ne kongruas kun la kliento, kiu ĝin liveris. Kunigu ĝin kun tunela atribuo, LAN malantaŭ la kliento aŭ duobla identeco.
La servila protokolo presas MULTI: bad source address from client, forĵetas la paketon, kaj la seanco restas konektita. Tiu kombino konfuzas homojn, kiuj legas la mesaĝon kiel malsukcesan aŭtentikigon. Ĝi ne estas tio: la kliento aŭtentikiĝis, kaj la alveninta paketo portis internan fontadreson, kiun la servilo ne povis ligi al tiu klienta kazo. La kontrolo okazas antaŭ livero, tial la tunelo aspektas sana dum nenio utila trapasas ĝin.
Kion la servilo komparas antaŭ livero
Por ĉiu paketo alvenanta de kliento, la uzantspaca servilo rigardas la fontadreson ene de la tunelo kaj demandas sian internan enkursigad-staton, al kiu kliento tiu adreso apartenas. Se la posedanto estas alia kazo, aŭ se posedanto tute mankas, la paketo estas forigita kaj la averto eldoniĝas.
Ordinara livero tra la tunela interfaco neniam okazas.
Tiu ordo klarigas detalon, kiu konfuzas homojn: la nombriloj de la gastiga fajromuro ne moviĝas, ĉar la paketo neniam atingis la fajromuron. Ĝustigi la inversvojan filtradon sur la gastigo ŝanĝas nenion ĉi tie, ĉar la malakcepto okazis en la propra asocia kontrolo de la demono. Legu la mesaĝon kiel aserton pri posedo, poste eltrovu, kiun el tri situacioj ĝi kaŭzis.
Tri fontoj de malkongrua interna adreso
La kliento eble sendas el adreso, kiun oni ne atribuis al ĝi, el reto, kiun neniu deklaris ĝia, aŭ el duoblaĵo de identeco, kiu jam havas posedanton. Ĉiuj tri produktas la saman protokolan linion. Ili diferenciĝas en tio, kion vi devas ŝanĝi. Komencu per la adreso kaj la aktuala atribuolisto, kaj lasu tiujn du faktojn elekti la kazon.
Distingi ilin postulas du faktojn: la malakceptitan adreson en la protokolo, kaj la atribuojn, kiujn la servilo konsideras aktualaj. La dua estas havebla el la stata aŭ administra vido de la kuranta kazo, kaj ĝi estas la sola aŭtoritato inda konsulti, ĉar konfigura dosiero registras intencojn, ne la nunan staton.
Notu ambaŭ antaŭ ol ŝanĝi ion ajn, poste klasifiku. Ekrankopio farita poste ne estas registro de la stato, kiu kaŭzis la averton. Konservu ankaŭ la tempomarkon, ĉar atribuoj moviĝas inter seancoj.
| 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 |
La LAN malantaŭ kliento kaj iroute
Kiam eja kliento enkursigadas sian propran privatan reton, tiu reto devas esti deklarita kiel apartenanta al la kliento. Klient-specifa dosiero kun iroute-enskribo faras tion, kaj la enskribo nomas la prefikson, kiun la kliento rajtas porti.
Kerna enkursigilo montranta la saman prefikson al la tunelo estas aparta postulo, kaj aldoni ĝin ŝanĝas nenion pri la interna posedo de la demono.
# /etc/openvpn/server/ccd/site-b
iroute 192.168.70.0 255.255.255.0Konfirmu, ke la efektiva identeco kongruas kun la dosiernomo, ĉar malkongruo signifas, ke la dosiero neniam ŝargiĝas kaj la simptomo identas al mankanta enskribo. Ne aldonu larĝan iroute por silentigi la averton, ĉar tio igas neatenditan fonton rajtigita sen respondi, kial la kliento sendis ĝin. La manlibro de OpenVPN 2.6 dokumentas iroute, duplicate-cn kaj identecmapigon kiel apartajn kontrolojn.
La sama identeco sur du maŝinoj
Profilo kopiita al dua tekkomputilo portas la saman atestilon kaj la saman komunan nomon. Laŭ la agordoj de la servilo, la pli nova konekto povas anstataŭigi la pli malnovan, kaj kiu kazo tenas la posedon, tiu gajnas la asocian kontrolon.
Tio igas la eraron ŝajni intermita kaj aperi nur kiam ambaŭ aparatoj estas vekaj.
Permesi duoblajn komunnomojn lasas ambaŭ konektiĝi, sed ne donas al ili sendependajn statikajn adresojn aŭ sendependan posedon. Se du aparatoj devas kunekzisti, registru ilin aparte, por ke ĉiu havu sian propran identecon kaj sian propran atribuon. Trakti la duoblan agordon kiel riparon por ĉi tiu averto lasas la misteron surloke kaj aldonas duan.
Pruvu, ke la asocio ŝanĝiĝis
Apliku la korekton tra la posedanto de la konfiguracio, poste rekonektu la trafitan klienton, por ke la nova politiko ŝargiĝu.
Ripetu la saman fluon kaj konfirmu tri aferojn: la internan fonton de la paketo, la klientan kazon, kiun la servilo asocias kun ĝi, kaj la konduton de la celo poste.
Se la averto ĉesas sed la aplikaĵo ankoraŭ malsukcesas, la problemo moviĝis anstataŭ malaperi. Plusendo, fajromuraj reguloj kaj la revena vojo estas apartaj etapoj, kaj trapasi la asocian kontrolon nur signifas, ke la paketo rajtis lasi la tunelon.