Mengarahkan klien OpenVPN lewat Cloudflare? Periksa dulu perannya
Klien perangkat bukanlah router. Pastikan peran Cloudflare meneruskan paket host lain, lalu biarkan tunnel milik server sendiri di jalur lamanya.
Anda memiliki server OpenVPN yang berjalan dan host yang juga menjalankan perangkat lunak perangkat Cloudflare, dan langkah berikutnya yang tampak jelas adalah mengarahkan lalu lintas klien ke sana. Dua koneksi yang berjalan di satu mesin tidak berarti satu gateway transit. Yang kurang adalah peran yang terdokumentasi untuk meneruskan paket milik pihak lain, dan kebijakan yang mengklasifikasikan paket itu saat tiba.
Sebelum aturan apa pun ada empat pertanyaan: lalu lintas apa yang masuk, ke mana perginya berikutnya, bagaimana jawabannya menemukan jalan kembali, dan apa yang dilakukan desain saat jalur kedua itu gagal. Dua yang pertama adalah pertanyaan kemampuan.
Dua layanan di satu host bukan jalur transit
Klien perangkat dibangun untuk menangani lalu lintas yang berasal dari mesin tempat ia berjalan. Ia mencegat resolusi nama, atau lalu lintas aplikasi tertentu, dan mengirimkannya melalui tunnel-nya sendiri, dan kebijakannya ditulis untuk pengguna perangkat itu dan proses perangkat itu. Paket yang diteruskan dari klien OpenVPN bukan keluaran lokal, jadi aturan yang sama tidak mengklasifikasikannya. Itu bukan detail konfigurasi yang bisa ditutupi dengan aturan yang lebih luas, karena itu menentukan apakah perangkat lunak melihat paket itu sama sekali.
Itulah sebabnya pertanyaan desain adalah pertanyaan kemampuan. Entah produk yang terpasang punya peran terdokumentasi yang meneruskan lalu lintas untuk jaringan lain, atau fungsi transit itu sepenuhnya milik tempat lain.
Peran Cloudflare mana yang boleh meneruskan
Klien perangkat Cloudflare menawarkan mode yang berbeda cakupannya: hanya resolusi nama, lalu lintas dari perangkat, dan kadang keduanya. Tidak satu pun dari mode itu menjadikan host sebagai router untuk rentang privat yang datang melalui tunnel lain. Peran perutean khusus adalah produk terpisah dengan konektor, pendaftaran, dan model jaringannya sendiri.
| Question | What has to answer it |
|---|---|
| Does the installed product forward packets from other hosts? | A documented routing or connector role, not a device mode |
| Which prefixes does the connector advertise? | Its own configuration and status output |
| Does the server's own transport still take the old path? | ip route get for the endpoint, before and after |
| Do replies return through the same path? | Connection tracking counters on the forward rule |
Periksa peran yang terpasang sebelum merancang rute di sekitarnya. Baca antarmuka mana yang dibuat konektor, apakah ia mengumumkan prefiks tertentu atau rute default, dan apakah kebijakan lokal berlaku untuk paket yang diteruskan maupun paket lokal. Jika hanya lalu lintas lokal yang ditangani, server OpenVPN tidak bisa menjadi titik transit, tidak peduli bagaimana aturan terjemahan ditulis.
Di sinilah persyaratan keluar publik juga harus dinyatakan dengan tepat. Keluaran yang disediakan Cloudflare untuk lalu lintas klien yang diteruskan adalah kasus penggunaan khusus, dan itu harus dikonfirmasi terhadap layanan yang benar-benar Anda miliki.
Jaga tunnel luar tetap independen dari rute baru
Begitu Anda menambahkan rute default menuju antarmuka baru, lalu lintas keluar milik server mulai bersaing untuk itu, dan itu mencakup balasan ke klien OpenVPN dan sesi SSH Anda ke mesin tersebut. Gejala biasanya adalah tunnel yang terbentuk lalu mati, atau administrator yang terkunci di luar sementara perubahan tampak berhasil. Bandingkan ip route get untuk titik akhir sebelum dan sesudah, dan gunakan perutean berbasis kebijakan atau rute host untuk menjaga transportasi server sendiri di tempatnya. Jalankan perbandingan itu dari mesin itu sendiri, karena pandangan server tentang rutenya sendirilah yang penting.
Pengecualian untuk alamat publik server tidak cukup dengan sendirinya, karena jalur balik setiap administrator jarak jauh adalah aliran yang berbeda. Tentukan aliran mana yang harus bertahan melewati perubahan, lalu verifikasi masing-masing alih-alih menganggap yang pertama mencakup sisanya.
Batasi penerusan dan terjemahan pada satu aliran
Paket yang diterima mengikuti jalur penerusan, bukan jalur keluaran lokal, jadi aturan yang penting hidup di hook forward. Di mana antarmuka berikutnya perlu terjemahan, batasi sumbernya ke kumpulan klien, tujuannya ke yang diizinkan, dan keluarnya ke satu antarmuka itu. Aturan masquerade yang hanya dikaitkan dengan antarmuka tidak memilih rute sendiri dan tidak mengizinkan penerusan melewati filter lain.
Tentukan perilaku menutup saat gagal terlebih dahulu, lalu uji. Hentikan jalur berikutnya dan pastikan klien kehilangan keluaran yang dimaksud alih-alih diam-diam kembali ke uplink biasa, karena itulah hasil yang tidak disadari siapa pun sampai lalu lintas keluar lewat pintu yang salah. Ulangi pemeriksaan untuk resolusi nama dan untuk IPv6, karena kumpulan aturan hanya untuk v4 membiarkan jalur v6 terbuka.
Tuliskan empat jawaban yang Anda tetapkan dan pengamatan yang membuktikan masing-masing. Jalur transit yang dapat Anda jelaskan adalah jalur yang dapat Anda pertahankan pada tinjauan insiden berikutnya.