Satu URL untuk Pejabat dan VPN? Mengapa Mitos Senarai Benar Gagal

Sambungkan terowong, buka penanda buku yang sama, dan laman yang dibenarkan menjawab tepat seperti yang dilakukannya dari pejabat. Itulah andaian yang menjadi tumpuan senyap kebanyakan pelan akses jauh, dan ia hanya bertahan selagi tiga perkara berasingan kekal benar pada masa yang sama. Tiada satu pun daripadanya ciri klien VPN, dan tiada rekod DNS boleh menyediakan mana-mana satu daripadanya. Apabila penanda buku gagal di rumah, pelayar memberi anda satu ralat umum, sama ada puncanya laluan yang hilang, alamat keluar yang tidak diluluskan atau proksi yang menggantikan sumber yang dilaporkannya. Menganggap ketiga-tiganya sebagai satu masalah ialah cara pembetulan dasar kecil bertukar menjadi seminggu meluaskan senarai benar.

Reka bentuk yang bertahan apabila bersentuhan dengan rangkaian pejabat sebenar lebih sempit daripada andaian itu: jadual keputusan tiga baris yang jelas, satu titik penguatkuasaan yang tidak boleh dilangkau, dan ujian penolakan yang membuktikan sesuatu. Membongkar andaian itu didahulukan, kerana segala-galanya selepasnya bergantung pada mengetahui lapisan mana yang salah menggambarkan sumber.

Mitos: bersambung bukan bermakna menghala

Sebuah terowong dibentuk, dan klien memasang laluan untuk sekumpulan awalan. Itulah keseluruhan yang dilakukan oleh bersambung. Sama ada permintaan HTTPS yang tidak berkaitan melalui terowong itu, dan dari alamat awam mana ia kelihatan datang apabila tiba, ialah keputusan yang kemudiannya dibuat oleh komponen lain: jadual laluan memilih jalan, dan jalan keluar memilih sumber.

Itulah sebabnya pejabat dan meja dapur berbeza dengan komputer riba yang sama, profil pelayar yang sama dan penanda buku yang sama. Di pejabat permintaan keluar melalui alamat awam yang diselenggara yang telah dipersetujui oleh pengendali laman. Melalui terowong penuh ia boleh keluar melalui egress VPN, iaitu alamat berbeza dan, sehingga seseorang menambahnya, belum diluluskan. Melalui terowong berpecah ia mungkin tidak masuk terowong langsung. Hanya dua daripada tiga laluan itu pernah menjadi sebahagian daripada persetujuan dengan pemilik laman, dan yang ketiga bukan kecacatan yang perlu ditampal dengan entri allow tambahan.

Tiga keadaan permintaan, dua jalan keluar yang diluluskan

Tuliskan matriks itu sebelum menyentuh tembok api, kerana jadual itulah reka bentuknya dan peraturan hanyalah satu pelaksanaannya. Alamat di bawah ialah julat dokumentasi; gantikannya dengan nilai terselenggara anda sendiri dan simpan di tempat pemilik laman boleh mengauditnya.

Baris tengah ialah tempat kebanyakan pelan ini patah. Yang dikira ialah alamat yang dilihat oleh peranti penguatkuasaan, bukan alamat persendirian yang dipegang komputer riba di dalam terowong dan bukan alamat LAN-nya. Nilai seperti 10.8.0.6 tidak bermakna apa-apa kepada laman awam, dan 192.168.1.44 juga tidak. Alamat terowong ialah perincian pengalamatan terowong, bukan kelayakan yang boleh diperiksa oleh laman.

Jika VPN anda tidak dapat menyediakan egress yang stabil dan terdokumen, matriks tidak mempunyai baris tengah yang sah dan tiada berapa pun senarai benar akan mengarangnya. Pilihan jujur pada masa itu ialah laman persendirian yang dicapai melalui laluan persendirian yang jelas, atau get laluan akses yang peka identiti di hadapan aplikasi. Kedua-duanya mempunyai kontrak berbeza daripada senarai benar awam, dan kedua-duanya lebih mudah dijelaskan kepada juruaudit daripada senarai yang berkembang sehingga kebetulan berfungsi.

