LAN di balik satu sesi AWS Client VPN: apa yang diteruskan

Laptop terhubung ke endpoint AWS Client VPN, mencapai subnet privat, dan semuanya tampak sehat. Desktop di LAN yang sama tidak mencapai apa pun, padahal host Linux juga punya antarmuka jembatan dan kedua mesin berada di kabel yang sama. Tidak ada yang salah konfigurasi di tunnel; bagian yang hilang adalah perutean, dan jembatan itu petunjuk palsu.

Memperluas sesi Client VPN ke LAN adalah peran gateway. Itu bukan segmen Ethernet yang ditarik ke dalam layanan terkelola.

Host berfungsi dan LAN tidak

Antarmuka tunnel di mesin Linux punya alamat di dalam CIDR klien Client VPN, dan endpoint telah mendorong rute untuk rentang VPC. Permintaan yang dibuat di mesin itu adalah lalu lintas yang dihasilkan secara lokal: ia memilih rute, keluar melalui tunnel, dan mendapat balasan. Jalur itu tidak pernah menyentuh kode penerusan, antarmuka LAN, atau aturan firewall apa pun yang mengatur transit.

Lalu lintas dari perangkat LAN lain adalah aliran berbeda. Ia tiba di antarmuka LAN, butuh rute yang menunjuk ke tunnel, butuh penerusan aktif, butuh firewall yang mengizinkannya, dan butuh balasan kembali melalui host yang sama. Empat syarat, dan uji laptop yang berhasil tidak membuktikan satu pun. Dari desktop kegagalan tampak aneh: tunnel aktif, kredensial valid, dan tujuan tidak pernah menjawab. Cacatnya lokal pada jalur penerusan gateway, bukan pada layanan.

Tidak semua klien bisa menjadi gateway

AWS menyatakan bahwa aplikasi desktop Client VPN-nya tidak mendukung penerusan IP, dan klien lain mungkin mendukung. Batasan itu menentukan arsitektur sebelum perintah apa pun diketik. Jika satu-satunya klien yang tersedia adalah aplikasi desktop resmi, gateway Linux yang meneruskan untuk LAN bukan konfigurasi yang bisa Anda selesaikan, dan tidak ada jumlah masquerading yang akan mengubahnya.

Klien pengganti juga harus cocok dengan metode autentikasi endpoint dan kebijakan yang ingin Anda tegakkan. Endpoint berbasis sertifikat, direktori, dan SAML tidak menerima konfigurasi klien yang sama, dan klien pihak ketiga yang mengautentikasi tetapi mengabaikan rute yang didorong bukan peningkatan.

Perlakukan pilihan klien sebagai bagian dari tinjauan desain. Itu menentukan apakah pola penerusan LAN tersedia sama sekali, dan menentukan identitas apa yang dilihat endpoint untuk setiap perangkat di balik gateway. Catat klien dan konfigurasi endpoint yang dijadikan dasar pengujian. Pergantian klien enam bulan kemudian dapat diam-diam menghapus kemampuan yang diasumsikan desain.

Arahkan LAN ke tunnel dan terjemahkan

Dengan klien yang didukung di tempatnya, sisanya adalah pekerjaan gateway biasa. Perangkat LAN butuh rute untuk rentang VPC yang menunjuk ke host Linux, dan host butuh penerusan aktif. Jika Anda ingin VPC melihat lalu lintas sebagai klien terhubung dan bukan sebagai alamat LAN sembarang, terjemahkan sumber saat 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

Batasi aturan ke antarmuka tunnel dan rentang VPC, seperti di atas, alih-alih melakukan masquerading semua yang diteruskan host. Aturan yang lebih sempit lebih mudah dinalar, dan tidak diam-diam mengubah lalu lintas yang seharusnya mempertahankan alamat sumber aslinya.

Biarkan rute LAN datang otomatis jika bisa: opsi DHCP, pengumuman router, atau rute statis yang didorong oleh apa pun yang mengelola LAN. Rute yang hanya ada di satu mesin uji akan membuat desain tampak rusak saat orang lain mencobanya.

Balasan juga butuh jalur

Setelah permintaan mencapai VPC, balasan harus kembali melalui keadaan penerjemahan yang sama dan menemukan rute LAN di gateway. Bagian itu biasanya bekerja ketika aturan masquerade ada, karena pemetaan hidup di host yang melakukannya. Itu rusak ketika sisi VPC punya rute yang mengirim balasan ke tempat lain, dan itulah sebabnya rute CIDR klien dan asosiasi subnet di endpoint keduanya penting.

Perhatikan penghitung, bukan hanya ping. Aturan masquerade dengan nol paket memberi tahu Anda bahwa permintaan tidak pernah mencapai antarmuka tunnel, yang menunjuk kembali ke rute LAN atau tabel perutean klien itu sendiri. Aturan dengan paket tetapi tanpa balasan menunjuk ke sisi VPC, aturan otorisasi, atau grup keamanan yang tidak menerima sumber yang diterjemahkan. Baca kedua arah sebelum mengubah apa pun, karena hitungan yang hanya tumbuh di satu sisi adalah jalur satu arah, bukan jalur lambat.

Ingat bahwa endpoint adalah layanan terkelola. Tidak ada berkas konfigurasi server untuk diedit dan tidak ada direktif client-config untuk ditambahkan, jadi instruksi yang ditulis untuk server OpenVPN yang dikelola sendiri dengan rute subnet klien khusus tidak berlaku. Di AWS, tuasnya adalah asosiasi subnet, aturan otorisasi, dan tabel perutean VPC.

Identitas bersama adalah bagian yang harus dijawab kebijakan

Setiap perangkat di balik gateway menggunakan sesi VPN gateway. Aturan otorisasi endpoint memberi akses kepada pengguna atau grup, dan dari sudut pandang layanan ada tepat satu pengguna pada sesi itu. Penerusan lokal tidak mengalikan identitas itu menjadi autentikasi per perangkat, dan tidak memperluas pemeriksaan postur perangkat ke printer di sudut.

Itu mungkin dapat diterima, atau mungkin menjadi alasan desain ditolak. Tergantung pada apa yang diasumsikan sumber daya VPC tentang siapa yang memanggil. Identitas bersama yang sesuai dengan model otorisasi tidak masalah; yang diam-diam mengubah satu sesi terautentikasi menjadi akses seluruh LAN adalah temuan yang menunggu ditulis.

Jika persyaratannya benar-benar menghubungkan seluruh situs ke VPC, bandingkan desain situs-ke-situs yang didukung sebelum memperluas klien akses jarak jauh. Semantiknya berbeda, dan sesi klien dengan NAT adalah pengganti buruk untuk tautan situs ketika VPC perlu memulai koneksi ke LAN.

Putuskan klien, rute, penerjemahan, dan kisah identitas dalam urutan itu. Masing-masing membatasi yang berikutnya, dan urutannya menjelaskan mengapa host berfungsi sementara LAN tidak.