Sudah satu tahun lebih menggunakan Tailscale (daftar pada 22 Maret 2021) dan gue adalah happy users yang dengan senang hati akan merekomendasikan Tailscale untuk berbagai kebutuhan. Tailscale adalah sebuah layanan yang menawarkan VPN, dan dibuat diatas Wireguard. Awalnya yang dijual oleh Tailscale adalah solusi VPN tanpa ribet + SSO, seiring berjalan waktu, terdapat fitur-fitur pemanis yang “nice to have” yang salah satunya adalah MagicDNS.
Setiap komputer pasti memiliki nama, yang gampangnya sebut saja sebuah hostname. Komputer yang sedang gue pakai sekarang bernama macbook-air
dan dengan mDNS, komputer/perangkat lain dapat mengetahui alamat IP gue tanpa perlu mengkonfigurasi apapun khususnya terkait DNS. Di perangkat Apple sudah terpasang Zeroconf by default, yang berarti, gampangnya, iPhone gue bisa mengakses port 80 di laptop gue melalui Safari dengan mengakses http://macbook-air.local
tanpa setup apapun selagi berada dalam satu jaringan lokal yang sama.
Fitur MagicDNS nya Tailscale pun tidak jauh berbeda. Gue bisa mengakses Raspberry Pi gue dari mana saja tanpa perlu mengetahui ataupun mengingat alamat IP dari si raspi tersebut. Misal, bila ingin SSH, gue semudah menjalankan ssh rizaldy@raspi.rizaldy.club.beta.tailscale.net
misalnya, tanpa perlu mengatur apapun, khususnya menambahkankan entri ke DNS.
Tailscale menawarkan fitur lain yakni HTTPS Certificates. Benefitnya ada 2:
- Tidak ada “browser warning” ketika mengakses hostname yang menggunakan alamat IP dari Tailnet gue jika menggunakan protokol HTTPS
- Tidak perlu menulis
device.tailnet.beta.tailscale.net
panjang-panjang
Nama alternatif dari Tailnet gue adalah tailnet-fdxx
(redacted), jadi gue bisa menggunakan ssh rizaldy@raspi.tailnet-fdxx
yang menghemat beberapa huruf.
Bagian menariknya lagi adalah bila mengaktifkan MagicDNS, di berkas /etc/resolv.conf
kita akan terdapat entri tambahan (search) yang digunakan untuk “meng-append”. Let’s say gue menjalankan ssh rizaldy@raspi
, berdasarkan entry search yang ada di berkas tersebut, komputer gue akan mencoba raspi.xx
, raspi.xxx
, raspi.xxxx
sampai ter-resolve.
Di kasus gue, ketika gue menjalankan ping iphone-xs
, komputer gue akan mencoba:
- iphone-xs.tailnet-xxxx.ts.net
- iphone-xs.rizaldy.club.beta.tailscale.net
- iphone-xs.lan
Sampai berhasil satu dari 3 pilihan diatas berhasil.
MagicDNS
Sekilas ini hanyalah sistem DNS biasa, namun bagian menariknya adalah TLD *.ts.net
dan *.beta.tailscale.net
hanya bisa di-resolve oleh perangkat yang berada di Tailnet yang sama. Seperti, jika perangkat gue berada di tailnet rizaldy.club
dan sedangkan gue ingin mendapatkan alamat IP dari perangkat yang berada di Tailnet delman.io
misalnya, DNS tidak akan meresponse apa-apa.
Kasus diatas terjadi karena komputer fariz-devbox
berada di Tailnet yang sama (di delman.io dan rizaldy.club), in fact, Tailscale memiliki fitur “Share machine” yang tujuan gue adalah agar tidak perlu switch account.
Disitu terlihat bahwa di fariz-devbox
bisa resolve domain .delman.io
tapi tidak bisa resolve domain .rizaldy.club
. Sedangkan di workstation
, disitu bisa resolve .rizaldy.club
dan fariz-devbox.delman.io.beta.tailscale.net
, namun tidak bisa resolve desxxxxxxxgnr.delman.io.beta.tailscale.net
, karena sesederhana mesin tersebut tidak berada di satu Tailnet dengan gue.
MagicDNS + HTTPS
Di NUC gue ada menjalankan Nginx Proxy Manager yang berjalan di port 80 dan 443, Jika gue ingin mengaksesnya, maka beginilah tampilannya: Dan ini expected. Umumnya peringatan This Connection Is Not Private terjadi karena 2 hal:
- Penerbit sertifikat SSL yang digunakan tidak terpercaya
- Sertifikat SSL yang ada bukan untuk domain tersebut
Untuk poin nomor satu, ini biasanya menggunakan self-signed certificate. Umumnya terjadi di jaringan yang ingin mengintip aktivitas berinternet lo mengingat koneksi HTTPS menggunakan enkripsi end-to-end. Yang gampangnya, proses dekripsi bukan berada di komputer lo langsung, melainkan di somewhere (in the middle) yang tertarik dengan aktivitas berinternet lo.
Untuk nomor dua juga kurang lebih sama. Tapi terkadang memang karena kesalahan dari si admin yang memberikan sertifikat SSL yang salah meskipun domain yang berbeda berada di satu mesin yang sama.
Kembali ke pembahasan, secara teknis, pesan peringatan diatas kurang relevan karena koneksi ke nuc.rizaldy.club.xxx
tersebut ter-enkripsi secara end to end (via Wireguard). Namun masalah utamanya adalah penerbit sertifikat yang digunakan—menurut si peramban (Safari)—tidak terpercaya karena hanya beberapa penerbit saja yang dia percaya, dan ini normal.
Tailscale menawarkan fitur HTTPS Certificate yang sederhananya mereka akan memberikan sertifikat SSL yang diterbitkan oleh penerbit terpercaya untuk beberapa peramban, yang mana dalam kasus ini penerbitnya adalah Let’s Encrypt. Sehingga pesan annoying sebelumnya menghilang!
Jika menggunakan fitur HTTPS Certificates, Tailscale akan menyediakan domain alternatif (seperti tailnet-fxxx.ts.net
) alih-alih menggunakan delman.io.beta.tailscale.net
misalnya.
Ini memberikan tiga keuntungan:
- Gue tidak perlu setting DNS untuk devbox gue
- Gue tidak mendapatkan pesan “Connection is not secure” di peramban favorit gue
- Hostname/domain yang gue gunakan tersebut terjamin hanya bisa diakses oleh perangkat yang berada di satu Tailnet dengan gue
Karena hal itu, gue bisa menggunakan hostname tersebut sebagai virtual hosts di reverse proxy yang berada di devbox gue tersebut, misal seperti ini:
fariz-devbox.tailnet-fxxx.ts.net {
reverse_proxy /grafana* http://grafana
reverse_proxy /console* http://wetty
reverse_proxy * http://code-server
}
SNI Gotcha
Masalah klasik dari VPN adalah “perimeter security”, yang gampangnya, segala sesuatu yang berada dalam VPN, otomatis dianggap aman. Silahkan gunakan poin nomor tiga—yang sempat gue sebutkan diatas—sebagai contoh.
Kasus sederhananya adalah akses ke aplikasi web yang menggunakan reverse proxy. Of course gue sadar dengan adanya reverse proxy saja sudah mengurangi keamanan, tapi sayangnya menggunakan reverse proxy adalah hal yang umum sekarang.
Masalah terjadi ketika si penyerang mengetahui alamat IP publik dari perangkat gue. Meskipun kemungkinannya sangat kecil, namun attack vector dari threat model ini adalah “ex-employee”, misalnya.
Misal ada aplikasi internal yang hanya bisa diakses via VPN, namun gue tahu alamat IP publik tempat si aplikasi internal tersebut berjalan. Kita gunakan fariz-devbox
sebagai contoh agar lebih mudah.
Yang mana aplikasi internal tersebut berjalan di fariz-devbox.tailnet-fxxx.ts.net
.
Karena penyerang sudah bukan lagi karyawan di perusahaan, maka akses SSO sudah dicabut. Karyawan sudah tidak bisa melakukan autentikasi via Google Workspace.
Yang berarti, sudah tidak bisa lagi berada di Tailnet perusahaan tersebut, yang mana berguna untuk bisa me-resolve .ts.net
dengan fitur MagicDNS nya Tailscale.
Tapi DNS hanyalah DNS. DNS hanyalah sebuah sistem untuk mendapatkan alamat IP dari hostname yang dimaksud.
Dengan MagicDNS, response alamat IP yang akan diberikan adalah alamat IP private si Tailnet, dan ini intended. Dengan menggunakan DNS sederhana melalui /etc/hosts
, kita secara teknis bisa akses aplikasi internal tersebut sekalipun berada diluar Tailnet perusahaan.
Disitu terlihat bahwa gue menggunakan custom DNS dan gue mematikan Tailscale gue setelah menambahkan entri di /etc/hosts
. Dan ini aplikasi yang gue akses:
Yes, sebuah terminal. Tanpa autentikasi.
Tentu ini kesalahan sysadmin. Sysadmin tidak menggunakan middleware untuk memfilter “IP allowlist”. Dan setelah menggunakan middleware, berikut tampilannya: Karena akses ke aplikasi internal tersebut seharusnya berasal dari VPN (Tailscale menggunakan subnet 100.64.0.0/10), maka seharusnya berasal dari IP tersebut.
Penutup
Gue agak bosan mendengar celotehan “ini cuma bisa diakses via VPN kok, jadi aman lah”. VPN pada dasarnya hanyalah overlay network, sebuah jaringan pribadi diatas dibawah jaringan publik (internet). Celotehan selanjutnya adalah tentang “firewall berlapis”, silahkan Googling sendiri, pasti dapat sumbernya :))
Asumsi “menggunakan VPN = aman” menurut gue karena 3 hal:
- Koneksi terenkripsi
- Menggunakan IP private
- Untuk tersambung ke VPN, lo harus autentikasi dulu
Dan ini dapat dimengerti.
Nyatanya, di sistem yang menggunakan VPN dan fiReWaLL berLaPiS pun masih saja ada yang kebobolan.
Mungkin gue compare nya tidak fair. Biasanya VPN paling berguna untuk menghubungkan mesin yang air gap. Yang untuk bisa mengakses ke mesin tersebut harus melalui “jumphost” yang berada di VPN.
Dan jika mesin jumphost tersebut kebobolan? Ya jumping kita.
Alternatif dari VPN adalah ada sebuah konsep bernama Zero Trust, yang mana dipopulerkan oleh BeyondCorp nya Google. Model dari Zero Trust ini adalah “Trust but verify” dan salah satu penerapannya ada di IAP atau Identity-Aware Proxy yang mana termasuk dalam kategori Zero Trust Access.
Mengambil contoh gue yang sebelumnya, salah satu faktor yang gue gunakan adalah gue berasumsi bahwa aplikasi hanya bisa diakses dari jaringan tertentu, yang mana dari subnet 100.64.0.0/10. Jika menerapkan zeRo trUsT ini, gue tidak mengambil “jaringan tertentu” tersebut sebagai salah satu faktor. Umumnya di zero trust model ini faktornya adalah si pengguna dan perangkatnya. Bukan tentang si perangkat dengan alamat IP 100.86.101.4.
Jika pengguna dengan alamat email me@rizaldy.club boleh mengakses B, maka bisa mengakses B. Tapi misalnya hanya boleh dari perangkat X (macbook) dan tidak bisa dari perangkat lain sekalipun penggunanya adalah me@rizaldy.club.
Tailscale menggunakan pendekatan yang sedikit berbeda.
Jika model zero trust umumnya tidak peduli berada di jaringan mana (sekalipun itu internet), Tailscale tetap menggunakan pendekatan VPN + model zero trust yang sempat disinggung.
Namun berbeda dengan solusi VPN pada umumnya, Tailscale menggunakan model peer-to-peer dan tanpa VPN gateway. Technically Tailscale (sebagai penyedia layanan) memiliki control plane tapi tidak bertindak sebagai VPN gateway.
Gue personally tidak “mendewakan” Tailscale. Dalam praktiknya gue menggunakan solusi lain juga seperti Cloudflare Access dan Pomerium. Tapi jika masalah yang gue miliki bisa diselesaikan oleh Tailscale, maka gue akan berhenti disitu dan tidak melanjutkan mempertimbangkan Cloudflare Access lalu ke Pomerium.
Sebagai penutup, kasus yang gue angkat di tulisan ini adalah kasus yang agak umum terjadi di VPN yang tidak menggunakan pendekatan “BeyondCorp” ini. Solusi VPN yang menjual “Zero Trust” dan “Beyond Corp” biasanya menggunakan reverse proxy, in fact, di bagian comparisons nya Tailscale rata-rata alternatifnya menggunakan reverse proxy sebagai pengganti VPN.
…yang tentu saja masih menggunakan VPN untuk menghubungkan 2 jaringan berbeda, yang mungkin sekarang lebih relevan disebut “VPC”.
Anyways, jika membutuhkan solusi untuk “akses layanan dari mana saja”, give Tailscale a try. You deserve it.
Ingin akses Pi-hole di rumah dari mana saja? Akses Firefly-III di server rumah dari mana saja? Akses SSH di cloud tanpa ribet ngurus SSH keys dari mana saja?
Bulan lalu gue ada pekerjaan untuk menghubungkan infrastruktur yang ada di GCP dan AWS. Beberapa layanan berada di VPC nya GCP, dan infrastruktur di AWS perlu terhubung ke layanan tersebut. Tentu saja kasus ini membutuhkan VPN untuk menghubungkan 2 jaringan berbeda.
Dan jika VPN tersebut tidak menggunakan Tailscale, gue rasa gue akan lebih stress daripada sekarang.
Karena berurusan dengan VPN selalu membuat stress.
Dan menggunakan Tailscale, membuatnya menjadi less stress.
Tetep stress, cuman lebih sedikit.
Sekarang sudah tidak terlalu stress.
Karena sudah tidak ada VPN diantara kita HAHAHA.