Android IKEv2 fido-eraro: sendu la interan CA, ne radikon
La telefono rifuzas la enirejon ĉar la ricevita ĉeno haltas frue. Decidu: sendu la interan, riparu la identecon aŭ ŝanĝu la ŝlosiltipon.
La telefono rifuzas konektiĝi kaj presas No trusted RSA public key found for vpn.example.net, dum la sama enireja atestilo funkcias de tekkomputilo en la sama reto. La tentiga paŝo estas eldoni la atestilon denove. Antaŭe, determinu kiun el tri fiaskoj vi havas, ĉar nur unu temas pri la enhavo de la atestilo.
Tri fiaskoj malantaŭ unu mesaĝo
Android konstruas ĉenon de la enireja atestilo ĝis la CA elektita en la VPN-profilo, poste komparas la servilan nomon kun la profilo. La sciigo raportas la rezulton, ne la etapon. Fido-fiasko signifas, ke la ĉeno ne povis finiĝi per la atestiloj liveritaj en la interŝanĝo; identeca fiasko signifas, ke la ĉeno validas sed la nomo ne kongruas; algoritmo-fiasko signifas, ke la aparato aŭ la profilo ne akceptas la ŝlosiltipon aŭ la subskribon.
| What you see | What it points to | First move |
|---|---|---|
| Chain stops after the leaf in the daemon log | intermediate not loaded or not sent | load the intermediate as CA material |
| Chain validates, name differs from the profile | identity mismatch | fix the profile name or the certificate SAN |
| Chain validates, handshake still fails | key or signature not accepted | compare key type against the device |
Decidu per pruvoj anstataŭ provi riparojn laŭvice. Unu provo ĉe protokola nivelo 2 ĉe la demono diras al vi en kiu vico vi estas, kaj ĝi kostas malpli ol eldoni atestilon, kiu neniam malĝustis.
Unue decidu: ĉu alvenis la tuta ĉeno?
strongSwan sendas la atestilon agorditan por tiu konekto, kaj interaj atestiloj estas apartaj legitimiloj. Ili devas esti ŝargitaj kiel CA-atestiloj antaŭ ol la demono povas meti ilin en ŝarĝon, do aranĝo, kie la servila atestilo estas subskribita de intera, la radiko estas la fido-ankro kaj la intera vivas nur en la konstrua dosierujo de la CA, produktas ĝuste ĉi tiun fiaskon: nur la folio sur la drato, kaj la ĉeno finiĝas frue sur la telefono.
Kontrolu, kion tenas la demono per swanctl --list-certs en swanctl-instalaĵo, aŭ ipsec listcerts kun la pli malnova starter. La intera devus aperi kiel CA-atestilo kun la radiko supre. Se ĝi mankas, neniu klienta opcio helpos; se ĝi estas, iru al la sekva demando.
Poste kontrolu, ĉu ĝi estus sendita. La referenco de swanctl.conf dokumentas send_cert, kies defaŭlto ifasked sendas atestilojn nur kiam la partnero petis, dum always sendas ĉiam. La malnova ekvivalento estas leftsendcert=always en ipsec.conf. Tiu agordo regas sendadon, ne disponeblecon, do ĝi ne povas kompensi interan, kiun la demono neniam ŝargis.
Se la ĉeno estas mallonga, ŝargu la interan tie, kie la demono serĉas
Metu la interan en la CA-dosierujon, ne apud la folion: /etc/ipsec.d/cacerts por aranĝo kun ipsec.conf, /etc/swanctl/x509ca por swanctl, aŭ la vojon, kiun via pako anstataŭigas. Reŝargu la agordon kaj listigu la atestilojn denove. Iuj versioj ankaŭ sendas faskon kun la ĉeno ene de la folia dosiero, sed la CA-dosierujo estas la portebla aranĝo inter versioj kaj pakoj.
Kontrolu ankaŭ de la klienta flanko. La telefono vidas nur tion, kion portis la interŝanĝo, do la demona protokolo ĉe nivelo 2 devus montri la interan inter la senditaj atestiloj. Se ĝi montras ĝin kaj la telefono ankoraŭ fiaskas, vi estas en alia vico de la tabelo, kaj ĝustigi CA-dosierojn ne ŝanĝos la rezulton.
Se la ĉeno estas kompleta, ĉesu redakti atestilojn
Identeca fiasko estas malkongruo inter la nomo en la VPN-profilo kaj la nomo en la atestilo. Android komparas la servilan identecon, kiun vi agordis, kun la atestilo, kiun ĝi validigis, do profilo montranta adreson dum la atestilo nomas gastigan nomon, aŭ profilo kun gastiga nomo, kiun la atestilo ne kovras, fiaskas post sukcesa ĉena validigo. Riparu la malĝustan flankon kaj tenu profilon kaj atestilon kongruaj.
Algoritmo-fiasko aperas kun valida ĉeno kaj kongrua nomo. Android-eldonoj diferencas laŭ la ŝlosiltipoj kaj subskribaj skemoj, kiujn ili akceptas, kaj la profila tipo mem limigas la opciojn. Se la enirejo uzas pli malnovan aŭ nekutiman kombinaĵon, komparu ĝin kun tio, kion subtenas la aparato, antaŭ ol supozi, ke la atestilo estas difektita. La demona protokolo montros, ke la manpremo progresas pli ol en la fida kazo, kio estas la signo, ke la ĉeno ne plu estas la problemo.
Ne instalu la interan kiel uzantan radikon sur la telefono
Instali la mankantan interan kiel uzantan atestilon sur la telefono forigas la averton kaj ŝanĝas la fidan modelon de la telefono por ĉiu apo, kiu akceptas uzantajn radikojn. Ĝi ankaŭ kaŝas liveran difekton, kiu trafos la sekvan klienton, kaj lasas la enirejon sendi nekompletan ĉenon al ĉiu estonta aparato. La daŭra ripariĝo estas ĉe la servilo, unufoje, por ĉiuj klientoj.
Tenu la tri decidojn aparte en la ŝanĝprotokolo: kiuj atestiloj estis transdonitaj, kiu identeco komparita kaj kiu algoritmo intertraktita. Enirejo, kiu ĉiam sendas sian plenan ĉenon, profilo, kiu ĝuste nomas la atestilon, kaj ŝlosiltipo, kiun la ŝiparo subtenas, estas tri malgrandaj faktoj, kaj ili estas la tuta ĉi tiu fiasko.