Mengapa VPN TAP Bersama Masih Memerlukan HTTPS di Portal
VPN TAP mengautentikasi rekan, bukan layanan di belakangnya. Pertahankan validasi nama host di portal dan isolasi tetangga yang tidak Anda percayai.
Dua perangkat memiliki kredensial VPN yang sah dan berbagi satu segmen Ethernet yang dijembatani. Hanya satu di antaranya yang seharusnya menjawab untuk portal kantor, dan yang lain masih dapat mengklaim alamat portal pada segmen itu. Terowongan telah menjalankan tugasnya: ia mengautentikasi kedua rekan dan mengenkripsi setiap jalur ke server. Yang tidak dilakukannya adalah menyatakan siapa di antara mereka yang memiliki nama layanan, dan celah itulah sebabnya portal masih memerlukan sertifikat yang sah.
Apa yang sebenarnya diautentikasi VPN
Jabat tangan VPN menjawab satu pertanyaan: rekan mana yang menyelesaikan terowongan ini, dengan materi kunci apa. Jawaban itu berlaku per rekan dan per koneksi, dan tidak mengatakan apa pun tentang layanan yang kemudian diekspos rekan tersebut. Pada segmen TAP, rekan bahkan bukan satu alamat, karena ia dapat menyajikan MAC apa pun dan IP apa pun yang bersedia dipelajari jembatan. Autentikasi berhenti di ujung terowongan, bukan di aplikasi.
Pisahkan ketiga pertanyaan alih-alih menggabungkannya menjadi satu. Masing-masing punya mekanisme dan mode kegagalannya sendiri.
| Question | Answered by |
|---|---|
| Which peer sent this packet? | VPN transport authentication |
| Which device owns this IPv4 address? | ARP, trusted only as far as the segment |
| Which service am I talking to? | Application TLS and hostname validation |
Sebuah penerapan dapat memiliki terowongan yang terautentikasi sempurna dan layanan yang sama sekali tidak terautentikasi di belakangnya. Ia juga dapat memiliki sertifikat tervalidasi pada host yang alamat lapis keduanya diklaim oleh rekan lain, dan karena itu kedua kontrol harus ada dalam desain, bukan yang satu menggantikan yang lain. Tabel itu adalah seluruh argumen dalam tiga baris.
ARP pada segmen bersama bukan direktori
ARP memetakan alamat IPv4 ke MAC pada tautan lokal dan menerima balasan dari siapa pun di tautan itu. Pada segmen berjembatan yang permisif, seorang rekan dapat mengklaim alamat milik perangkat lain, dan jembatan meneruskan frame ke siapa pun yang menjawab paling akhir. Mengenkripsi setiap jalur klien ke server tidak mengubah itu, karena frame didekripsi sebelum mencapai jembatan. Batas kepercayaan ARP adalah segmen, bukan terowongan.
Lihat apa yang benar-benar dipelajari host: ip neigh show mencantumkan pemetaan saat ini dan statusnya, dan entri yang berganti antara dua alamat MAC selama operasi normal adalah gejala yang layak diselidiki, bukan diabaikan. Pada segmen kecil yang sehat, entri tersebut tetap stabil untuk waktu lama.
Isolasi rekan dan kebijakan jembatan ada tepat untuk kasus ini. Desain yang dirutekan biasanya jawaban yang lebih baik ketika layanan hanya IP dan perangkat tidak punya alasan untuk melihat frame satu sama lain.
Pertahankan validasi sertifikat di tempat layanannya berada
TLS aplikasi menjawab pertanyaan yang tidak bisa dijawab terowongan: apakah ini layanan yang ingin saya capai. Peramban memeriksa nama host terhadap sertifikat, dan pemeriksaan itu satu-satunya bagian rantai yang menyebut portal, bukan rekan.
Periksa apa yang disajikan server sebelum memutuskan bahwa peringatan itu kosmetik. openssl s_client -connect portal.example.internal:443 -servername portal.example.internal mencetak rantai dan nama alternatif subjek. Jika nama yang Anda ketik tidak ada dalam daftar itu, peringatan itu benar dan sertifikatlah yang perlu diperbaiki. Mengajari pengguna untuk melewatinya mengubah kontrol yang berfungsi menjadi hiasan.
Panduan penjembatanan OpenVPN menjelaskan model Ethernet dan opsi kebijakan di sekitarnya, dan itulah rujukan yang tepat untuk apa yang seharusnya diizinkan segmen. Bacalah sebelum melonggarkan aturan jembatan, karena model yang dijelaskannya adalah yang diasumsikan setiap pemeriksaan di atas.
Putuskan apakah rekan-rekan itu seharusnya berbagi segmen sama sekali
Perbaikan termurah biasanya berhenti berbagi lapis kedua ketika persyaratannya hanya keterjangkauan IP. VPN yang dirutekan memberi setiap klien alamatnya sendiri, menghapus domain siaran bersama, dan mengubah lalu lintas antar rekan menjadi keputusan kebijakan alih-alih bawaan. Portal kemudian memiliki satu alamat untuk dilindungi dan tidak ada tetangga yang dapat mengklaimnya.
Jika segmen harus tetap ada, periksa pengaturan sisi server yang memungkinkan klien saling menjangkau: grep -n client-to-client /etc/openvpn/server.conf. Saat dinonaktifkan, lalu lintas klien melewati server dan dapat difilter di sana. Saat diaktifkan, rekan bertukar frame langsung melalui jembatan, dan titik penyaringan Anda adalah jembatan dan firewall host.
Catat perlindungan mana yang benar-benar diandalkan setiap host: autentikasi terowongan, isolasi segmen, atau TLS aplikasi. Host yang bergantung pada ketiganya baik-baik saja. Host yang bergantung pada yang pertama dan menganggap dua lainnya ikut serta adalah host yang akhirnya menyajikan konten yang salah.