MULTI: halb lähteaadress kliendilt: kelle aadress see oli?
Sisemine allikas ei vasta kliendile, kes selle edastas. Sobitage see tunnelimäärangu, kliendi taga oleva LAN-i või dubleeritud identiteediga.
Serveri logi trükib MULTI: bad source address from client, viskab paketi ära ja sessioon jääb ühendatuks. See kombinatsioon ajab segadusse inimesi, kes loevad teadet autentimise ebaõnnestumisena. See pole nii: klient autentis end ja saabunud pakett kandis sisemist lähteaadressi, mida server ei suutnud selle kliendi eksemplariga siduda. Kontroll toimub enne kohaletoimetamist, seepärast näeb tunnel terve välja, samal ajal kui midagi kasulikku sellest läbi ei lähe.
Mida server enne kohaletoimetamist võrdleb
Iga kliendilt saabuva paketi puhul vaatab kasutajaruumi server tunneli sees olevat lähteaadressi ja küsib oma sisemisest marsruutimise olekust, millisele kliendile see aadress kuulub. Kui omanik on teine eksemplar või omanikku pole üldse, siis pakett tühistatakse ja hoiatus väljastatakse.
Tavaline kohaletoimetamine tunneli liidese kaudu ei toimu kunagi.
See järjekord selgitab detaili, mis inimesi hämmastab: hosti tulemüüri loendurid ei liigu, sest pakett ei jõudnud tulemüürini kunagi. Pöördtee filtreerimise kohandamine hostis ei muuda siin midagi, sest tagasilükkamine toimus deemonile omases sidumiskontrollis. Lugege teadet väitena omandiõiguse kohta ja uurige seejärel, milline kolmest olukorrast selle tekitas.
Kolm mittestattuvat sisemise aadressi allikat
Klient võib saata aadressilt, mida talle ei määratud, võrgust, mida keegi ei kuulutanud tema omaks, või identiteedi duplikaadilt, millel on juba omanik. Kõik kolm tekitavad sama logirea. Need erinevad selle poolest, mida peate muutma. Alustage aadressist ja praegusest määrangute loendist ning laske neil kahel faktil juhtum valida.
Nende eristamiseks on vaja kahte fakti: logis tagasi lükatud aadress ja määrangud, mida server peab praegusteks. Teine on saadaval jooksva eksemplari oleku- või haldusvaates ja on ainus autoriteet, mida tasub konsulteerida, sest konfiguratsioonifail kirjendab kavatsusi, mitte praegust olekut.
Kirjutage mõlemad üles enne, kui midagi muudate, ja seejärel liigitage. Hiljem tehtud ekraanipilt ei ole selle oleku kirje, mis hoiatuse tekitas. Hoidke ka ajatemplit, sest määrangud liiguvad sessioonide vahel.
| 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 |
Kliendi taga olev LAN ja iroute
Kui saidi klient marsruudib oma privaatvõrku, tuleb see võrk kuulutada kliendile kuuluvaks. Kliendipõhine fail iroute-kirjega teeb seda ja kirje nimetab prefiksi, mida kliendil on lubatud kanda.
Kerneli marsruut, mis suunab sama prefiksi tunnelisse, on eraldi nõue ja selle lisamine ei muuda deemoni sisemises omanduses midagi.
# /etc/openvpn/server/ccd/site-b
iroute 192.168.70.0 255.255.255.0Kinnitage, et tegelik identiteet vastab failinimele, sest mittevastavus tähendab, et faili ei laadita kunagi, ja sümptom on identne puuduva kirjega. Ärge lisage laia iroute'i hoiatuse vaigistamiseks, sest see muudab ootamatu allika lubatuks, vastamata, miks klient selle saatis. OpenVPN 2.6 käsiraamat dokumenteerib iroute'i, duplicate-cn ja identiteedi vastendamise eraldi juhtelementidena.
Sama identiteet kahes masinas
Teise sülearvutisse kopeeritud profiil kannab sama sertifikaati ja sama üldnime. Sõltuvalt serveri seadetest võib uuem ühendus asendada vanema ja sidumiskontrollis võidab see eksemplar, kellel on omand.
Seetõttu tundub rike vahelduvana ja ilmneb ainult siis, kui mõlemad seadmed on ärkvel.
Dubletteeritud üldnimede lubamine laseb mõlemal ühenduda, kuid ei anna neile sõltumatuid staatilisi aadresse ega sõltumatut omandit. Kui kaks seadet peavad koos eksisteerima, registreerige need eraldi, et kummagi oma identiteet ja oma määrang oleks. Dublettseade käsitlemine selle hoiatuse parandusena jätab mõistatuse paigale ja lisab teise.
Tõestage, et sidumine muutus
Rakendage parandus konfiguratsiooni omaniku kaudu ja seejärel ühendage mõjutatud klient uuesti, et uus poliitika laaditaks.
Korrake sama voogu ja kinnitage kolm asja: paketi sisemine allikas, kliendi eksemplar, millega server selle seob, ja sihtkoha käitumine pärast seda.
Kui hoiatus lakkab, kuid rakendus ikka ei tööta, on probleem liikunud, mitte kadunud. Edastamine, tulemüüri reeglid ja tagasitee on eraldi etapid ning sidumiskontrolli läbimine tähendab ainult, et paketil lubati tunnelist lahkuda.