Kehidupan seorang insinyur jaringan bahagia dan tanpa beban sampai gateway kripto bersertifikat muncul. Setuju, berurusan dengan solusi yang dirancang untuk mengenkripsi saluran transmisi data sesuai dengan GOST bukanlah tugas yang mudah. Ada baiknya jika ini adalah produk terkenal dan mudah dimengerti. Mari kita mengingat "S-Terra" yang sama (kita telah menulis tentang "S-Terra Gateway" mereka ). Tapi apa yang harus dilakukan dengan solusi yang lebih eksotis berdasarkan protokol enkripsi mereka sendiri, misalnya, "Continent" (dari "Security Code") atau ViPNet Coordinator HW (dari "Infotex")? Dalam artikel ini saya akan mencoba memfasilitasi perendaman di dunia ViPNet (kami juga akan membicarakan tentang Benua suatu hari nanti) dan memberi tahu Anda masalah apa yang saya hadapi sendiri dan bagaimana saya menyelesaikannya.
Saya akan segera membuat reservasi bahwa kita akan berbicara tentang versi 4.2.1 yang disertifikasi oleh FSB dan FSTEC untuk hari ini. Dalam versi 4.3.x saat ini, banyak hal menarik telah muncul, misalnya, DGD (Deteksi Gateway Mati) dan mekanisme pengelompokan yang dimodifikasi, yang menyediakan peralihan yang hampir mulus, tetapi untuk saat ini ini adalah masa depan. Saya tidak akan mendalami lebih dalam tentang perintah dan file konfigurasi, dengan fokus pada perintah dan variabel utama, dan penjelasan rinci tentang "kunci" ini dapat ditemukan di dokumentasi.
Pertama, mari kita cari tahu bagaimana semuanya bekerja. Jadi, koordinator ViPNet melakukan beberapa fungsi. Pertama, ini adalah gerbang kripto (CG), yang memungkinkan Site-to-site dan RA VPN. Kedua, ini adalah server-router amplop yang berisi data layanan terenkripsi (direktori dan kunci) atau data aplikasi klien (pertukaran file, surat bisnis). Ngomong-ngomong, di direktori itulah file yang berisi informasi tentang objek jaringan ViPNet, termasuk nama, pengenal, alamat, koneksi, disimpan. Koordinator juga menjadi sumber informasi layanan untuk kliennya.
Selain itu, ia dapat menyalurkan lalu lintas dari komputer jaringan di mana perangkat lunak ViPNet tidak diinstal. Omong-omong, para ahli yang bekerja dengan solusi ini sering menyebut host terbuka bukan sebagai "node terowongan", tetapi hanya "terowongan". Ini bisa membingungkan bagi para insinyur yang terbiasa dengan solusi VPN lain, di mana terowongan mengacu pada koneksi PtP antara jaringan.
Sebagai protokol enkripsi, ViPNet menggunakan IPlir, yang juga dikembangkan oleh Infotex. Untuk merangkum lalu lintas, protokol transport IP / 241 (jika lalu lintas tidak meninggalkan domain siaran), UDP / 55777 dan TCP / 80 (jika UDP tidak tersedia) digunakan.
Konsep membangun sambungan aman didasarkan pada apa yang disebut "sambungan", yang terdiri dari dua jenis. Yang pertama (di tingkat node) diperlukan untuk membangun koneksi yang aman antar node, yang terakhir (di tingkat pengguna) diperlukan untuk pengoperasian aplikasi klien. Tetapi ada pengecualian: Node administrator ViPNet memerlukan kedua jenis komunikasi tersebut.
Apa yang salah dalam skema ini? Seperti yang diperlihatkan oleh latihan, sebenarnya ada banyak keanehan dari pekerjaan, dan tidak semua masalah dapat diselesaikan secara intuitif, tanpa “bantuan penonton”, tetapi sesuatu harus diterima begitu saja.
Koordinator tidak tersedia
“Kami tidak memiliki koordinator / klien / terowongan yang tersedia. Apa yang harus dilakukan?" - pertanyaan paling umum yang diajukan pemula saat menyiapkan ViPNet. Satu-satunya tindakan yang benar dalam situasi seperti ini adalah mengaktifkan pendaftaran semua lalu lintas pada koordinator dan melihat log paket IP, yang merupakan alat paling penting untuk memecahkan masalah semua jenis masalah jaringan. Metode ini menghemat 80% kasus. Bekerja dengan log paket IP juga membantu untuk lebih memahami mekanisme operasi node jaringan ViPNet.
Amplop tidak terkirim
Tetapi log paket IP, sayangnya, tidak berguna dalam hal amplop. Mereka dikirim menggunakan modul transport (mftp), yang memiliki jurnal dan antriannya sendiri. Secara default, amplop dikirim ke koordinator "sendiri" klien (yaitu, yang node didaftarkan), dan kemudian melalui saluran antar-server yang dikonfigurasi antara koordinator (yaitu, tidak secara langsung melalui saluran aman). Artinya jika Anda ingin mengirim surat melalui surat bisnis, klien akan mengemasnya dalam amplop dan mengirimkannya terlebih dahulu ke koordinatornya. Lebih jauh dalam perjalanan mungkin ada beberapa koordinator lagi, dan hanya setelah itu amplop akan mencapai node penerima.
Dua kesimpulan menyusul dari ini. Pertama, komunikasi antara klien tidak harus diperiksa (dengan menekan F5 dan ikon yang sesuai di menu) untuk mengirimkan amplop. Kedua, jika koneksi di antara mereka masih diperiksa, ini tidak menjamin pengiriman, karena masalahnya mungkin ada di salah satu saluran antar-server.
Dalam kasus yang tidak jelas, adalah mungkin untuk mendiagnosis perjalanan amplop melalui saluran interserver atau antara klien dan koordinator menggunakan jurnal dan antrian amplop, serta log pada koordinator. Selain itu, modul transport klien ViPNet dapat dikonfigurasi untuk pengiriman langsung amplop, pengiriman melalui folder bersama, atau SMTP / POP3 (tetapi ini adalah opsi yang benar-benar eksotis). Kami tidak akan menyelami pengaturan ini.
Konsekuensi berkedip
Mungkin menjadi masalah untuk meningkatkan ke versi saat ini dari perangkat keras lama yang telah digunakan dalam waktu lama, misalnya, sebagai suku cadang. Dalam prosesnya, kesalahan "perangkat keras yang tidak didukung" mungkin muncul, yang menunjukkan bahwa Anda memiliki platform perangkat keras yang benar-benar tidak didukung dari jalur G1 yang sudah ketinggalan zaman (ini adalah HW100 E1 / E2 dan HW1000 Q1), atau tentang masalah dalam pengaturan BIOS atau informasi yang salah yang tertanam di DMI. Apakah akan mengelola DMI sendiri, semua orang memutuskan sendiri, karena ada risiko mengubah peralatan menjadi "batu bata" yang tidak berguna. Dengan BIOS, ini sedikit lebih mudah: pengaturan sistem yang salah ada dalam fungsi HT (Hyper Threading) yang dinonaktifkan atau mode ACHI (Advanced Host Controller Interface) yang dinonaktifkan untuk HDD. Agar tidak menebak apa sebenarnya masalahnya, Anda dapat merujuk ke USB flash drive tempat firmware tersebut diproduksi.File dengan informasi diagnostik dibuat di dalamnya, khususnya, semua platform yang didukung terdaftar di file verbose.txt dengan hasil pemeriksaan dengan milik Anda. Misalnya, kesalahan cpu :: Vendor (# 3) == 'GenuineIntel' 24 kali => [Gagal] kemungkinan besar menunjukkan bahwa HT dinonaktifkan. Ngomong-ngomong, flashing sering disalahartikan dengan memperbarui, tetapi ini adalah proses yang berbeda. Selama pembaruan, semua pengaturan disimpan, dan parameter yang dijelaskan di atas tidak dicentang. Dan saat Anda reflash, Anda kembali ke pengaturan pabrik.Selama pembaruan, semua pengaturan disimpan, dan parameter yang dijelaskan di atas tidak dicentang. Dan saat Anda reflash, Anda kembali ke pengaturan pabrik.Selama pembaruan, semua pengaturan disimpan, dan parameter yang dijelaskan di atas tidak dicentang. Dan saat Anda reflash, Anda kembali ke pengaturan pabrik.
Konfigurasi non-informatif
File konfigurasi utama untuk HW adalah "iplir.conf", tetapi tidak selalu mencerminkan pengaturan saat ini. Faktanya adalah pada saat memuat driver IPlir, konfigurasi ini diinterpretasikan sesuai dengan logika yang ditetapkan, dan tidak semua informasi dapat dimuat ke driver (misalnya, jika ada konflik alamat IP). Insinyur yang telah bekerja dengan koordinator perangkat lunak Linux mungkin mengetahui perintah "iplirdiag", yang menampilkan pengaturan node saat ini yang dimuat ke dalam driver. Di HW, perintah ini juga ada dalam mode "admin escape".
Output yang paling populer adalah:
iplirdiag -s ipsettings --node-info <node id> ## menampilkan informasi tentang node
iplirdiag -s ipsettings --v-tun-table ## menampilkan semua tunnel yang dimuat ke driver
Mari kita membahas sedikit tentang mode "admin escape". Sebenarnya, ini adalah jalan keluar dari shell ViPNet ke bash. Di sini saya setuju dengan vendor, yang merekomendasikan penggunaan mode ini hanya untuk diagnostik dan membuat modifikasi apa pun hanya di bawah pengawasan dukungan teknis vendor. Ini bukan Debian biasa Anda, di sini setiap gerakan ceroboh dapat menonaktifkan OS, mekanisme perlindungan yang akan menganggap "inisiatif" Anda sebagai ancaman potensial. Sehubungan dengan BIOS terkunci secara default, ini mengutuk Anda untuk perbaikan non-garansi (baca "mahal").
(Un) split tunneling
Fakta lain yang tidak semua orang tahu: secara default, klien ViPNet bekerja dalam mode terowongan terbagi (saat Anda dapat menentukan lalu lintas mana yang akan digabungkan ke dalam terowongan dan mana yang tidak). ViPNet memiliki teknologi "Open Internet" (kemudian diubah namanya menjadi "Protected Internet Gateway"). Banyak orang secara keliru mengaitkan fungsi ini dengan koordinator daripada klien. Pada klien yang terdaftar dengan koordinator dengan fungsi ini, dua set filter prasetel dibuat. Yang pertama mengizinkan interaksi hanya dengan koordinator itu sendiri dan terowongannya, yang kedua - dengan objek lain, tetapi menolak akses ke koordinator OI dan terowongannya. Selain itu, menurut konsep vendor, dalam kasus pertama, koordinator harus melakukan tunnel ke server proxy atau menjadi server proxy itu sendiri. Lalu lintas layanan, serta penerimaan dan pengiriman amplop (keduanya layanan,dan aplikasi) berfungsi dalam konfigurasi apa pun.
TCP-
Suatu kali saya menemukan aplikasi yang tidak ingin bekerja dengan cara apa pun melalui koordinator. Beginilah cara saya mengetahui bahwa koordinator memiliki port layanan yang melaluinya lalu lintas tidak terenkripsi diblokir tanpa kemungkinan konfigurasi apa pun. Ini termasuk UDP / 2046,2048,2050 (layanan dasar ViPNet), TCP / 2047,5100,10092 (untuk ViPNet Statewatcher) dan TCP / 5000-5003 (MFTP). Di sini saya menyimpulkan fungsi terowongan TCP. Bukan rahasia lagi bahwa ISP suka menyaring port UDP yang tinggi, jadi administrator, dalam upaya meningkatkan ketersediaan CN mereka, mengaktifkan fitur terowongan TCP. Dalam kasus ini, sumber daya di DMZ (melalui port terowongan TCP) menjadi tidak tersedia. Hal ini disebabkan oleh fakta bahwa port terowongan TCP juga menjadi satu layanan, dan tidak ada lagi aturan firewall dan aturan NAT (Network Address Translation) di dalamnya. Sulit untuk mendiagnosis fakta itubahwa lalu lintas ini tidak dicatat dalam log paket IP seolah-olah tidak ada sama sekali.
Mengganti koordinator
Cepat atau lambat, muncul pertanyaan untuk mengganti koordinator dengan pilihan yang lebih produktif atau sementara. Misalnya mengganti HW1000 dengan HW2000 atau software koordinator dengan PAK dan sebaliknya. Kesulitannya terletak pada kenyataan bahwa setiap kinerja memiliki "peran" sendiri-sendiri di NCC (Network Control Center). Bagaimana cara mengubah peran dengan benar tanpa kehilangan kohesi? Pertama, di NCC kami mengubah peran ke yang baru, membentuk direktori, tetapi jangan mengirim (!) Mereka. Kemudian kami merilis file DST baru di UKC dan menginisialisasi Koordinator baru. Kemudian kami melakukan penggantian dan, setelah memastikan bahwa semua interaksi berfungsi, kami mengirimkan buku referensi.
Clustering dan node crash
Cadangan panas harus dimiliki untuk setiap situs besar, jadi sekumpulan model lama (HW1000, HW2000, HW5000) selalu dibeli dari mereka. Namun, pembuatan cluster dari gateway crypto yang lebih kompak (HW50 dan HW100) tidak mungkin dilakukan karena kebijakan lisensi vendor. Akibatnya, pemilik situs kecil harus membayar lebih dan membeli HW1000 (baik, atau tidak ada toleransi kesalahan). Tahun ini, vendor akhirnya membuat lisensi tambahan untuk model koordinator junior. Jadi dengan dirilisnya versi 4.2.x, menjadi mungkin untuk mengumpulkannya ke dalam sebuah cluster.
Saat menyiapkan cluster untuk pertama kalinya, Anda dapat menghemat banyak waktu dengan tidak mengonfigurasi antarmuka dalam mode wizard atau menggunakan perintah CLI. Anda dapat langsung memasukkan alamat yang diperlukan ke dalam file konfigurasi cluster (failover config edit), hanya saja jangan lupa untuk menentukan topengnya. Ketika daemon failover dimulai dalam mode cluster, itu akan menetapkan alamat ke antarmuka yang sesuai dengan sendirinya. Pada saat yang sama, banyak yang takut untuk menghentikan daemon, dengan asumsi bahwa alamat diubah ke alamat pasif atau mode tunggal. Jangan khawatir: antarmuka akan menyimpan alamat yang ada pada saat daemon dihentikan.
Dalam versi cluster, ada dua masalah umum: reboot siklik dari node pasif dan kegagalannya untuk beralih ke mode aktif. Untuk memahami esensi dari fenomena ini, mari kita pahami mekanisme operasi cluster. Jadi, node aktif menghitung paket pada antarmuka dan, jika tidak ada paket dalam waktu yang ditentukan, mengirimkan ping ke testip. Jika ping berhasil, maka penghitung akan dimulai ulang, jika tidak lulus, maka kegagalan antarmuka terdaftar dan node aktif masuk ke reboot. Pada saat yang sama, node pasif mengirimkan permintaan ARP reguler pada semua antarmuka yang dijelaskan di failover.ini (file konfigurasi cluster, yang berisi alamat yang diterima node aktif dan pasif). Jika rekaman ARP dari setidaknya satu alamat menghilang, maka node pasif akan beralih ke mode aktif.
Mari kembali ke masalah cluster. Saya akan mulai dengan yang sederhana - tidak beralih ke mode aktif. Jika tidak ada node yang aktif, tetapi mac-address-nya masih ada pada node pasif di tabel ARP (inet show mac-address-table), Anda harus pergi ke administrator switch (entah cache ARP dikonfigurasi dengan cara ini, atau ini adalah semacam kegagalan ). Pemuatan ulang siklik dari node pasif sedikit lebih rumit. Hal ini terjadi karena passive tidak melihat record ARP aktif, masuk ke mode aktif dan (perhatian!) Polling tetangga melalui link HB. Tetapi tetangga kita dalam mode aktif dan memiliki lebih banyak waktu aktif. Pada saat ini, node pasif menyadari bahwa ada sesuatu yang salah, karena konflik negara telah muncul, dan melakukan boot ulang. Ini berlanjut tanpa batas. Jika masalah ini terjadi, Anda perlu memeriksa pengaturan alamat IP di failover.ini dan pengalihan.Jika semua pengaturan pada koordinator sudah benar, maka inilah saatnya menghubungkan teknisi jaringan ke pertanyaan.
Alamat penyeberangan
Dalam praktik kami, kami sering menjumpai persimpangan alamat terowongan di belakang koordinator yang berbeda.
Untuk kasus seperti itu, ada virtualisasi alamat di produk ViPNet. Virtualisasi adalah sejenis NAT tanpa memantau status koneksi satu-ke-satu atau rentang ke jangkauan. Secara default, fungsi ini dinonaktifkan pada koordinator, meskipun Anda dapat menemukan alamat virtual potensial di iplir.conf di baris "tunnel" setelah "to" di bagian koordinator tetangga. Untuk mengaktifkan virtualisasi secara global untuk seluruh daftar, di bagian [visibilitas], ubah parameter "tunneldefault" menjadi "virtual". Jika Anda ingin mengaktifkannya untuk tetangga tertentu, maka Anda perlu menambahkan parameter "tunnelvisibility = virtual" ke bagian [id] -nya. Juga perlu dipastikan bahwa parameter tunnel_local_networks disetel ke "on". Untuk mengedit alamat virtual, parameter tunnel_virt_assignment harus disetel ke mode "manual".Di sisi berlawanan, Anda perlu melakukan tindakan serupa. Parameter "usetunnel" dan "exclude_from_tunnels" juga bertanggung jawab atas setelan tunnel. Hasil dari pekerjaan yang dilakukan dapat diperiksa menggunakan utilitas "iplirdiag", yang saya sebutkan di atas.
Tentu saja, alamat virtual membawa beberapa ketidaknyamanan, sehingga administrator infrastruktur lebih memilih untuk meminimalkan penggunaannya. Misalnya, ketika organisasi terhubung ke sistem informasi (IS) dari beberapa lembaga pemerintah, organisasi ini akan mengeluarkan file DST dengan jangkauan terowongan tetap dari rencana alamat IS. Seperti yang bisa kita lihat, keinginan orang yang menghubungkan tidak diperhitungkan. Bagaimana menyesuaikan diri dengan kolam ini, semua orang memutuskan sendiri. Seseorang memigrasi workstation ke alamat baru, dan seseorang menggunakan SNAT dalam perjalanan dari host ke koordinator. Bukan rahasia lagi bahwa beberapa administrator menggunakan SNAT untuk melewati batasan lisensi platform yang lebih rendah. Kami tidak berupaya menilai etika "life hack" seperti itu, tetapi jangan lupa bahwa kinerja platform itu sendiri masih memiliki batasan,dan ketika kelebihan beban, kualitas saluran komunikasi akan mulai menurun.
Ketidakmampuan untuk bekerja GRE
Tentu saja, setiap solusi TI memiliki batasannya sendiri pada kasus penggunaan yang didukung, dan Koordinator ViPNet tidak terkecuali. Masalah yang agak mengganggu adalah ketidakmampuan untuk bekerja GRE (dan protokol yang menggunakannya) dari berbagai sumber ke satu tujuan melalui SNAT. Ambil, misalnya, sistem bank-klien yang menyiapkan terowongan PPTP ke alamat publik bank. Masalahnya adalah protokol GRE tidak menggunakan port, jadi setelah lalu lintas melewati NAT, soket lalu lintas tersebut menjadi sama (kami memiliki alamat tujuan yang sama, protokol yang sama, dan kami hanya menerjemahkan alamat sumber ke alamat yang sama). Koordinator bereaksi terhadap ini dengan memblokir lalu lintas di latar belakang kesalahan 104 - Koneksi sudah ada. Ini terlihat seperti ini:
Oleh karena itu, jika Anda menggunakan beberapa koneksi GRE, Anda harus menghindari penerapan NAT ke koneksi tersebut. Sebagai upaya terakhir, lakukan penyiaran 1: 1 (meskipun, saat menggunakan alamat publik, ini adalah solusi yang agak tidak praktis).
Jangan lupakan waktu
Kami melanjutkan topik pemblokiran dengan acara nomor 4 - batas waktu paket IP. Semuanya dangkal di sini: peristiwa ini terjadi ketika ada perbedaan antara waktu absolut (tidak termasuk zona waktu) antara node jaringan ViPNet (koordinator dan klien ViPNet). Pada koordinator HW, perbedaan maksimum adalah 7200 detik dan disetel dalam parameter "timediff" dari file konfigurasi IPlir. Saya tidak mempertimbangkan koordinator HW-KB dalam artikel ini, tetapi perlu dicatat bahwa dalam versi KB2 timediff adalah 7 detik secara default, dan di KB4 adalah 50 detik, dan acara di sana mungkin tidak dihasilkan 4, tetapi 112, yang mungkin membingungkan seorang insinyur yang terbiasa dengan HW "normal".
Lalu lintas tidak terenkripsi, bukan terenkripsi
Mungkin sulit bagi pemula untuk memahami sifat dari peristiwa 22 - Paket IP non-enkripsi dari simpul jaringan - di log paket IP. Ini berarti bahwa koordinator mengharapkan lalu lintas terenkripsi dari alamat IP ini, tetapi lalu lintas yang tidak terenkripsi datang. Paling sering terjadi seperti ini:
- ViPNet-, , . IPlir , , , . , : ViPNet-, – . , , , . , , , ViPNet-, . , ViPNet-, ;
- . , , ( ). , , , ;
- . , . , «» . , , , 22 .
(ALG)
Banyak firewall, termasuk Koordinator ViPNet, mungkin bermasalah dengan SIP yang melewati NAT. Mengingat bahwa alamat virtual adalah NAT internal, masalah dapat terjadi meskipun NAT secara eksplisit tidak digunakan, tetapi hanya alamat virtual yang digunakan. Koordinator memiliki modul pemrosesan protokol aplikasi (ALG) yang akan menyelesaikan masalah ini, tetapi ini tidak selalu berfungsi seperti yang diinginkan. Saya tidak akan membahas mekanisme ALG (artikel terpisah dapat ditulis tentang topik ini), prinsipnya sama untuk semua ITU, hanya judul perubahan tingkat aplikasi. Untuk pengoperasian yang benar dari protokol SIP melalui koordinator, Anda perlu mengetahui hal-hal berikut:
- ALG harus diaktifkan saat menggunakan NAT;
- saat menggunakan pengalamatan virtual, ALG harus diaktifkan pada kedua node yang berpartisipasi dalam interaksi (koordinator-koordinator, koordinator-klien), bahkan jika visibilitas virtual diatur hanya pada satu sisi;
- saat menggunakan visibilitas nyata dan tidak ada NAT, Anda harus mematikan ALG agar tidak mengganggu SIP;
- ALG baris 3.x dan 4.x tidak kompatibel (secara tegas, baris 3.x tidak ada cara untuk mengontrolnya sama sekali). Dalam skenario seperti itu, vendor tidak dapat menjamin pengoperasian SIP yang benar.
Modul ini dikendalikan oleh perintah dari grup "modul alg" dari mode hak istimewa (aktifkan).
Akhirnya
Saya mencoba mempertimbangkan masalah yang paling mendesak, mengidentifikasi akarnya dan berbicara tentang solusinya. Tentu saja, ini jauh dari semua fitur ViPNet, jadi saya sarankan untuk tidak malu - hubungi dukungan dan minta saran di komunitas (di forum vendor, di saluran telegram, di komentar di bawah posting ini). Dan jika Anda tidak ingin menyelami semua kesulitan bekerja dengan ViPNet atau terlalu melelahkan, maka Anda selalu dapat menyerahkan pengelolaan jaringan ViPNet di tangan para profesional.
Penulis: Igor Vinokhodov, insinyur dari lini ke-2 administrasi, Rostelecom-Solar