Apa yang perlu direkod untuk VPN tapak-ke-tapak: pemilih dan skop

Enam bulan selepas terowong dipasang, subnet baharu berhenti sepadan dengan dasar dan satu-satunya dokumen di kongsi hanya menyebut VPN pejabat. Itulah kegagalan yang dicegah oleh rekod pemilih, dan ia khusus: set alamat berubah tetapi dokumen tidak. Menulis rekod dengan betul bermakna mengetahui set alamat mana antara beberapa set yang anda huraikan, dan merekodkan yang benar-benar dikuatkuasakan oleh rakan, bukan yang anda konfigurasikan.

Dikonfigurasikan bukan dirundingkan

Dalam terowong IPsec berasaskan dasar, setiap pihak mencadangkan pemilih trafik: julat sumber dan destinasi untuk persatuan anak. Pihak yang menjawab dibenarkan menyempitkan cadangan itu, jadi persatuan yang dipasang mungkin meliputi kurang daripada yang disenaraikan dalam konfigurasi. Rekod yang menyalin konfigurasi menggambarkan niat, bukan skop perlindungan semasa. Kedua-duanya menyimpang secara senyap, dan tiada apa pun di halaman status terowong yang menunjukkannya.

Simpan kedua-dua lajur, dengan tarikh anda memerhatikannya. Pemilih yang dikonfigurasikan ialah apa yang anda maksudkan; yang dirundingkan ialah apa yang kernel kuatkuasakan sekarang. Apabila kedua-duanya berbeza, perbezaan itu menjelaskan kegagalan mengejut jauh lebih kerap daripada pepijat penghalaan.

Satu persatuan juga tidak mewakili setiap pasangan yang dikonfigurasikan. Terowong dengan beberapa kombinasi pemilih boleh berakhir dengan beberapa persatuan anak, dan rekod yang menyenaraikan salah satunya ialah inventori separa. Senaraikan semuanya dan bukannya meringkaskannya.

Terowong berasaskan laluan memilih secara berbeza

Dengan antara muka berasaskan laluan, jadual penghalaan menentukan apa yang masuk ke terowong dan pemilih boleh sengaja luas. Itu reka bentuk yang sah dan bukan kecuaian, dan rekod mesti menggambarkannya sedemikian. Tuliskan laluan, antara muka yang ditujunya, dan dasar tembok api yang mengehadkan perkhidmatan yang boleh dicapai. Skop perlindungan luas dengan sengaja, dan skop perkhidmatan yang menyempitkannya.

Menyalin templat berasaskan dasar ke terowong berasaskan laluan menghasilkan dokumen yang menggambarkan mekanisme yang tidak digunakan oleh penggunaan. Jurutera seterusnya kemudian mencari pemilih yang tidak sepatutnya ada, dan menyimpulkan terowong itu salah dikonfigurasikan sedangkan ia hanya didokumenkan dengan buruk.

Terjemahan tergolong dalam jadual yang sama

Apabila NAT membentangkan julat berbeza kepada rakan, rekodkan prefiks asal dan terjemahan bersama-sama. Catat peringkat di mana pemilih dan peraturan akses sepadan dengannya, kerana susunan menentukan sama ada pihak jauh akan pernah melihat alamat yang anda tulis. Jadual dengan hanya satu daripada dua julat lebih buruk daripada tiada jadual, kerana ia kelihatan lengkap.

Inilah perincian yang mematahkan terowong yang berfungsi selepas perubahan NAT: pemilih masih sepadan dengan prefiks asal, rakan kini menerima yang terjemahan, dan laluan pulangnya menunjuk ke alamat yang tidak lagi wujud. Tiada apa pun merekodkan ralat pada saat kedua-duanya berhenti sepadan.

DNS persendirian tergolong di tempat yang sama. Nama yang menyelesaikan kepada alamat yang tidak boleh digunakan dari tapak berkenaan ialah ralat dokumentasi dengan tiket sokongan dilampirkan, dan ia akan disalahkan pada terowong.

Lampirkan keperluan perkhidmatan

Julat yang dilindungi bukan senarai kebenaran. Tuliskan perkhidmatan mana yang sepatutnya boleh dicapai dari sumber mana, dan siapa yang memiliki aplikasi di belakangnya. Kedua-dua medan itu menjawab soalan berbeza, dan mencampurkannya ialah cara semakan keselamatan akhirnya berhujah tentang penghalaan dan bukannya akses.

Kemudian namakan pentadbir rangkaian yang menyelenggara peraturan itu. Inventori pemilih tanpa pemilik menjadi lapuk secara senyap, dan lapuk tidak dapat dibezakan daripada salah apabila terowong rosak pada pukul dua pagi. Pemilik juga orang yang boleh mengesahkan perubahan itu disengajakan.

Jadikan rekod itu pelan ujian

Untuk setiap laluan yang diperlukan, pilih hos sumber dan destinasi yang mewakili dan catat laluan, perkhidmatan dan get laluan balasan yang dijangka. Itu menjadikan dokumen itu pelan ujian dan bukannya penerangan. Baca persatuan langsung dengan arahan di bawah, dan bandingkannya dengan baris rundingan yang anda tulis.

swanctl --list-sas

Rangka lima baris biasanya cukup untuk memastikan rekod itu jujur. Versi di bawah muat dalam tiket perubahan tanpa dipotong:

sites: office <-> dc1
configured selector: 10.10.0.0/16 <-> 10.20.0.0/16
negotiated selector: 10.10.4.0/22 <-> 10.20.0.0/16
translated range: 172.16.4.0/22 -> 10.10.4.0/22
service and owner: erp:443 / finance-netops

Ping ke get laluan sahaja bukan ujian penerimaan. Ia tidak pernah melaksanakan laluan transit, jadi ia boleh lulus walaupun setiap aliran yang diteruskan gagal. Uji dari hos di satu pihak ke perkhidmatan di pihak yang lain dan sahkan balasan tiba melalui terowong. Jika hanya ping lulus, rekod itu baru sahaja menemui masalah penghantaran yang sepatutnya dicegahnya. Dokumentasi penghantaran strongSwan menerangkan bagaimana pemilih, laluan dan penghantaran berinteraksi pada rakan Linux.