MULTI: adresë burimore e gabuar nga klienti: e kujt ishte kjo adresë?
Burimi i brendshëm nuk përputhet me klientin që e dërgoi. Përputheni atë me një caktim tuneli, një LAN pas klientit ose një identitet të dyfishuar.
Regjistri i serverit printon MULTI: bad source address from client, e hedh paketën dhe sesioni mbetet i lidhur. Ky kombinim i huton ata që e lexojnë mesazhin si dështim vërtetimi. Nuk është: klienti u vërtetua dhe paketa që mbërriti mbante një adresë burimore të brendshme që serveri nuk mund ta lidhte me atë instancë të klientit. Kontrolli bëhet përpara dorëzimit, prandaj tuneli duket i shëndoshë ndërsa asgjë e dobishme nuk kalon përmes tij.
Çfarë krahason serveri përpara dorëzimit
Për çdo paketë që vjen nga një klient, serveri në hapësirën e përdoruesit shikon adresën burimore brenda tunelit dhe pyet gjendjen e tij të brendshme të rrugëtimit se cilit klient i përket ajo adresë. Nëse pronari është një instancë tjetër, ose nuk ka fare pronar, paketa hidhet dhe paralajmërimi lëshohet.
Dorëzimi i zakonshëm përmes ndërfaqes së tunelit nuk ndodh kurrë.
Ky rend shpjegon një detaj që i huton njerëzit: numëruesit e murit të zjarrit në host nuk lëvizin, sepse paketa nuk arriti kurrë te muri i zjarrit. Rregullimi i filtrimit të rrugës së kthimit në host nuk ndryshon asgjë këtu, pasi refuzimi ndodhi në kontrollin e lidhjes së vetë daemonit. Lexojeni mesazhin si një pohim për pronësinë, pastaj zbuloni cila nga tri situatat e prodhoi.
Tri burime të një adrese të brendshme që nuk përputhet
Klienti mund të dërgojë nga një adresë që nuk iu caktua, nga një rrjet që askush nuk e deklaroi si të vetin, ose nga një kopje e një identiteti që ka tashmë pronar. Të tria prodhojnë të njëjtin rresht regjistri. Ato ndryshojnë në atë që duhet të ndryshoni. Filloni me adresën dhe listën aktuale të caktimeve, dhe lërini këto dy fakte të zgjedhin rastin.
Për t'i dalluar duhen dy fakte: adresa e refuzuar në regjistër dhe caktimet që serveri i konsideron aktuale. E dyta është e disponueshme nga pamja e statusit ose e menaxhimit të instancës që punon, dhe është autoriteti i vetëm që vlen të konsultohet, sepse skedari i konfigurimit regjistron qëllime dhe jo gjendjen e tanishme.
Shënoni të dyja përpara se të ndryshoni çdo gjë, pastaj klasifikoni. Një pamje ekrani e bërë më pas nuk është regjistrim i gjendjes që prodhoi paralajmërimin. Ruani edhe vulën kohore, sepse caktimet lëvizin midis sesioneve.
| 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-i pas klientit dhe iroute
Kur një klient site rrugëton rrjetin e vet privat, ai rrjet duhet të deklarohet si i klientit. Një skedar specifik i klientit me një hyrje iroute e bën këtë, dhe hyrja emërton prefiksin që klienti lejohet të transportojë.
Një rrugë kernel që drejton të njëjtin prefiks drejt tunelit është kërkesë e veçantë, dhe shtimi i saj nuk ndryshon asgjë në pronësinë e brendshme të daemonit.
# /etc/openvpn/server/ccd/site-b
iroute 192.168.70.0 255.255.255.0Konfirmoni që identiteti efektiv përputhet me emrin e skedarit, pasi mospërputhja do të thotë që skedari nuk ngarkohet kurrë dhe simptomi është identik me një hyrje që mungon. Mos shtoni një iroute të gjerë për të heshtur paralajmërimin, sepse kjo e kthen një burim të papritur në të autorizuar pa u përgjigjur se pse klienti e dërgoi. Manuali i OpenVPN 2.6 dokumenton iroute, duplicate-cn dhe hartëzimin e identitetit si kontrolle të veçanta.
I njëjti identitet në dy makina
Një profil i kopjuar në një laptop të dytë mbart të njëjtin certifikatë dhe të njëjtin emër të përbashkët. Në varësi të cilësimeve të serverit, lidhja më e re mund të zëvendësojë atë më të vjetër, dhe kontrollin e lidhjes e fiton instanca që mban pronësinë.
Kjo e bën defektin të duket i ndërprerë dhe shfaqet vetëm kur të dy pajisjet janë zgjuar.
Lejimi i emrave të përbashkët të dyfishuar i lë të dyja të lidhen, por nuk u jep adresa statike të pavarura ose pronësi të pavarur. Nëse dy pajisje duhet të bashkëjetojnë, regjistrojini veçmas, që secila të ketë identitetin dhe caktimin e vet. Trajtimi i cilësimit të dyfishuar si riparim i këtij paralajmërimi e lë misterin në vend dhe shton një të dytë.
Provoni që lidhja ndryshoi
Zbatojeni korrigjimin përmes pronarit të konfigurimit, pastaj rilidhni klientin e prekur që politika e re të ngarkohet.
Përsëritni të njëjtin rrjedhë dhe konfirmoni tri gjëra: burimin e brendshëm të paketës, instancën e klientit me të cilën serveri e lidh, dhe sjelljen e destinacionit më pas.
Nëse paralajmërimi ndalon por aplikacioni ende dështon, problemi u zhvendos dhe nuk u zhduk. Përcjellja, rregullat e murit të zjarrit dhe rruga e kthimit janë faza të veçanta, dhe kalimi i kontrollit të lidhjes do të thotë vetëm se paketës iu lejua të linte tunelin.