Berhijrah daripada VPN berasaskan PPP tanpa menyalin andaiannya

Migrasi VPN selesai apabila pengguna, destinasi, resolusi nama dan tingkah laku semasa kegagalan semuanya masih betul, bukan apabila klien baharu memaparkan ikon hijau. Pemasangan lama berasaskan PPP membawa andaian yang tidak pernah ditulis: rahsia dikongsi yang juga menjadi satu-satunya semakan identiti, kolam alamat tetap yang disenaraikan oleh firewall sebagai dibenarkan, dan akhiran DNS yang ditolak oleh pelayan. Menggantikan protokol tanpa menginventori andaian itu menghasilkan terowong yang melengkapkan handshake dan sempadan yang tidak wujud. Urutan di bawah ialah urutan yang saya gunakan, dan langkah terakhir itulah yang dilangkau oleh pasukan.

Langkah 1: inventori apa yang disediakan oleh sambungan lama

Inventori ditulis, bukan diingat. Catat klien yang disokong, peranan pengesahan, kolam alamat, rangkaian terlindung, keperluan DNS dan kebenaran perkhidmatan yang diperlukan oleh setiap kumpulan pengguna.

Untuk L2TP/IPsec, pisahkan kedua-dua lapisan secara jelas. Identiti rakan IPsec mengesahkan mesin; PPP mengesahkan pengguna, biasanya dengan CHAP atau MSCHAPv2.

Di situlah pemasangan lama menyembunyikan andaiannya. Kunci pra-kongsi yang dikongsi setiap klien mengesahkan kumpulan dan bukan peranti, dan selalunya itulah satu-satunya perkara yang pernah diputar. Jika akaun PPP ialah kawalan sebenar setiap pengguna, katakan begitu, kerana pengganti mesti menghasilkan semula kawalan itu dengan sesuatu yang bukan rentetan dikongsi. Catat juga alamat sumber tetap dan pengecualian rangkaian tempatan, kerana itulah kebergantungan yang tiada siapa mendokumenkan sehingga ia rosak.

Langkah 2: reka pengganti dengan sengaja

Memilih pengganti ialah pemetaan keperluan demi keperluan: protokol dan klien yang diselenggara yang disokong organisasi, dengan setiap keperluan identiti dan akses mendarat dalam mekanisme sebenar. Rahsia dikongsi tidak automatik setara dengan kunci atau sijil setiap peranti, dan akaun PPP setiap pengguna tidak setara dengan sijil peranti.

Selaraskan julat alamat sebelum apa-apa lagi, kerana kolam pengganti yang bertindih dengan LAN rumah atau pejabat mencipta kegagalan yang tiada kaitan dengan kekuatan sifer. Semak kolam itu terhadap senarai yang sama yang anda bina untuk perkhidmatan lama, serta apa yang klien baharu andaikan secara lalai. Sahkan penghalaan balik untuk rangkaian terlindung dan sahkan bahawa klien baharu boleh menolak atau mendokumenkan akhiran DNS yang ditolak oleh klien lama. Dua perkara itu menyebabkan lebih banyak tiket migrasi daripada perubahan protokol itu sendiri.

Langkah 3: laksanakan secara berperingkat dan sahkan kedua-dua kebenaran dan penolakan

Laksanakan dengan seorang pengguna wakil dan satu aplikasi wakil. Sertakan resolusi DNS peribadi dalam ujian, kerana terowong yang mencapai alamat tetapi tidak dapat menyelesaikan nama dalaman hanya separuh berhijrah. Sertakan juga keadaan tidak tersedia yang dijangka: apa yang patut berlaku apabila terowong terputus, dan sama ada klien menguatkuasakannya.

Kemudian uji destinasi yang sepatutnya kekal ditolak. Peraturan kebenaran sementara yang luas boleh membuat terowong baharu kelihatan sihat sambil membuang sempadan kebenaran yang dikuatkuasakan perkhidmatan lama secara senyap, dan tiada siapa menyedarinya sehingga audit. Bandingkan hasil kebenaran dan penolakan secara bersebelahan, dari klien yang sama, dalam sesi yang sama. Kekalkan perkhidmatan lama berjalan sehingga kedua-dua lajur sepadan dengan reka bentuk.

Sebelum memindahkan akses pentadbir, sahkan anda mempunyai laluan pemulihan yang dibenarkan dan tidak bergantung pada terowong yang sedang anda ubah.

Langkah 4: persarakan identiti lama

Mempersarakan identiti lama dengan betul bermakna membatalkan pengguna dan kelayakan peranti yang usang melalui perkhidmatan yang memilikinya, kemudian membuang profil dan pendengar lama apabila tiada kebergantungan tinggal. Memadam fail tempatan tidak membatalkan salinan di tempat lain, dan pendengar lama yang masih menerima rahsia dikongsi lama ialah pintu tanpa pengawasan.

Titik itu wajar diperlahankan. Profil klien yang dinyahaktifkan pada komputer riba bukan kelayakan yang dibatalkan; kelayakan itu hidup pada pelayan dan kekal sah sehingga pelayan berhenti menerimanya. Cari salinan lain konfigurasi lama — peranti ujian, telefon yang terlupa, pemasang yang disimpan seseorang — dan anggap pemberhentian pendengar sebagai saat perkhidmatan lama benar-benar berakhir. Sehingga itu, migrasi mempunyai dua pintu depan.

Rekod penerimaan ialah inventori dari langkah satu dengan satu lajur ditambah: apa yang dilakukan reka bentuk baharu untuk setiap baris, dan bagaimana anda mengesahkannya. Itu menjadikan peningkatan protokol sebagai keperluan perkhidmatan dengan bukti.

Kekalkan hasil terikat pada apa yang diperlukan perkhidmatan dan bukan pada nama protokol, kerana protokol moden dengan andaian lama yang disalin ke dalamnya ialah risiko yang sama dengan pembingkaian lebih baik. RFC 3193 menerangkan bagaimana L2TP dibawa melalui IPsec, yang merupakan peringatan berguna bahawa kedua-dua lapisan sentiasa keputusan berasingan. Jika inventori mempunyai baris yang tidak dapat anda jelaskan, berhenti dan cari tahu apa yang bergantung padanya. Migrasi selesai apabila senarai itu membosankan.