MULTI: nepareiza avota adrese no klienta: kura tā bija adrese?
Iekšējais avots neatbilst klientam, kas to piegādāja. Saskaņojiet to ar tuneļa piešķīrumu, LAN aiz klienta vai dublētu identitāti.
Servera žurnāls izdrukā MULTI: bad source address from client, izmet paketi, un sesija paliek savienota. Šī kombinācija mulsina tos, kuri ziņojumu lasa kā autentifikācijas neveiksmi. Tā nav: klients ir autentificējies, un atnākušā pakete nesa iekšējo avota adresi, kuru serveris nevarēja saistīt ar šo klienta eksemplāru. Pārbaude notiek pirms piegādes, tāpēc tunelis izskatās vesels, kamēr caur to neiet nekas lietderīgs.
Ko serveris salīdzina pirms piegādes
Katram no klienta pienākošajam paketei lietotāja telpā darbojošais serveris skatās uz avota adresi tuneļa iekšienē un jautā savam iekšējam maršrutēšanas stāvoklim, kuram klientam šī adrese pieder. Ja īpašnieks ir cits eksemplārs vai īpašnieka vispār nav, pakete tiek atmesta un tiek izdots brīdinājums.
Parasta piegāde caur tuneļa saskarni nekad nenotiek.
Šī secība izskaidro detaļu, kas mulsina cilvēkus: resursdatora ugunsmūra skaitītāji nekustas, jo pakete nekad nav sasniegusi ugunsmūri. Apgrieztā ceļa filtrēšanas pielāgošana resursdatorā šeit neko nemaina, jo atteikums notika paša dēmona saistīšanas pārbaudē. Lasiet ziņojumu kā apgalvojumu par īpašumtiesībām, pēc tam noskaidrojiet, kura no trim situācijām to radīja.
Trīs neatbilstošas iekšējās adreses avoti
Klients var sūtīt no adreses, kas tam netika piešķirta, no tīkla, kuru neviens nav paziņojis kā viņa, vai no tādas identitātes kopijas, kurai jau ir īpašnieks. Visas trīs rada vienu un to pašu žurnāla rindu. Tās atšķiras ar to, kas jums jāmaina. Sāciet ar adresi un pašreizējo piešķīrumu sarakstu, un ļaujiet šiem diviem faktiem izvēlēties gadījumu.
Lai tās atšķirtu, vajadzīgi divi fakti: žurnālā atstumtā adrese un piešķīrumi, ko serveris uzskata par pašreizējiem. Otrais ir pieejams darbojošā eksemplāra statusa vai pārvaldības skatā, un tā ir vienīgā autoritāte, ko ir vērts konsultēt, jo konfigurācijas fails fiksē nodomus, nevis pašreizējo stāvokli.
Pierakstiet abus pirms kaut kā maiņas, pēc tam klasificējiet. Vēlāk uzņemts ekrānuzņēmums nav tā stāvokļa pieraksts, kas radīja brīdinājumu. Saglabājiet arī laikspiedolu, jo piešķīrumi pārvietojas starp sesijām.
| 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 |
LAN aiz klienta un iroute
Kad vietas klients maršrutē savu privāto tīklu, šis tīkls ir jāpaziņo kā klientam piederošs. Klientam raksturīgs fails ar iroute ierakstu to dara, un ieraksts nosauc prefiksu, ko klientam atļauts pārvadāt.
Kodola maršruts, kas to pašu prefiksu vērš uz tuneli, ir atsevišķa prasība, un tā pievienošana neko nemaina dēmona iekšējās īpašumtiesībās.
# /etc/openvpn/server/ccd/site-b
iroute 192.168.70.0 255.255.255.0Pārliecinieties, ka faktiskā identitāte atbilst faila nosaukumam, jo neatbilstība nozīmē, ka fails nekad netiek ielādēts, un simptoms ir identisks trūkstošam ierakstam. Nepievienojiet plašu iroute, lai apklusinātu brīdinājumu, jo tas negaidītu avotu pārvērš atļautā, neatbildot, kāpēc klients to nosūtīja. OpenVPN 2.6 rokasgrāmata dokumentē iroute, duplicate-cn un identitātes kartēšanu kā atsevišķas kontroles.
Viena un tā pati identitāte divās mašīnās
Uz otru klēpjdatoru nokopēts profils nes to pašu sertifikātu un to pašu vispārējo nosaukumu. Atkarībā no servera iestatījumiem jaunākais savienojums var aizstāt vecāko, un saistīšanas pārbaudi uzvar tas eksemplārs, kuram ir īpašumtiesības.
Tāpēc kļūda izskatās neregulāra un parādās tikai tad, kad abas ierīces ir nomodā.
Atļaujot dublētus vispārējos nosaukumus, abi var savienoties, taču tiem netiek dotas neatkarīgas statiskas adreses vai neatkarīgas īpašumtiesības. Ja divām ierīcēm jāpastāv kopā, reģistrējiet tās atsevišķi, lai katrai būtu sava identitāte un savs piešķīrums. Dublēšanas iestatījuma uztveršana kā šī brīdinājuma labojums atstāj noslēpumu uz vietas un pievieno otru.
Pierādiet, ka saistījums ir mainījies
Piemērojiet labojumu caur konfigurācijas īpašnieku, pēc tam atkārtoti pievienojiet skarto klientu, lai ielādētos jaunā politika.
Atkārtojiet to pašu plūsmu un apstipriniet trīs lietas: paketes iekšējo avotu, klienta eksemplāru, ar ko serveris to saista, un galamērķa uzvedību pēc tam.
Ja brīdinājums apstājas, bet lietojumprogramma joprojām neizdodas, problēma ir pārvietojusies, nevis pazudusi. Pārsūtīšana, ugunsmūra noteikumi un atgriešanās ceļš ir atsevišķi posmi, un saistīšanas pārbaudes iziešana nozīmē tikai to, ka paketei tika ļauts atstāt tuneli.