Satu URL untuk Kantor dan VPN? Mengapa Mitos Daftar Izinkan Gagal

Sambungkan terowongan, buka markah yang sama, dan situs yang diizinkan menjawab persis seperti saat dari kantor. Itulah anggapan yang menjadi landasan diam-diam sebagian besar rencana akses jarak jauh, dan hanya bertahan selama tiga hal terpisah tetap benar pada saat yang sama. Tidak satu pun dari ketiganya merupakan fitur klien VPN, dan tidak ada catatan DNS yang dapat menyediakan salah satunya. Ketika markah gagal di rumah, peramban memberi Anda satu galat umum, entah penyebabnya rute yang hilang, alamat keluar yang tidak disetujui, atau proxy yang menggantikan sumber yang dilaporkannya. Memperlakukan ketiganya sebagai satu masalah adalah cara sebuah perbaikan kebijakan kecil berubah menjadi sepekan memperlebar daftar izinkan.

Rancangan yang bertahan saat bersentuhan dengan jaringan kantor sungguhan lebih sempit daripada anggapan itu: tabel keputusan tiga baris yang eksplisit, satu titik penegakan yang tidak dapat dilewati, dan uji penolakan yang membuktikan sesuatu. Membongkar anggapan itu didahulukan, karena semua yang berikutnya bergantung pada mengetahui lapisan mana yang salah menyajikan sumber.

Mitos: terhubung bukan berarti merutekan

Sebuah terowongan terbentuk, dan klien memasang rute untuk sekumpulan prefiks. Itulah seluruh yang dilakukan terhubung. Apakah permintaan HTTPS yang tak berhubungan melewati terowongan, dan dari alamat publik mana ia tampak datang saat tiba, adalah keputusan yang nanti diambil komponen lain: tabel rute memilih jalur, dan jalan keluar memilih sumber.

Karena itulah kantor dan meja dapur berbeda dengan laptop yang sama, profil peramban yang sama, dan markah yang sama. Di kantor permintaan keluar melalui alamat publik terpelihara yang disetujui operator situs. Melalui terowongan penuh ia dapat keluar lewat egress VPN, yang merupakan alamat berbeda dan, sampai seseorang menambahkannya, belum disetujui. Melalui terowongan terpisah ia mungkin tidak pernah masuk terowongan sama sekali. Hanya dua dari tiga jalur itu yang pernah menjadi bagian kesepakatan dengan pemilik situs, dan yang ketiga bukan cacat yang perlu ditambal dengan entri allow tambahan.

Tiga keadaan permintaan, dua jalan keluar yang disetujui

Tuliskan matriksnya sebelum menyentuh firewall, karena tabel itulah rancangannya dan aturan hanyalah salah satu penerapannya. Alamat di bawah adalah rentang dokumentasi; gantilah dengan nilai terpelihara Anda sendiri dan simpan di tempat pemilik situs dapat mengauditnya.

Baris tengah adalah tempat sebagian besar rencana ini patah. Yang diperhitungkan adalah alamat yang dilihat perangkat penegakan, bukan alamat privat yang dipegang laptop di dalam terowongan dan bukan alamat LAN-nya. Nilai seperti 10.8.0.6 tidak berarti apa pun bagi situs publik, dan 192.168.1.44 juga tidak. Alamat terowongan adalah detail pengalamatan terowongan, bukan kredensial yang dapat diperiksa situs.

Jika VPN Anda tidak dapat menyediakan egress yang stabil dan terdokumentasi, matriks tidak punya baris tengah yang sah dan tidak ada berapa pun daftar izinkan yang akan mengarangnya. Pilihan jujur saat itu adalah situs privat yang dijangkau lewat rute privat eksplisit, atau gerbang akses yang sadar identitas di depan aplikasi. Keduanya punya kontrak berbeda dari daftar izinkan publik, dan keduanya lebih mudah dijelaskan kepada auditor daripada daftar yang tumbuh sampai kebetulan berhasil.

Baca sumber di tempat keputusan diambil

