Reverse Proxy dengan Autentikasi di Server Caddy Linux

Artikel ini membahas Reverse proxy dengan Caddy server yang diperkuat sistem autentikasi untuk menentukan hak ases pengguna. Pada pembahsan ini kita contohkan saja menggunakan DNS eksternal penaadventure.com dan DNS internal unixwinbsd.site. Biar lebih jelasnya perhatikan gambar di bawah ini.

Diagram Reverse Proxy dengan Caddy Web Server

Server DNS internal lokal dikonfigurasi menggunakan tampilan sehingga nama host internal media server unixwinbsd.site dan nama DNS eksternal penaadventure.com yang dicadangkan untuk proyek tersebut diarahkan ke alamat IP LAN lokal yang sama. Artinya, mengakses unixwinbsd.site atau penaadventure.com pada LAN lokal di browser akan menghasilkan koneksi ke server unixwinbsd pada LAN lokal.

1. DNS Dinamis

Anda dapat mendaftarkan nama domain reguler untuk proyek tersebut, tetapi idenya adalah menggunakan biaya sumber daya dan kompleksitas pengaturan yang sangat rendah sehingga varian akhir yang dipilih adalah menggunakan layanan DNS dinamis daring (DDNS). Kenyataannya, DNS dinamis tidak merujuk pada pembaruan DNS server bind yang umum pada reservasi alamat IP, tetapi merujuk pada layanan daring yang mengekspos kait pemrograman yang dapat digunakan untuk memperbarui alamat IP eksternal dari nama domain yang disediakan oleh "penyedia dns dinamis", yang merupakan tugas yang dapat diselesaikan dengan mudah menggunakan alat seperti ddclient.

Artinya, pengaturan yang dijelaskan dalam dokumen ini hanya menggunakan dua nama domain, penaadventure.com, masing-masing auth.penaadventure.com, tanpa mendaftarkan nama subdomain tambahan untuk setiap Servarr (Sonarr, Lidarr, dll). Untungnya, sebagian besar layanan DNS dinamis mengizinkan subdomain dari domain yang dicadangkan, seperti media atau auth. Salah satu triknya adalah mengkonfigurasi subdomain media dan auth agar menjadi penunjuk (PTR) atau nama kanonik (CNAME) dari DNS dinamis tingkat atas yang dicadangkan seperti penaadventure.com.

Dengan mengkonfigurasi subdomain sebagai penunjuk atau nama kanonik domain tingkat atas, setiap kali alamat IP diperbarui melalui alat seperti ddclient, nama subdomain lainnya akan menunjuk ke alamat IP yang diperbarui. Kesalahan yang mungkin terjadi adalah membuat catatan A untuk media dan auth karena catatan A dapat dikonfigurasi secara terpisah untuk menunjuk ke alamat IP yang berbeda sehingga tidak ada jaminan bahwa ddclient akan memperbaruinya.

Sebagai kesimpulan, catatan DNS berikut dibuat:

penaadventure.com.      A               EXTERNAL_IP

media                            PTR          penaadventure.com.

auth                               PTR          penaadventure.com.

2. Menyiapkan Instalasi Servarr

Konfigurasi masing-masing instans tidak terlalu penting, hanya saja instans tersebut harus dikonfigurasi untuk menggunakan jalur dasar, bukan jalur akar.

Artinya, semua server Servarr akan dikonfigurasi untuk memiliki baseURL, sehingga pasangan host dan jalur berikut harus setara:

media.tld/sonarr, media.penaadventure.com/sonarr,

media.tld/radarr, media.penaadventure.com/radarr

dan seterusnya untuk semua server Servarr.

Hal ini dapat dikonfigurasi di bagian "Umum" pada setiap Servarr.

Saat menyiapkan semua Servarr, Anda dapat menonaktifkan autentikasi sepenuhnya, atau membuat set pengecualian yang diperlukan untuk alamat IP LAN yang tidak dapat dirutekan untuk melewati autentikasi dan kemudian mengakses Servarr secara langsung.

3. Menyiapkan Reverse Proxy

Demi kenyamanan, dua reverse-proxy dikonfigurasi menggunakan caddy. Reverse-proxy pertama akan ada di server internal media.tld dan akan memungkinkan akses ke instans Servarr menggunakan jalur baseURL. Berikut ini adalah contoh konfigurasi untuk caddy yang akan melakukan reverse-proxy ke beberapa layanan Servarr sehingga layanan tersebut dapat diakses melalui LAN FQDN dari server "media" plus baseURL yang telah dikonfigurasikan untuk Servarr terkait:

Sekarang, sesuai dengan baris pertama dalam konfigurasi 127.0.0.1:32400, tujuan default untuk setiap permintaan melalui HTTP ke server media pada port 80 akan dialihkan ke port 32400 pada mesin lokal, yang merupakan port mendengarkan default untuk server Plex Media.

