Jika kamu bekerja di perusahaan SaaS (Software as a Service), cool, kemungkinan besar tulisan ini untukmu. Jika bukan, atau mungkin belum, just pretend you are and fake it till you make it.
Ketika seseorang berkata bahwa dia bekerja di sebuah perusahaan yang menjual software (atau kita persingkat menjadi program), yang mereka jual sebenarnya adalah lisensi. Seperti, jika kamu membuat & menjual sebuah program untuk mengakses basis data menggunakan GUI, pengguna membeli lisensi alias "serifikat" yang menandakan bahwa pengguna tersebut sah dapat menggunakan program karena telah membelinya, dan yang mana "license key" adalah buktinya.
Tapi program bukanlah sebuah produk yang dirancang untuk terakhir. Akan selalu ada perubahan, peningkatan, perbaikan dsb yang memakan waktu yang tidak sedikit.
Mengambil contoh TablePlus diatas, lisensi yang digunakan oleh mereka adalah "perpetual license" namun dengan lifetime 1 tahun untuk bisa mendapatkan pembaruan secara valid. Jika lebih dari 1 tahun, maka lisensi yang ada harus di perbarui juga untuk dapat mendapatkan pembaruan terbaru, jika ingin (dan harusnya menjadi sebuah keharusan).
Sayangnya pengelolaan lisensi ini bukanlah pekerjaan yang mudah. Bahkan sistem pengelola lisensi yang dirancang oleh sekelas Microsoft saja dapat di "pecahkan" untuk produk Windows dan Office mereka (and we know it).
Tapi poin utamanya bukan disitu.
Ini adalah tentang bagaimana membuat "development hours" menjadi efisien sehingga pengguna & pengembang mendapatkan solusi win-to-win dan tidak ada yang dirugikan.
Alih-alih hanya menjual lisensi, bisnis software sekarang banyak beralih ke menjualnya sebagai layanan. Layanan tersebut lumayan beragam, dan yang paling populer adalah menawarkan support, tempat penyimpanan dan computing power. Mengambil contoh Microsoft, jika sebelumnya, mungkin, untuk dapat menggunakan salah satu produk Office bernama Microsoft Word secara legal harus membayar 1,899,999 IDR (dan hanya untuk produk Office), sekarang bisa membayar 959,999 IDR*/tahun* namun juga mendapatkan penyimpanan sebesar 1TB, akses support, plus tidak perlu memasang Microsoft Office untuk dapat menggunakan salah satu produknya, karena "computing power" dan tempat penyimpanan tersebut berada di komputer Microsoft sehingga dapat menghemat penyimpanan plus sumber daya yang dikonsumsi di komputer pengguna.
Dan hey, pengguna tidak perlu ribet melakukan pembaruan versi karena pada dasarnya yang mereka gunakan hanyalah "client" untuk berinteraksi dengan produk utamanya (bukan keseluruhan dari produk tersebut) dan umumnya client tersebut berukuran kecil dan tidak memakan banyak sumber daya.
Terdengar menarik?
Enterprise customer
Belum lengkap rasanya jika bisnis SaaS tidak menawarkan paket khusus yang biasa bernama "Enterprise". Singkatnya, jika biasanya customer akan menyesuaikan kebutuhan dengan paket yang ditawarkan, khusus untuk kasus ini, justru kebalikannya: paket yang ditawarkan harus menyesuaikan dengan kebutuhan customer ini.
Alasannya beragam namun yang paling populer adalah karena mereka memiliki "kebutuhan khusus" berdasarkan standar yang mereka miliki.
Kebutuhan khusus ini yang paling populer adalah "custom deployment", jika biasanya keseluruhan program dijalankan penuh di komputer penyedia layanan, dalam kebutuhan ini berarti program tersebut dijalankan di komputer mereka.
Sehingga computing power dan penyimpanan berasal dari komputer mereka.
Tidak semua bisnis SaaS wajib memiliki paket ini, tapi jika program yang kamu kembangkan ingin digunakan oleh organisasi yang lebih besar dan rumit, sudah dipastikan paket ini harus ada mengingat ehm angka yang akan masuk terlihat sangat menggiurkan.
Enterprise infrastructure
Bagaimanapun enterprise memiliki infrastrukturnya sendiri yang seharusnya sudah berjalan selama mungkin. Salah satu infrastruktur tersebut adalah data center, yang pada dasarnya hanyalah kumpulan komputer tempat dimana data berikut aplikasi yang memproses data tersebut berada.
Komputer-komputer tersebut saling terhubung dan terus berjalan tanpa mengenal tombol shutdown.
Umumnya tempat yang bisa digunakan untuk mengakses infrastruktur mereka selain langsung dari tempat data center tersebut berada adalah sebuah bangunan bernama kantor. Spesifiknya, menggunakan jaringan yang terpasang di kantor tersebut yang umumnya bersifat pribadi.
Sederhananya, jaringan yang ada di kantor tersebut terhubung ke data center secara fisik, baik untuk alasan keamanan ataupun efektivitas.
Namun bagaimana bila ingin mengakses infrastruktur tersebut diluar bangunan kantor, contohnya seperti kondisi saat ini yang mengharuskan pekerja bekerja dari jarak jauh termasuk dari rumah?
Harus ada sesuatu yang dapat menghubungkan jaringan private tersebut melalui jaringan public alias internet.
Dan sesuatu tersebut bernama VPN.
Virtual Private Network (VPN)
Pada contoh diatas kita menggunakan "pekerja" sebagai subjek, silahkan ganti menjadi "komputer tempat aplikasi kamu berjalan" jika ingin.
VPN sederhananya adalah sebuah jaringan pribadi yang berada di jaringan publik (internet). Untuk dapat mengakses jaringan pribadi melalui jaringan publik, setidaknya ada 2 pilihan yang bisa dipilih:
- Melalui proxy
- Melalui VPN
Dua pilihan diatas memiliki tujuan yang sama—mengakses jaringan pribadi melalui jaringan publik—dan perbedaan kontrasnya adalah proxy selalu bertindak sebagai "gateway" alias semua paket harus selalu masuk ke dan keluar dari proxy server tersebut.
Mari kita bahas sedikit tentang proxy terlebih dahulu untuk mempermudah bagaimana bayangan.
Kita mulai dari proxy yang paling umum digunakan di jaringan internet: reverse proxy. Yang dalam contoh ini program yang digunakan adalah nginx.
Sederhananya reverse proxy menggunakan "hostname" sebagai identifier alih-alih alamat IP nya secara langsung, sehingga ketika pengguna ingin mengakses komputer dengan alamat IP tertentu, yang mengakses komputer tersebut adalah si reverse proxy tersebut.
Dan alamat IP yang digunakan si hostname tersebut mengarah ke komputer tempat reverse proxy tersebut berjalan.
Sebagai contoh, alamat IP 172.22.0.15 diatas adalah alamat IP private yang digunakan oleh si komputer yang menjalankan aplikasi django di port 80 di jaringan 172.22.0.0/24, dan hanya bisa diakses oleh komputer yang berada di jaringan tersebut.
Menggunakan reverse proxy untuk mengakses jaringan private melalui jaringan publik terlihat lebih mudah namun terdapat banyak tantangan baik dari sisi keamanan maupun sisi performa mengingat permintaan masuk dan keluar pun selalu melewati proxy server.
Selain itu, terkadang kebutuhannya pun sangat beragam dan memproksi paket TCP saja tidak cukup.
Site to Site VPN
Ini adalah jenis yang umum digunakan jika ingin menghubungkan 2 jaringan pribadi berbeda.
Diagram diatas hanyalah contoh dan di kasus nyata seharusnya lebih ribet dari diagram diatas. Sebatas gambaran, dibagian kiri dapat berkomunikasi dengan keseluruhan subnet 192.168.100.0/24 di kanan sedangkan yang kanan hanya dapat berkomunikasi dengan jaringan ber-alamat IP 100.64.0.1 di kiri.
Multi Site VPN
Ini lebih ribet dari yang sebelumnya. Jika yang sebelumnya hanya berkomunikasi dengan 1 jaringan pribadi, disini kita akan berkomunikasi dengan 2 jaringan pribadi.
Dan gue rasa ini yang paling banyak digunakan di jaringan enterprise.
Biasanya mereka (bagian kanan) memiliki data center yang berada di tempat berbeda (let's say di markas utama dan di IXP) dan multi site VPN ini kadang digunakan jika memang somehow routing ke berbeda subnet tidak dihandle oleh mereka.
Gue pribadi pernah berhadapan dengan jaringan seperti ini, dan ehm gue lempar menjadi masalah mereka daripada harus establish 2 tunnel ke endpoint berbeda.
Point to Site VPN
Jika yang sebelumnya direksinya adalah 1-1, di point to site direksinya adalah N-1 yang biasanya kasusnya untuk remote access (atau "Road Warrior" bahasa kerennya).
Contoh kasusnya gue rasa... untuk remote access? Hahaha oke oke selain itu mungkin bisa juga untuk mengakses komputer yang air gapped melalui bastion host, mengakses database di remote server dari local, dsb.
Gue rasa gak ada yang terlalu spesial dengan jenis VPN ini, karena, ehm, melakukan port forwarding saja gue rasa sudah cukup just in case para stakeholder ingin membuka terminal dan melakukan SSH hahaha.
Mesh VPN
Dari awal topologi jaringan yang digunakan adalah "Hub-and-Spoke" alias Star Network yang meskipun di banyak kasus bukanlah sebuah masalah, tapi tetap memiliki potensi terjadinya Single Point Of Failure (SPOF).
Sumber gambar: How Tailscale works
Dengan mesh VPN terdapat benefit lucu yang bisa didapat, seperti:
- Komputer (sebisa mungkin) berkomunikasi secara peer-to-peer
- Mengurangi latensi (just in case beberapa komputer ada yang berada di region berbeda dengan "central hub")
- Menghindari SPOF
Sayangnya di beberapa kasus Mesh VPN tidak cost effective khususnya bila menggunakan "VPN solution" yang ditawarkan oleh cloud provider yang digunakan (bayangkan bila melakukan inter-region ataupun inter-cloud VPC peering).
Protokol VPN
Di banyak kasus, ada 4 protokol yang biasanya paling laku di pasaran:
- IPsec
- L2TP
- PPTP
- TLS
Jika network architect nya cukup edgy mungkin akan menggunakan Wireguard.
Terdapat pro-kontra dari setiap opsi protokol yang ada, namun yang pasti konfigurasi VPN adalah pekerjaan yang stressful, terlepas protokol apa yang ingin digunakan.
Studi kasus
Kamu membuat aplikasi untuk memproses access log yang tersimpan di S3. Proses yang dilakukan adalah mengumpulkan data, mentransformasinya, dan mengirimkan hasilnya ke RDBMS.
RDBMS yang digunakan adalah Postgres dan berada di jaringan private milik klien.
Sayangnya Postgres mereka hanya bisa diakses dijaringan private (lokal) karena alasan keamanan, dan sebagaimana yang kita tahu untuk dapat mengakses jaringan private melalui jaringan publik adalah dengan membuat VPN karena hampir tidak mungkin bila kita menghubungkan komputer kita secara fisik.
Dengan membuat VPN kasus ini dapat terselesaikan yang sederhananya dengan cara paket dikirimkan ke komputer yang mengetahui harus kemana paket tersebut diteruskan.
Sorry if I oversimplified this as I used Tailscale for this example. And yes, using Tailscale to establish a VPN is that easy.
Penutup
Gue tadinya ingin berbagi tentang bagaimana teknisnya membuat VPN dari menggunakan IPsec sampai Wireguard, tapi gue urungkan karena gue rasa itu terlalu "usang" dan rencananya gue ingin membagikannya namun untuk di lingkungan cloud.
Tujuan gue menulis ini sebenarnya ingin menjelaskan sedikit tentang penggunaan VPN di penggunaan di bisnis mengingat kata VPN sekarang seringkali terikat dengan "consumer VPN" alias penggunaan pribadi yang tidak lepas dengan iming-iming privasi dan anonimitas.
Jika kamu bekerja ataupun menjalankan perusahaan SaaS dan memiliki paket Enterprise (atau setidaknya memiliki target pasar untuk mereka), gue rasa mengkonfigurasi VPN adalah sesuatu yang tidak bisa dihindari, cepat atau lambat.
À la revoyure!
Top comments (0)