Letakkan pembatasannya pada perangkat yang menamatkan permintaan, dan pastikan tidak ada jalur asal alternatif yang melewatinya. Modul akses Nginx mengevaluasi direktif allow dan deny secara berurutan, kecocokan pertama menang, dan aturan yang diwarisi dari blok pembungkus tetap berlaku di dalam location. allow sempit di samping allow lebar di tempat yang sama biasanya berarti yang lebar yang memutuskan. Baca seluruh konfigurasi efektif untuk location itu sebelum menyunting satu barisnya pun.

server {
    listen 443 ssl;
    server_name intranet.example.com;

    set_real_ip_from 10.20.0.10;
    real_ip_header X-Forwarded-For;
    real_ip_recursive on;

    location /app/ {
        allow 203.0.113.24;    # office public exit
        allow 198.51.100.77;   # approved VPN egress
        deny  all;
        proxy_pass http://app_backend;
    }
}

Di belakang penyeimbang beban atau proxy balik, aturan itu melihat proxy kecuali Anda memberi tahu sebaliknya. Pulihkan alamat pemanggil hanya melalui mekanisme proxy tepercaya yang didukung, dengan daftar alamat proxy yang eksplisit. Header permintaan yang mengklaim alamat yang disetujui bukan bukti bahwa pemanggil memilikinya, dan pada pendengar publik header yang diteruskan tanpa validasi menjadikan daftar izinkan sekadar hiasan.

Lalu periksa keluarga alamat lainnya. Himpunan aturan yang hanya mencakup IPv4 adalah keputusan tidak lengkap untuk nama host yang juga menjawab di AAAA, dan klien dengan IPv6 yang berfungsi akan mencapai aplikasi yang sama melalui jalur yang tidak pernah Anda tinjau.

Terowongan terpisah: permintaan yang tak pernah masuk

Terowongan terpisah hanya membawa prefiks dalam daftarnya. Subnet kantor internal biasanya masuk daftar itu; situs web publik tidak. Peramban menyelesaikan nama, membandingkan alamat yang dipilih dengan tabel rute, dan tetap menemukan gerbang bawaan lokal di depannya.

Jadi permintaan datang dari koneksi rumah pengguna, ditolak, dan laporan berbunyi bahwa VPN rusak sementara terowongan justru melakukan persis apa yang dikonfigurasikan. Ada dua perbaikan yang sah: rutekan tujuan itu melalui terowongan dan biarkan egress yang disetujui membawanya, atau terima bahwa situs dijangkau langsung dan beri pengguna jarak jauh jalur disetujui lain seperti gerbang akses. Memperlebar daftar izinkan publik situs sampai alamat rumah kebetulan termasuk bukanlah keduanya, dan itu menghapus batas yang seharusnya ditegakkan rancangan. Dua yang pertama menjaga matriks tetap jujur; yang ketiga diam-diam menghapus satu baris darinya.

Buktikan penolakannya, lalu pemulihannya

Uji dengan permintaan yang menjalankan keputusan sesungguhnya, dari klien yang berdiri di setiap baris tabel. Pemeriksaan keterjangkauan ke halaman sembarang yang menampilkan alamat tidak membuktikan apa pun, karena tujuan itu mungkin menempuh jalur berbeda dari aplikasi.

curl -sS -o /dev/null -w 'status=%{http_code}
' https://intranet.example.com/app/login
# repeat with the tunnel up, then with it down
tail -f /var/log/nginx/access.log | grep ' /app/'

Bandingkan catatan akses di batas dengan apa yang diprediksi tabel. Lalu turunkan terowongan dan buat permintaan baru yang seharusnya ditolak; halaman yang sudah dimuat, atau koneksi yang sudah terbuka, tidak menguji apa pun. Jika tidak ada penolakan yang muncul, titik penegakan tidak berada di tempat yang Anda duga.

Pertahankan autentikasi aplikasi setelah penerimaan jaringan, karena jalan keluar kantor dan egress VPN masing-masing mewakili banyak orang dan tak satu pun mengidentifikasi individu. Instruksi bagi pengguna tetap singkat: naikkan terowongan yang disetujui, lalu coba lagi. Itulah yang membuat satu URL tetap nyaman sementara aturan sumber tetap menjadi keputusan, bukan dugaan.