Android VPN al Cisco IOS: la kontrakto, kiun oni unue akiru

La telefono devas atingi Cisco-enirejon. Iu jam nomis la klienton, kiun oni instalos. Tio estas la malĝusta fino de la procezo, kaj tial la tunelo malsukcesas post horo da retajpado de legitimiloj.

Kion vi unue bezonas estas konekta kontrakto: protokolo, aŭtentikigo, identeco, fidata materialo, adresa atribuo kaj enkursigo, skribitaj de tiu, kiu administras la enirejon.

Akiru tion skribe kaj la elekto de kliento fariĝas serĉo. Preterlasu ĝin kaj ĉiu malsukceso aspektas kiel malbona pasvorto.

Faru la kolektadon antaŭ ol instali ion

Sendu al la posedanto de la enirejo liston kaj petu respondojn, ne produktan nomon. Naŭ eroj plene kovras profilojn de fora aliro:

1. La gastigantnomo aŭ adreso de la enirejo, kiun la kliento devas voki, kaj ĉu ĝi atingeblas de ekstere.
2. La protokolo kaj versio: IKEv2, alia generacio de IPsec, aŭ TLS-bazita servo.
3. La identeco de la kunulo, kiun la enirejo atendas, kaj kion ĝi mem prezentas reciproke.
4. Fidata materialo: kiu CA subskribas la atestilon de la enirejo, aŭ ĉu uziĝas antaŭdividita ŝlosilo.
5. Uzanta aŭtentikigo: atestilo, EAP-uzantnomo kaj pasvorto, aŭ antaŭdividita ŝlosilo.
6. La adresaro, en kiu la kliento alteriĝas, kun masko kaj enirejo.
7. DNS-serviloj por uzi ene de la tunelo, kaj ĉu la kliento devas akcepti ilin.
8. Permesitaj celaj prefiksoj, kaj ĉu trafiko ekster ili devas esti blokata.
9. La subtenataj klientaj eldonoj kaj telefonaj operaciumaj versioj, plus ajna enskribiĝa postulo.

Du el tiuj eroj kaŭzas la plej multajn eviteblajn malsukcesojn. Sen la fidata materialo vi ne povas validigi la enirejon, do ĝusta kliento aspektas difekta. Sen la permesitaj prefiksoj vi ne povas distingi enkursigan limigon de serva problemo.

La vendista nomo ne estas protokolo

Cisco IOS kaj IOS XE proponas plurajn aranĝojn de fora aliro, kaj ili ne kunhavas unu dratan formaton. IKEv2 kun FlexVPN-stila profilo ne estas la sama servo kiel pli malnova IKEv1-agordo, kaj TLS-bazita klienta servo estas denove alia produkto, ofte sur alia platformo en la sama medio.

Do kliento, kies nomo mencias la rutilaron, pruvas nenion. Ĝi povas bone realigi unu el tiuj servoj kaj neniun alian. Demandu, kiu servo estas agordita, poste kontrolu, ĉu la dokumentaro de la kliento nomas tiun servon subtenata.

Cisco propra IKEv2-dokumentaro disigas la proponon, politikon, profilon kaj ŝlosilringon kiel apartajn objektojn. Tiu strukturo utilas kiam vi legas agordon, kiun iu enmetas al vi: ĝi diras, kiu objekto tenas la agordojn gravajn por fora telefono, anstataŭ trakti la tutan dosieron kiel unu blokon.

Kion kovras la enkonstruita stako de Android

Android elmetas platforman IKEv2/IPsec-profilon per Ikev2VpnProfile, kun apartaj aŭtentikigaj tipoj por antaŭdividita ŝlosilo, RSA-atestilo kaj EAP-uzantnomo kaj pasvorto. La Ikev2VpnProfile-referenco estas la aŭtoritato pri tio, kion la konstruilo akceptas, inkluzive de la gastigantnomo de la enirejo kaj la radika CA de la servilo uzata por validigi ĝin.

Tiu API estas kapabla deklaro, ne kompatibla promeso. Ĝi diras, ke la platformo povas IKEv2 kun tiuj aŭtentikigaj tipoj. Ĝi ne diras, ke difinita OEM-agorda ekrano montras ĉiun kampon, nek ke profil-dosiero eksportita el alia produkto importiĝos.

Ĝi ankaŭ signifas, ke la enkonstruita stako ne savos vin, se la enirejo funkciigas servon, kiun la platformo ne realigas. Tiukaze vi bezonas la vendistan klienton, kiun la funkciigisto subtenas, instalita kaj agordita laŭ la funkciigista dokumentaro, anstataŭ ĉirkaŭvojo konstruita sur protokolo, kiun la telefono ne parolas.

Testu laŭ la ordo, en kiu la kontrakto estas skribita

Validigu unu tavolon samtempe kaj haltu ĉe la unua malsukceso, ĉar postaj testoj estas sensencaj ĝis la antaŭaj trapasos.

Fido. Se la kliento rifuzas la atestilon de la enirejo, nenio alia gravas. Konfirmu, ke la CA, kiun vi ricevis, subskribas la atestilon, kiun la enirejo prezentas, kaj ke la gastigantnomo, kiun vi vokis, aperas en ĝi. Lasu validigon ŝaltita; malŝalti ĝin igas identecan problemon risko de interkapto.

Aŭtentikigo. Rifuzitaj legitimiloj kaj neagordita propono produktas malsamajn erarojn sed simile aspektajn malsukcesojn. La protokolo de la enirejo decidas: ĝi diros, ĉu la propono estis akceptebla antaŭ ol diri ion pri la uzanto.

Adreso kaj DNS. Konfirmu, ke la telefono ricevis adreson el la dokumentita adresaro, poste solvu unu internan nomon. Tunelo, kiu leviĝas kun adreso kaj sen solvilo, aspektas konektita kaj kondutas kvazaŭ nenio funkcius.

Atingebleco. Testu unu permesitan celon laŭ adreso, poste laŭ nomo. Se la adreso funkcias kaj la nomo ne, vi revenis al DNS. Se neniu funkcias, komparu la prefikson, kiun vi testas, kun la permesita listo antaŭ ol tuŝi la klienton.

Malsukcesaj reĝimoj kaj la retroigo

Tenu la antaŭan funkciantan profilon eksportita kaj dokumentita antaŭ ol ŝanĝi ion, inkluzive de la CA-kaŝnomo kaj la adresaro. Tiam retroigo signifas restarigi konatan profilon, ne rekonstrui ĝin el memoro dum interrompo.

Kiam ĝi funkcias, notu la naŭ kolektajn respondojn apud la profilo. La sekva telefono, la sekva operaciuma ĝisdatigo kaj la sekva enireja ŝanĝo ĉiuj fariĝas komparo kun dokumento anstataŭ plia posttagmezo da konjektado.