Baca sumber di tempat keputusan dibuat

Letakkan sekatan pada peranti yang menamatkan permintaan, dan pastikan tiada laluan asal alternatif memintasnya. Modul akses Nginx menilai arahan allow dan deny mengikut urutan, padanan pertama menang, dan peraturan yang diwarisi daripada blok yang menyelubungi masih terpakai di dalam location. allow sempit di sebelah allow lebar di tempat yang sama biasanya bermakna yang lebar yang memutuskan. Baca keseluruhan konfigurasi berkesan untuk location itu sebelum menyunting walau satu barisnya.

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 pengimbang beban atau proksi songsang, peraturan itu melihat proksi kecuali anda memberitahunya sebaliknya. Pulihkan alamat pemanggil hanya melalui mekanisme proksi dipercayai yang disokong, dengan senarai alamat proksi yang jelas. Pengepala permintaan yang mendakwa alamat yang diluluskan bukan bukti bahawa pemanggil memilikinya, dan pada pendengar awam pengepala yang dihantar tanpa pengesahan menjadikan senarai benar sebagai hiasan.

Kemudian periksa keluarga alamat yang lain. Set peraturan yang hanya meliputi IPv4 ialah keputusan tidak lengkap untuk nama hos yang juga menjawab pada AAAA, dan klien dengan IPv6 yang berfungsi akan mencapai aplikasi yang sama melalui laluan yang tidak pernah anda semak.

Terowong berpecah: permintaan yang tidak pernah masuk

Terowong berpecah hanya membawa awalan dalam senarainya. Subnet pejabat dalaman biasanya masuk senarai itu; laman web awam tidak. Pelayar menyelesaikan nama, membandingkan alamat yang dipilih dengan jadual laluan, dan tetap menemui get laluan lalai tempatan di hadapannya.

Jadi permintaan datang dari sambungan rumah pengguna, ditolak, dan laporan menyatakan VPN rosak sedangkan terowong melakukan tepat apa yang dikonfigurasikan untuknya. Dua pembetulan wajar: halakan destinasi itu melalui terowong dan biarkan egress yang diluluskan membawanya, atau terima bahawa laman dicapai secara terus dan beri pengguna jauh laluan diluluskan yang lain seperti get laluan akses. Meluaskan senarai benar awam laman sehingga alamat rumah kebetulan termasuk bukanlah kedua-duanya, dan ia menghapuskan sempadan yang sepatutnya dikuatkuasakan oleh reka bentuk. Dua yang pertama mengekalkan matriks jujur; yang ketiga diam-diam memadam satu baris daripadanya.

Buktikan penolakan, kemudian pemulihan

Uji dengan permintaan yang menjalankan keputusan sebenar, dari klien yang berdiri pada setiap baris jadual. Pemeriksaan kebolehcapaian terhadap halaman sembarangan yang memaparkan alamat tidak membuktikan apa-apa, kerana destinasi itu mungkin mengikut laluan berbeza daripada 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 rekod akses di sempadan dengan apa yang diramalkan oleh jadual. Kemudian turunkan terowong dan buat permintaan baharu yang sepatutnya ditolak; halaman yang sudah dimuatkan, atau sambungan yang sudah terbuka, tidak menguji apa-apa. Jika tiada penolakan muncul, titik penguatkuasaan bukan di tempat yang anda sangka.

Kekalkan pengesahan aplikasi selepas kemasukan rangkaian, kerana jalan keluar pejabat dan egress VPN masing-masing mewakili ramai orang dan tiada satu pun mengenal pasti individu. Arahan untuk pengguna kekal pendek: angkat terowong yang diluluskan, kemudian cuba lagi. Itulah yang mengekalkan satu URL selesa sementara peraturan sumber kekal sebagai keputusan, bukan tekaan.