Server proxy terbalik kedua yang akan diinstal, akan berada di gateway Internet yang menghadap ke depan dan akan melakukan proxy terbalik permintaan eksternal ke server internal pada server media. Alasan untuk menambahkan server caddy lain ke pengaturan adalah pemisahan masalah di mana server media adalah entitas yang berdiri sendiri yang dapat dijadikan bagian dari LAN mana pun (misalnya: kontainer, seperti mesin virtual) sementara caddy pada gateway Internet akan bertindak untuk LAN yang dikonfigurasikan secara khusus. Keterbatasannya, tentu saja, adalah karena port HTTP dan HTTPS bersifat unik dan layanan lain mungkin perlu diekspos dalam LAN.

Gateway caddy reverse-proxy juga akan bertanggung jawab untuk melakukan autentikasi bagi klien di luar LAN lokal karena lebih mudah untuk melindungi seluruh alokasi Servarr, daripada harus melalui semua layanan dan mengaktifkan autentikasi dan proteksi. Bahkan jika autentikasi diaktifkan untuk semua Servarr, serta layanan tambahan yang bahkan tidak memiliki autentikasi bawaan, hal itu masih merupakan satu tingkat pemisahan lagi di mana permintaan yang datang melalui koneksi Internet eksternal akan diproses pada server yang menghadap ke depan dan tidak akan hanya di-NAT ke jaringan lokal (khususnya, mesin media).

Dengan demikian, berikut adalah konfigurasi lengkap untuk caddy pada gateway yang menghadap ke Internet:

{
        log {
                output file /var/log/caddy/access.log {
                        roll_size 250mb
                        roll_keep 5
                        roll_keep_for 720h
                }
        }

        order authenticate before respond
        order authorize before reverse_proxy

        security {
                local identity store localdb {
                        realm local
                        #path /tmp/users.json
                        path /etc/caddy/auth/local/users.json
                }
                authentication portal media {
                        enable identity store localdb
                        cookie domain media.home.entertainment.tld
                        cookie lifetime 86400
                        ui {
                                theme basic
                                links {
                                        "Services" /services
                                }
                        }
                }
                authorization policy admin_policy {
                        set auth url https://auth.home.entertainment.tld
                        allow roles authp/user authp/admin
                }
        }

        order replace after encode
}

auth.home.entertainment.tld {
        tls some@email.tld
        
        authenticate with media
}

media.home.entertainment.tld {
        tls some@email.tld

        # Expose iCal without authorization and only based on API key authentication.
        # /sonarr/feed/calendar/Sonarr.ics?apikey=
        # /radarr/feed/v3/calendar/Radarr.ics?apikey=
        @noauth {
                not path_regexp \/.+?\/feed(/.*?)*\/calendar\/.+?\.ics$
                not remote_ip 192.168.0.1/24
        }

        handle @noauth {
                authorize with admin_policy
        }

        reverse_proxy media.tld {
                header_up Host {host}
                header_up X-Real-IP {remote}
                header_up X-Forwarded-Host {hostport}
                header_up X-Forwarded-For {remote}
                header_up X-Forwarded-Proto {scheme}
        }
}

Saat permintaan tiba di gateway Internet yang menghadap ke depan, server caddy berdasarkan konfigurasi sebelumnya, akan melakukan langkah-langkah berikut, secara berurutan:

• Cookie autentikasi akan diperiksa keberadaannya pada browser yang mengakses server caddy serta alamat IP browser yang mengakses,
• Jika ada cookie atau permintaan berasal dari jaringan lokal 192.168.1.0/24, maka permintaan akan diteruskan ke server media di media.tld,
• Jika tidak ada cookie autentikasi di browser dan permintaan berada di luar LAN lokal, caddy akan mengalihkan permintaan ke auth.home.entertainment.tld di mana pengguna akan diminta untuk mengautentikasi menggunakan autentikator berbasis formulir,
• Setelah autentikasi berhasil, pengguna akan diarahkan kembali ke FQDN dan URL asli yang diminta, sehingga diharapkan dapat mencapai salah satu Server

Satu-satunya langkah yang terlewat adalah pengecualian berikut ini:

not path_regexp \/.+?\/feed(/.*?)*\/calendar\/.+?\.ics$

yang memperbolehkan jalur Servarr cocok dengan ekspresi reguler, seperti:

# /sonarr/feed/calendar/Sonarr.ics?apikey=
# /radarr/feed/v3/calendar/Radarr.ics?apikey=

Umumnya, ini baik-baik saja, karena mengakses layanan iCal untuk semua Server memerlukan kunci API, sehingga meskipun layanan tersebut diekspos ke publik, pengguna akan memerlukan kunci API untuk dapat menarik kalender iCal secara efektif. Lebih jauh, mengingat caddy dikonfigurasi dengan E-Mail TLS melalui pengaturan.

lalu caddy akan secara otomatis membuat sertifikat SSL/TLS untuk domain media.home.entertainment.tld dan auth.home.entertainment.tld. Anda juga dapat menyiapkan sertifikat SSL/TLS wildcard, tetapi hal itu memerlukan penyedia seperti CloudFlare untuk mengatasi tantangan LetsEncrypt atau ZeroDNS dalam pembuatan sertifikat.