LAN di sebalik satu sesi AWS Client VPN: apa yang dihantar ke hadapan

Komputer riba menyambung ke titik akhir AWS Client VPN, sampai ke subnet peribadi, dan semuanya kelihatan sihat. Desktop pada LAN yang sama tidak sampai ke mana-mana, walaupun hos Linux juga mempunyai antara muka jambatan dan kedua-dua mesin berada pada kabel yang sama. Tiada apa yang salah dikonfigurasikan dalam terowong; bahagian yang hilang ialah penghalaan, dan jambatan itu petunjuk palsu.

Meluaskan sesi Client VPN ke LAN ialah peranan get laluan. Ia bukan segmen Ethernet yang diregangkan ke dalam perkhidmatan terurus.

Hos berfungsi dan LAN tidak

Antara muka terowong pada mesin Linux mempunyai alamat dalam CIDR klien Client VPN, dan titik akhir telah menolak laluan untuk julat VPC. Permintaan yang dibuat pada mesin itu ialah trafik yang dijana secara setempat: ia memilih laluan, keluar melalui terowong dan mendapat balasan. Laluan itu tidak pernah menyentuh kod penghantaran ke hadapan, antara muka LAN atau mana-mana peraturan tembok api yang mengawal transit.

Trafik daripada peranti LAN lain ialah aliran berbeza. Ia tiba pada antara muka LAN, perlukan laluan yang menunjuk ke terowong, perlukan penghantaran ke hadapan diaktifkan, perlukan tembok api yang membenarkannya, dan perlukan balasan kembali melalui hos yang sama. Empat syarat, dan ujian komputer riba yang berjaya tidak membuktikan satu pun. Dari desktop kegagalan kelihatan pelik: terowong aktif, kelayakan sah, dan destinasi tidak pernah menjawab. Kecacatan itu setempat pada laluan penghantaran ke hadapan get laluan, bukan pada perkhidmatan.

Bukan setiap klien boleh menjadi get laluan

AWS menyatakan bahawa aplikasi desktop Client VPN-nya tidak menyokong penghantaran ke hadapan IP, dan klien lain mungkin menyokongnya. Kekangan itu menentukan seni bina sebelum sebarang arahan ditaip. Jika satu-satunya klien yang tersedia ialah aplikasi desktop rasmi, get laluan Linux yang menghantar ke hadapan untuk LAN bukan konfigurasi yang boleh anda selesaikan, dan tiada jumlah masquerading akan mengubahnya.

Klien pengganti juga mesti sepadan dengan kaedah pengesahan titik akhir dan dasar yang ingin anda kuatkuasakan. Titik akhir berasaskan sijil, direktori dan SAML tidak menerima konfigurasi klien yang sama, dan klien pihak ketiga yang mengesahkan tetapi mengabaikan laluan yang ditolak bukan penambahbaikan.

Anggap pilihan klien sebagai sebahagian daripada semakan reka bentuk. Ia menentukan sama ada corak penghantaran ke hadapan LAN tersedia sama sekali, dan menentukan identiti apa yang dilihat titik akhir bagi setiap peranti di belakang get laluan. Rekodkan klien dan konfigurasi titik akhir yang diuji. Penukaran klien enam bulan kemudian boleh membuang keupayaan yang diandaikan oleh reka bentuk secara senyap.

Halakan LAN ke terowong dan terjemahkannya

Dengan klien yang disokong di tempatnya, selebihnya ialah kerja get laluan biasa. Peranti LAN perlukan laluan untuk julat VPC yang menunjuk ke hos Linux, dan hos perlukan penghantaran ke hadapan diaktifkan. Jika anda mahu VPC melihat trafik sebagai klien bersambung dan bukan sebagai alamat LAN sewenang-wenangnya, terjemahkan sumber semasa keluar.

LAN: 10.24.11.0/24
Linux LAN gateway: 10.24.11.15
VPN interface: tun0
Target VPC range: 10.2.0.0/16

