Hadkan hos Subversion kepada pengguna VPN dengan Apache 2.4

ServerName memilih hos maya; ia tidak mengehadkan siapa yang menyambung. Tuntut julat VPN dan pengguna repositori sebenar, kemudian buktikan kedua-dua penolakan.

Menghalakan hos maya Subversion ke alamat VPN mengubah tapak mana yang menjawab permintaan, bukan siapa yang dibenarkan menghantarnya. Semakan akses berlaku kemudian, mengikut peraturan dalam bahagian yang sepadan dengan URL, dan nama hos tidak pernah masuk ke dalam keputusan itu. Jika ServerName ialah satu-satunya perubahan anda, repositori itu sama mudah dicapai seperti semalam. Dua soalan berasingan perlu dijawab dalam konfigurasi: soket mana yang menerima sambungan dan identiti mana yang dibawa oleh permintaan itu.

Apa yang sebenarnya ditentukan oleh ServerName

Pengehosan maya berasaskan nama membandingkan pengepala Host dengan entri ServerName dan ServerAlias, memilih satu hos dan membiarkannya mengendalikan permintaan. Sambungan itu sendiri telah diterima lebih awal oleh soket Listen milik pelayan, bukan hos. Itulah sebabnya nama yang kelihatan peribadi tidak menawarkan perlindungan: mana-mana klien yang mencapai soket itu boleh menghantar pengepala Host tersebut. Nama ialah kunci penghalaan, dan kunci penghalaan dipilih oleh pemanggil.

Anda boleh melihat pemetaan tanpa meneka. apachectl -S mencetak setiap hos, port dan namanya, serta menandakan yang mana satu lalai untuk alamat itu.

RequireAll ialah bekas yang menjadikan kedua-dua semakan wajib

Apache 2.4 membalut arahan Require satu bahagian dalam RequireAny tersirat, jadi dua arahan kosong bermakna salah satu daripadanya sudah cukup. Tambah bekas itu dan maknanya terbalik:

<Location /svn/repo>
    AuthType Basic
    AuthName "Subversion"
    AuthBasicProvider file
    AuthUserFile /etc/apache2/svn.htpasswd
    <RequireAll>
        Require ip 10.8.0.0/24
        Require valid-user
    </RequireAll>
</Location>

RequireAll memerlukan kedua-dua syarat: alamat sumber dalam julat terowong dan pengguna yang diterima repositori. Itulah yang sepatutnya bermaksud hanya-VPN untuk URL Subversion. Rujukan mod_authz_core mendokumenkan peraturan bekas itu. Kekalkan blok di dalam Location sedia ada untuk repositori dan biarkan arahan DAV yang sudah berfungsi di tempatnya, kerana fragmen ini tidak menggantikan AuthType, fail kata laluan mahupun kebenaran peringkat laluan.

Ujian sumber datang daripada mod_authz_host, jadi sahkan ia dimuatkan sebelum menyahpepijat apa-apa lagi: apachectl -M | grep authz_host.

Alamat yang dinilai Apache ialah alamat soket

Require ip membandingkan dengan alamat yang direkodkan Apache untuk sambungan itu, dan ia bukan selalu alamat yang klien sangka dimilikinya.

Apabila VPN menghalakan alamatnya tanpa terjemahan, Apache melihat alamat terowong dan 10.8.0.0/24 sepadan. Apabila get laluan menterjemah, Apache melihat get laluan dan peraturan itu senyap tidak sepadan dengan apa-apa; perkara sama berlaku di belakang pengimbang beban yang menamatkan TLS di hadapan hos. Untuk kes itu ada mod_remoteip. RemoteIPHeader X-Forwarded-For bersama RemoteIPTrustedProxy untuk pengimbang menggantikan alamat yang direkodkan, dan barulah julat itu mempunyai sesuatu untuk dibandingkan.

Mempercayai pengepala penghantaran sewenang-wenangnya lebih buruk daripada tiada peraturan sama sekali. Mana-mana klien boleh menghantar X-Forwarded-For yang mengandungi 10.8.0.9 dan memenuhi semakan julat yang tidak pernah ditambat kepada hop yang dipercayai.

Lapisi pendengar dan dasar repositori

Pengikatan ialah kawalan berasingan dan selalunya lebih mudah. Listen 10.8.0.1:443 menentukan soket mana yang wujud, dan permintaan tidak boleh memilih hos pada soket yang tidak pernah dibuka. Harganya ialah urutan permulaan: jika antara muka terowong turun apabila Apache bermula, pengikatan gagal dan perkhidmatan tidak naik. Pasangkannya dengan urutan unit, atau ikat pada alamat yang wujud secara bebas daripada terowong.

Kebenaran laluan kekal dalam AuthzSVNAccessFile. Akaun sah untuk tapak itu bukan pemberian yang sama seperti akses tulis ke laluan projek, dan peraturan rangkaian tidak mengubahnya.

Perhatikan penggabungan bahagian apabila blok berada dalam fail yang disertakan. Apache menggabungkan bekas kebenaran merentas bahagian bersarang dan bahagian yang paling khusus sepadan boleh menggantikan keperluan dan bukannya menambahnya, jadi peraturan pada /svn mungkin tidak sampai ke /svn/repo/trunk apabila bahagian yang lebih sempit menetapkan peraturannya sendiri.

Buktikan kedua-dua penolakan sebelum menganggapnya selesai

Uji empat permintaan, bukan satu. Di dalam VPN dengan akaun sah anda sepatutnya mendapat senarai repositori. Di dalam VPN dengan kata laluan salah anda sepatutnya mendapat 401 dan bukan senarai. Dari luar VPN dengan kelayakan sah anda sepatutnya mendapat 403, dan permintaan awam yang sama ke nama hos alternatif mesti gagal dengan cara yang sama.

Satu arahan bagi setiap kes sudah cukup: curl -sI -u user:pass https://svn.example.com/svn/repo/, kemudian baca baris status. Ulangi kes yang berfungsi melalui klien sebenar juga, kerana svn info melatih kaedah DAV yang akan digunakan oleh commit dan kemas kini.

Jika mana-mana daripada empat keputusan tidak sepadan dengan dasar yang anda maksudkan, konfigurasi belum selesai, dan menukar nama hos tidak akan mengubahnya.

Artikel berkaitan