VPN ng Android papuntang Cisco IOS: ang kontratang dapat makuha muna

Kailangang maabot ng telepono ang isang Cisco gateway. May nakapangalan na sa client na dapat i-install. Iyon ang maling dulo ng proseso, at iyon ang dahilan kung bakit nabibigo ang tunnel pagkatapos ng isang oras na muling pag-type ng mga kredensyal.

Ang kailangan mo muna ay isang kontrata ng koneksyon: protocol, authentication, identity, trust material, paglalaan ng address at routing, na isinulat ng nagpapatakbo ng gateway.

Kunin ito sa sulat at ang pagpili ng client ay magiging paghahanap na lamang. Laktawan ito at bawat pagpalya ay magmumukhang maling password.

Gawin ang pagkuha ng impormasyon bago mag-install ng kahit ano

Magpadala ng listahan sa may-ari ng gateway at humingi ng sagot, hindi pangalan ng produkto. Sinasaklaw ng siyam na aytem ang remote-access profile nang buo:

1. Ang hostname o address ng gateway na dapat tawagan ng client, at kung naaabot ito mula sa labas.
2. Ang protocol at bersyon: IKEv2, ibang henerasyon ng IPsec, o serbisyong nakabatay sa TLS.
3. Ang identity ng kapares na inaasahan ng gateway, at ang ipinapakita nito pabalik.
4. Trust material: aling CA ang pumipirma sa certificate ng gateway, o kung may pre-shared key.
5. Authentication ng user: certificate, EAP username at password, o pre-shared key.
6. Ang address pool kung saan bumabagsak ang client, kasama ang mask at gateway.
7. Mga DNS server na gagamitin sa loob ng tunnel, at kung dapat tanggapin ng client.
8. Mga pinapayagang destination prefix, at kung dapat harangin ang trapik sa labas ng mga ito.
9. Ang mga sinusuportahang bersyon ng client at ng operating system ng telepono, kasama ang anumang kailangan sa enrollment.

Dalawang aytem sa mga iyon ang dahilan ng karamihan ng maiiwasang pagpalya. Kung walang trust material, hindi mo ma-validate ang gateway, kaya mukhang sira ang tamang client. Kung walang pinapayagang prefix, hindi mo makikilala ang paghihigpit sa routing mula sa problema sa serbisyo.

Ang pangalan ng vendor ay hindi protocol

Nag-aalok ang Cisco IOS at IOS XE ng ilang ayos ng remote access, at hindi sila nagbabahagi ng isang wire format. Ang IKEv2 na may profile na parang FlexVPN ay hindi ang parehong serbisyo ng lumang IKEv1 configuration, at ang client service na nakabatay sa TLS ay ibang produkto na naman, madalas sa ibang platform sa parehong kapaligiran.

Kaya ang client na ang pangalan ay nagbabanggit ng vendor ng router ay walang pinapatunayan. Maaaring mahusay nitong ipatupad ang isa sa mga serbisyong iyon at wala sa iba. Itanong kung aling serbisyo ang naka-configure, pagkatapos tingnan kung binabanggit ng dokumentasyon ng client ang serbisyong iyon bilang sinusuportahan.

Ang dokumentasyon ng IKEv2 ng Cisco mismo ay naghihiwalay ng proposal, policy, profile at keyring bilang magkakaibang object. Kapaki-pakinabang ang estrukturang iyon kapag binabasa mo ang configuration na ipinaste ng iba sa iyo: sinasabi nito kung aling object ang may mga setting na mahalaga para sa malayong telepono, sa halip na ituring ang buong file bilang isang buo.

Ano ang sakop ng built-in na stack ng Android

Inilalabas ng Android ang platform IKEv2/IPsec profile sa pamamagitan ng Ikev2VpnProfile, na may hiwalay na uri ng authentication para sa pre-shared key, RSA certificate, at EAP username at password. Ang Ikev2VpnProfile reference ang awtoridad sa kung ano ang tinatanggap ng builder, kasama ang hostname ng gateway at ang server root CA na ginagamit sa pag-validate nito.

Ang API na iyon ay pahayag ng kakayahan, hindi pangako ng compatibility. Sinasabi nitong kaya ng platform ang IKEv2 sa mga uri ng authentication na iyon. Hindi nito sinasabi na ang isang partikular na OEM settings screen ay nagpapakita ng bawat field, o na ang profile file na in-export mula sa ibang produkto ay mai-import.

Ibig sabihin din nito na hindi ka maililigtas ng built-in na stack kung may serbisyong pinapatakbo ang gateway na hindi ipinatutupad ng platform. Sa ganoong kaso kailangan mo ang client ng vendor na sinusuportahan ng operator, naka-install at naka-configure ayon sa dokumentasyon ng operator, hindi isang paraan sa paligid na itinayo sa protocol na hindi kinakausap ng telepono.

Subukan sa ayos na nakasulat ang kontrata

I-validate ang isang layer sa isang pagkakataon at huminto sa unang pagpalya, dahil walang kabuluhan ang mga susunod na test hangga't hindi pumapasa ang mga nauna.

Tiwala. Kung tinatanggihan ng client ang certificate ng gateway, wala nang ibang mahalaga. Tiyakin na ang CA na ibinigay sa iyo ay pumipirma sa certificate na ipinapakita ng gateway, at naroon ang hostname na tinawagan mo. Panatilihing bukas ang validation; ang patayin ito ay ginagawang panganib ng interception ang isang problema sa identity.

Authentication. Ang tinanggihang kredensyal at ang hindi tugmang proposal ay nagbibigay ng magkaibang error pero magkamukhang pagpalya. Ang log ng gateway ang magpapasya: sasabihin nito kung katanggap-tanggap ang proposal bago ito magsabi ng anuman tungkol sa user.

Address at DNS. Tiyakin na nakatanggap ang telepono ng address mula sa dokumentadong pool, pagkatapos i-resolve ang isang panloob na pangalan. Ang tunnel na bumangon na may address pero walang resolver ay mukhang konektado at kumikilos na parang walang gumagana.

Abot. Subukan ang isang pinapayagang destinasyon sa address, pagkatapos sa pangalan. Kung gumagana ang address at hindi ang pangalan, bumalik ka sa DNS. Kung wala sa dalawa ang gumagana, ihambing ang prefix na sinusubukan mo sa pinapayagang listahan bago hawakan ang client.

Mga paraan ng pagpalya at ang rollback

Panatilihing naka-export at dokumentado ang dating gumaganang profile bago magbago ng anuman, kasama ang CA alias at ang address pool. Ang rollback noon ay nangangahulugang ibalik ang kilalang profile, hindi ito muling buuin mula sa memorya habang may outage.

Kapag gumana, itala ang siyam na sagot sa pagkuha ng impormasyon sa tabi ng profile. Ang susunod na telepono, ang susunod na update ng OS at ang susunod na pagbabago sa gateway ay magiging paghahambing sa isang dokumento sa halip na isa na namang hapon ng hula.