Mengapa VPN TAP Dikongsi Masih Memerlukan HTTPS di Portal

Dua peranti mempunyai kelayakan VPN yang sah dan berkongsi satu segmen Ethernet yang dijambatani. Hanya satu daripadanya sepatutnya menjawab bagi portal pejabat, dan yang lain masih boleh menuntut alamat portal pada segmen itu. Terowong itu telah menjalankan tugasnya: ia mengesahkan kedua-dua rakan dan menyulitkan setiap laluan ke pelayan. Apa yang tidak dilakukannya ialah memperakui siapa antara mereka yang memiliki nama perkhidmatan, dan jurang itulah sebabnya portal masih memerlukan sijil yang sah.

Apa yang sebenarnya disahkan oleh VPN

Jabat tangan VPN menjawab satu soalan: rakan mana yang menyelesaikan terowong ini, dan dengan bahan kunci apa. Jawapan itu adalah bagi setiap rakan dan setiap sambungan, dan ia tidak menyatakan apa-apa tentang perkhidmatan yang didedahkan oleh rakan itu selepasnya. Pada segmen TAP, rakan itu bukan pun satu alamat, kerana ia boleh membentangkan mana-mana MAC dan mana-mana IP yang sanggup dipelajari oleh jambatan. Pengesahan berhenti di hujung terowong, bukan di aplikasi.

Asingkan ketiga-tiga soalan daripada menggabungkannya menjadi satu. Setiap satu mempunyai mekanisme dan cara kegagalannya sendiri.

Satu penggunaan boleh mempunyai terowong yang disahkan sepenuhnya dan perkhidmatan yang tidak disahkan sama sekali di belakangnya. Ia juga boleh mempunyai sijil yang disahkan pada hos yang alamat lapisan keduanya dituntut oleh rakan lain, dan kerana itu kedua-dua kawalan perlu ada dalam reka bentuk, bukan yang satu menggantikan yang lain. Jadual itu ialah keseluruhan hujah dalam tiga baris.

ARP pada segmen dikongsi bukan direktori

ARP memetakan alamat IPv4 kepada MAC pada pautan setempat dan menerima balasan daripada sesiapa sahaja pada pautan itu. Pada segmen berjambatan yang permisif, rakan boleh menuntut alamat milik peranti lain, dan jambatan menghantar bingkai kepada sesiapa yang menjawab paling akhir. Menyulitkan setiap laluan klien ke pelayan tidak mengubahnya, kerana bingkai dinyahsulit sebelum sampai ke jambatan. Sempadan kepercayaan ARP ialah segmen, bukan terowong.

Lihat apa yang sebenarnya dipelajari oleh hos: ip neigh show menyenaraikan pemetaan semasa dan keadaannya, dan entri yang bertukar antara dua alamat MAC semasa operasi biasa ialah gejala yang wajar disiasat dan bukan diabaikan. Pada segmen kecil yang sihat, entri sedemikian kekal stabil untuk masa yang lama.

Pengasingan rakan dan dasar jambatan wujud tepat untuk kes ini. Reka bentuk berhalakan biasanya jawapan yang lebih baik apabila perkhidmatan hanya IP dan peranti tidak mempunyai sebab untuk melihat bingkai satu sama lain.

Kekalkan pengesahan sijil di tempat perkhidmatan itu berada

TLS aplikasi menjawab soalan yang tidak dapat dijawab oleh terowong: adakah ini perkhidmatan yang ingin saya capai. Pelayar menyemak nama hos terhadap sijil, dan semakan itulah satu-satunya bahagian rantaian yang menamakan portal dan bukan rakan.

Periksa apa yang dibentangkan oleh pelayan sebelum memutuskan bahawa amaran itu hanya kosmetik. openssl s_client -connect portal.example.internal:443 -servername portal.example.internal mencetak rantaian dan nama alternatif subjek. Jika nama yang anda taip tiada dalam senarai itu, amaran itu betul dan sijillah yang perlu dibaiki. Mengajar pengguna untuk memintasnya mengubah kawalan yang berfungsi menjadi hiasan.

Panduan penjambatan OpenVPN menerangkan model Ethernet dan pilihan dasar di sekelilingnya, dan itulah rujukan yang betul untuk apa yang sepatutnya dibenarkan oleh segmen. Bacalah sebelum melonggarkan peraturan jambatan, kerana model yang diterangkannya ialah apa yang diandaikan oleh setiap semakan di atas.

Putuskan sama ada rakan-rakan itu patut berkongsi segmen sama sekali

Pembaikan termurah biasanya berhenti berkongsi lapisan kedua apabila keperluan hanyalah kebolehcapaian IP. VPN berhalakan memberikan setiap klien alamatnya sendiri, membuang domain siaran yang dikongsi dan menjadikan trafik antara rakan sebagai keputusan dasar dan bukan lalai. Portal kemudian mempunyai satu alamat untuk dilindungi dan tiada jiran yang boleh menuntutnya.

Jika segmen itu perlu kekal, periksa tetapan sebelah pelayan yang membolehkan klien saling mencapai: grep -n client-to-client /etc/openvpn/server.conf. Apabila dilumpuhkan, trafik klien melalui pelayan dan boleh ditapis di sana. Apabila didayakan, rakan bertukar bingkai terus melalui jambatan, dan titik penapisan anda ialah jambatan dan tembok api hos.

Catat perlindungan mana yang sebenarnya diharapkan oleh setiap hos: pengesahan terowong, pengasingan segmen atau TLS aplikasi. Hos yang bergantung pada ketiga-tiganya adalah baik. Hos yang bergantung pada yang pertama dan menganggap dua yang lain datang bersamanya ialah hos yang akhirnya menyajikan kandungan yang salah.