iptables -t nat -A POSTROUTING -s 10.24.11.0/24 -d 10.2.0.0/16 -o tun0 -j MASQUERADE

Hadkan peraturan kepada antara muka terowong dan julat VPC, seperti di atas, bukan melakukan masquerading semua yang dihantar ke hadapan oleh hos. Peraturan yang lebih sempit lebih mudah difikirkan, dan ia tidak mengubah secara senyap trafik yang sepatutnya mengekalkan alamat sumber asalnya.

Biarkan laluan LAN tiba secara automatik jika boleh: pilihan DHCP, pengumuman penghala atau laluan statik yang ditolak oleh apa-apa yang menguruskan LAN. Laluan yang hanya wujud pada satu mesin ujian akan membuat reka bentuk kelihatan rosak pada saat orang lain mencubanya.

Balasan juga perlukan laluan

Sebaik sahaja permintaan sampai ke VPC, balasan mesti kembali melalui keadaan terjemahan yang sama dan menemui laluan LAN pada get laluan. Bahagian itu biasanya berfungsi apabila peraturan masquerade ada, kerana pemetaan tinggal pada hos yang melakukannya. Ia rosak apabila pihak VPC mempunyai laluan yang menghantar balasan ke tempat lain, dan sebab itulah kedua-dua laluan CIDR klien dan perkaitan subnet pada titik akhir penting.

Perhatikan pembilang, bukan hanya ping. Peraturan masquerade dengan sifar paket memberitahu anda permintaan tidak pernah sampai ke antara muka terowong, yang menunjuk kembali ke laluan LAN atau jadual penghalaan klien itu sendiri. Peraturan dengan paket tetapi tanpa balasan menunjuk ke pihak VPC, peraturan kebenaran atau kumpulan keselamatan yang tidak menerima sumber yang diterjemahkan. Baca kedua-dua arah sebelum mengubah apa-apa, kerana kiraan yang hanya bertambah pada satu sisi ialah laluan sehala, bukan laluan perlahan.

Ingat bahawa titik akhir ialah perkhidmatan terurus. Tiada fail konfigurasi pelayan untuk diedit dan tiada arahan client-config untuk ditambah, jadi arahan yang ditulis untuk pelayan OpenVPN yang diurus sendiri dengan laluan subnet klien tersuai tidak berpindah. Di AWS, tuasnya ialah perkaitan subnet, peraturan kebenaran dan jadual penghalaan VPC.

Identiti dikongsi ialah bahagian yang dasar mesti jawab

Setiap peranti di belakang get laluan menggunakan sesi VPN get laluan. Peraturan kebenaran titik akhir memberikan akses kepada pengguna atau kumpulan, dan dari sudut pandangan perkhidmatan terdapat tepat satu pengguna pada sesi itu. Penghantaran ke hadapan setempat tidak menggandakan identiti itu kepada pengesahan setiap peranti, dan ia tidak meluaskan pemeriksaan postur peranti ke pencetak di sudut.

Itu mungkin boleh diterima, atau ia mungkin sebab reka bentuk ditolak. Ia bergantung pada apa yang diandaikan oleh sumber VPC tentang siapa yang memanggil. Identiti dikongsi yang sesuai dengan model kebenaran adalah wajar; yang secara senyap menukar satu sesi yang disahkan menjadi akses seluruh LAN ialah penemuan yang menunggu untuk ditulis.

Jika keperluan itu benar-benar menghubungkan seluruh tapak ke VPC, bandingkan reka bentuk tapak-ke-tapak yang disokong sebelum meluaskan klien akses jauh. Semantiknya berbeza, dan sesi klien dengan NAT ialah pengganti lemah untuk pautan tapak apabila VPC perlu memulakan sambungan ke LAN.

Putuskan klien, laluan, terjemahan dan kisah identiti dalam urutan itu. Setiap satu mengehadkan yang seterusnya, dan urutan itu menjelaskan mengapa hos berfungsi manakala LAN tidak.