VPN Android ke Cisco IOS: kontrak yang perlu diperoleh dahulu

Telefon perlu sampai ke gerbang Cisco. Seseorang sudah menamakan klien yang perlu dipasang. Itu hujung proses yang salah, dan itulah sebabnya terowong gagal selepas sejam menaip semula kelayakan.

Apa yang anda perlukan dahulu ialah kontrak sambungan: protokol, pengesahan, identiti, bahan kepercayaan, peruntukan alamat dan penghalaan, ditulis oleh pihak yang mengendalikan gerbang.

Dapatkannya secara bertulis dan pilihan klien menjadi hanya carian. Langkau dan setiap kegagalan kelihatan seperti kata laluan yang salah.

Lakukan pengumpulan maklumat sebelum memasang apa-apa

Hantar senarai kepada pemilik gerbang dan minta jawapan, bukan nama produk. Sembilan perkara merangkumi profil akses jauh sepenuhnya:

1. Nama hos atau alamat gerbang yang perlu didail oleh klien, dan sama ada boleh dicapai dari luar.
2. Protokol dan versinya: IKEv2, generasi IPsec yang lain, atau perkhidmatan berasaskan TLS.
3. Identiti rakan yang dijangka oleh gerbang, dan apa yang ia kemukakan balik.
4. Bahan kepercayaan: CA mana yang menandatangani sijil gerbang, atau sama ada kunci yang dikongsi dahulu digunakan.
5. Pengesahan pengguna: sijil, nama pengguna dan kata laluan EAP, atau kunci yang dikongsi dahulu.
6. Kumpulan alamat tempat klien mendarat, bersama topeng dan gerbang.
7. Pelayan DNS untuk digunakan di dalam terowong, dan sama ada klien perlu menerimanya.
8. Awalan destinasi yang dibenarkan, dan sama ada trafik di luarnya perlu disekat.
9. Keluaran klien yang disokong dan versi sistem pengendalian telefon, serta apa-apa keperluan pendaftaran.

Dua daripada perkara itu menyebabkan kebanyakan kegagalan yang boleh dielakkan. Tanpa bahan kepercayaan anda tidak boleh mengesahkan gerbang, jadi klien yang betul kelihatan rosak. Tanpa awalan yang dibenarkan anda tidak boleh membezakan kekangan penghalaan daripada masalah perkhidmatan.

Nama vendor bukan protokol

Cisco IOS dan IOS XE menawarkan beberapa aturan akses jauh, dan semuanya tidak berkongsi satu format penghantaran. IKEv2 dengan profil bergaya FlexVPN bukan perkhidmatan yang sama seperti konfigurasi IKEv1 yang lebih lama, dan perkhidmatan klien berasaskan TLS ialah produk lain lagi, selalunya pada platform lain dalam persekitaran yang sama.

Jadi klien yang namanya menyebut vendor penghala tidak membuktikan apa-apa. Ia mungkin melaksanakan salah satu perkhidmatan itu dengan baik dan tiada satu pun yang lain. Tanya perkhidmatan mana yang dikonfigurasikan, kemudian semak sama ada dokumentasi klien menamakan perkhidmatan itu sebagai disokong.

Dokumentasi IKEv2 Cisco sendiri memisahkan cadangan, dasar, profil dan gelang kunci sebagai objek berasingan. Struktur itu berguna apabila anda membaca konfigurasi yang seseorang tampal kepada anda: ia memberitahu anda objek mana yang menyimpan tetapan penting bagi telefon jauh, bukan menganggap seluruh fail sebagai satu ketulan.

Apa yang diliputi oleh tindanan terbina dalam Android

Android mendedahkan profil IKEv2/IPsec platform melalui Ikev2VpnProfile, dengan jenis pengesahan berasingan untuk kunci yang dikongsi dahulu, sijil RSA serta nama pengguna dan kata laluan EAP. Rujukan Ikev2VpnProfile ialah kuasa tentang apa yang diterima oleh pembina, termasuk nama hos gerbang dan CA akar pelayan yang digunakan untuk mengesahkannya.

API itu ialah pernyataan keupayaan, bukan janji keserasian. Ia menyatakan platform boleh melakukan IKEv2 dengan jenis pengesahan tersebut. Ia tidak menyatakan bahawa skrin Tetapan OEM tertentu mendedahkan setiap medan, mahupun bahawa fail profil yang dieksport daripada produk lain akan diimport.

Ini juga bermakna tindanan terbina dalam tidak akan menyelamatkan anda jika gerbang menjalankan perkhidmatan yang tidak dilaksanakan oleh platform. Dalam kes itu anda memerlukan klien vendor yang disokong oleh operator, dipasang dan dikonfigurasikan seperti yang didokumenkan oleh operator, bukan jalan pintas yang dibina atas protokol yang tidak dituturkan oleh telefon.

Uji mengikut urutan kontrak ditulis

Sahkan satu lapisan pada satu masa dan berhenti pada kegagalan pertama, kerana ujian kemudian tidak bermakna sehingga yang terdahulu lulus.

Kepercayaan. Jika klien menolak sijil gerbang, tiada apa lagi yang penting. Pastikan CA yang diberikan menandatangani sijil yang dikemukakan oleh gerbang, dan nama hos yang anda dail ada di dalamnya. Biarkan pengesahan aktif; mematikannya mengubah masalah identiti menjadi risiko penyadapan.

Pengesahan. Kelayakan yang ditolak dan cadangan yang tidak sepadan menghasilkan ralat berbeza tetapi kegagalan yang kelihatan serupa. Log gerbang ialah penentu: ia akan menyatakan sama ada cadangan itu boleh diterima sebelum menyatakan apa-apa tentang pengguna.

Alamat dan DNS. Pastikan telefon menerima alamat daripada kumpulan yang didokumenkan, kemudian selesaikan satu nama dalaman. Terowong yang naik dengan alamat tetapi tanpa penyelesai kelihatan bersambung dan berkelakuan seolah-olah tiada apa yang berfungsi.

Kebolehcapaian. Uji satu destinasi yang dibenarkan melalui alamat, kemudian melalui nama. Jika alamat berfungsi dan nama tidak, anda kembali ke DNS. Jika kedua-duanya tidak berfungsi, bandingkan awalan yang anda uji dengan senarai yang dibenarkan sebelum menyentuh klien.

Mod kegagalan dan pengunduran

Simpan profil kerja sebelumnya dieksport dan didokumenkan sebelum mengubah apa-apa, termasuk alias CA dan kumpulan alamat. Pengunduran kemudian bermakna memulihkan profil yang dikenali, bukan membinanya semula daripada ingatan semasa gangguan.

Apabila ia berfungsi, catat sembilan jawapan pengumpulan di sebelah profil. Telefon seterusnya, kemas kini sistem seterusnya dan perubahan gerbang seterusnya semuanya menjadi perbandingan dengan dokumen dan bukan lagi satu petang meneka.