MULTI: pogrešna izvorišna adresa od klijenta: čija je to adresa bila?
Unutarnji izvor ne odgovara klijentu koji ga je dostavio. Uskladite ga s dodjelom tunela, LAN-om iza klijenta ili dvostrukim identitetom.
Poslužiteljev zapisnik ispisuje MULTI: bad source address from client, odbacuje paket, a sesija ostaje povezana. Ta kombinacija zbunjuje ljude koji poruku čitaju kao neuspjelu autentifikaciju. Nije tako: klijent se autentificirao, a paket koji je stigao nosio je unutarnju izvorišnu adresu koju poslužitelj nije mogao povezati s tom instancom klijenta. Provjera se događa prije dostave, zato tunel izgleda zdrav dok kroz njega ne prolazi ništa korisno.
Što poslužitelj uspoređuje prije dostave
Za svaki paket koji stigne od klijenta, poslužitelj u korisničkom prostoru gleda izvorišnu adresu unutar tunela i pita svoje unutarnje stanje usmjeravanja kojem klijentu ta adresa pripada. Ako je vlasnik druga instanca ili vlasnika uopće nema, paket se odbacuje i upozorenje se ispisuje.
Uobičajena dostava kroz sučelje tunela nikada se ne događa.
Taj redoslijed objašnjava pojedinost koja ljude zbunjuje: brojači vatrozida na hostu se ne pomiču jer paket nikada nije stigao do vatrozida. Prilagodba filtriranja obrnutog puta na hostu ovdje ništa ne mijenja jer se odbijanje dogodilo u vlastitoj provjeri povezivanja demona. Čitajte poruku kao tvrdnju o vlasništvu, a zatim otkrijte koja je od tri situacije to proizvela.
Tri izvora neusklađene unutarnje adrese
Klijent možda šalje s adrese koja mu nije dodijeljena, iz mreže koju nitko nije proglasio njegovom ili iz dvostrukog identiteta koji već ima vlasnika. Sve tri daju isti redak u zapisniku. Razlikuju se po tome što morate promijeniti. Počnite s adresom i trenutačnim popisom dodjela i pustite da ta dva podatka odaberu slučaj.
Razlikovanje zahtijeva dva podatka: odbijenu adresu u zapisniku i dodjele koje poslužitelj smatra trenutačnima. Drugi je dostupan iz prikaza stanja ili upravljanja pokrenute instance i jedini je autoritet koji vrijedi provjeriti jer konfiguracijska datoteka bilježi namjere, a ne trenutačno stanje.
Zabilježite oboje prije nego što bilo što promijenite, a zatim klasificirajte. Snimka zaslona načinjena poslije nije zapis stanja koje je proizvelo upozorenje. Sačuvajte i vremensku oznaku jer se dodjele sele između sesija.
| 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 iza klijenta i iroute
Kada klijent lokacije usmjerava vlastitu privatnu mrežu, ta mreža mora biti proglašena klijentovom. Datoteka specifična za klijenta s unosom iroute to čini, a unos imenuje prefiks koji klijent smije prenositi.
Kernel ruta koja isti prefiks usmjerava u tunel zaseban je zahtjev i njezino dodavanje ništa ne mijenja u unutarnjem vlasništvu demona.
# /etc/openvpn/server/ccd/site-b
iroute 192.168.70.0 255.255.255.0Potvrdite da se stvarni identitet podudara s imenom datoteke jer nepodudarnost znači da se datoteka nikada ne učitava, a simptom je identičan nedostajućem unosu. Ne dodajte široki iroute da ušutkate upozorenje jer to neočekivani izvor pretvara u ovlašteni bez odgovora zašto ga je klijent poslao. Priručnik OpenVPN 2.6 dokumentira iroute, duplicate-cn i mapiranje identiteta kao zasebne kontrole.
Isti identitet na dva računala
Profil kopiran na drugo prijenosno računalo nosi isti certifikat i isto uobičajeno ime. Ovisno o postavkama poslužitelja, novija veza može zamijeniti stariju, a koja instanca drži vlasništvo, pobjeđuje u provjeri povezivanja.
Zbog toga se kvar čini isprekidanim i pojavljuje se samo kad su oba uređaja aktivna.
Dopuštanje dvostrukih uobičajenih imena pušta oba da se povežu, ali im ne daje neovisne statičke adrese ni neovisno vlasništvo. Ako dva uređaja moraju postojati zajedno, registrirajte ih odvojeno tako da svaki ima vlastiti identitet i vlastitu dodjelu. Tretiranje postavke dvostrukih identiteta kao popravka ovog upozorenja ostavlja misterij na mjestu i dodaje drugi.
Dokažite da se povezanost promijenila
Primijenite ispravak kroz vlasnika konfiguracije, a zatim ponovno povežite zahvaćenog klijenta da bi se nova pravila učitala.
Ponovite isti tijek i potvrdite tri stvari: unutarnji izvor paketa, instancu klijenta s kojom ga poslužitelj povezuje i ponašanje odredišta nakon toga.
Ako upozorenje prestane, ali aplikacija i dalje ne radi, problem se premjestio, a nije nestao. Prosljeđivanje, pravila vatrozida i povratni put zasebne su faze, a prolazak provjere povezivanja znači samo da je paket smio napustiti tunel.