Serba-serbi VPN

VPN itu apa sih? Virtual Private Network adalah teknologi untuk membuat serangkaian perangkat terhubung ke jaringan virtual yang sama. Jadi seolah-olah berbagai device tergabung di satu jaringan. Di posting ini saya akan membahas VPN dari sudut pandang user, sampai kalau ingin membuat VPN sendiri.

VPN banyak digunakan di dunia corporate atau enterprise. Penggunaan yang umum adalah untuk menghubungkan berbagai kantor regional dengan kantor lain atau dengan kantor pusat. VPN juga dipakai oleh remote worker untuk mengakses resource kantor (server, printer, dsb) yang tidak bisa diakses dari umum. Dengan koneksi VPN, komputer rumah atau laptop masuk ke jaringan perusahaan. Jika browsing via VPN maka , seolah-olah kita mengakses internet dari perusahaan tersebut.

Sumber: wikipedia

Beberapa bank juga menggunakan koneksi VPN untuk partnernya, jadi berbagai perusahaan yang ingin mengakses sistem bank harus lewat VPN. Ini hanya layer keamanan tambahan, selain itu masih digunakan password dan juga token.

VPN juga bisa digunakan untuk berinternet lewat server orang lain. Sebenarnya prinsipnya sama dengan sebelumnya: kita bergabung di jaringan privat dan dari situ mengakses internet. Tujuannya memakai VPN biasanya:

  • Membypass blokir
  • Mendapatkan konten tertentu, misalnya daftar film Netflix di Thailand dan USA sangat berbeda
  • Menyembunyikan IP, misalnya untuk wartawan yang takut dipersekusi

Di VPN seperti ini kita hanya numpang lewat untuk internet saja. Ini tidak beda (dari sisi security) seperti numpang WIFI di tempat publik atau rumah orang: pemilik access point bisa mengakses traffic tertentu (kata kuncinya di sini adalah: tertentu). Akan saya jelaskan lebih lanjut di artikel ini.

Koneksi Lewat VPN seperti numpang WIFI di sebuah tempat

Siapa penyedia layanan VPN ini? untuk perusahaan ya mereka sendiri. Selain itu ada penyedia VPN, baik yang gratis maupun berbayar. Kita juga bisa menyewa sendiri VPS (Virtual Private Server) atau dedicated server, biayanya tidak jauh beda dengan VPN berbayar.

Keamanan Aplikasi Gratis

Ada berbagai catatan dalam keamanan VPN gratis. Pertama adalah keamanan aplikasi itu sendiri, terlepas dari aplikasi VPN atau bukan, sebuah aplikasi bisa melakukan banyak hal di ponsel kita tanpa kita sadari.

Di OS Android yang lama, sebuah aplikasi bisa dengan mudah mendapatkan isi phone book, imei, dsb. Bahkan di Android ataupun iOS terbaru pun jika pengguna memencet “YES” untuk berbagai permission, maka aplikasi tetap bisa mendapatkan banyak informasi dari ponsel Anda.

Bahkan jika tidak mendapatkan informasi apapun, sebuah aplikasi bisa menjalankan coin miner di ponsel Anda. Artinya ponsel Anda akan dipakai untuk mendapatkan uang dari berbagai cryptocurrency. Efek buruk menjalankan coin miner terus menerus adalah: HP jadi panas dan akan mengurangi masa hidup batere ponsel Anda.

Tentunya aplikasi apapun juga bisa menampilkan iklan. Ini adalah salah satu sumber pendapatan VPN gratis. Cara dengan iklan ini walaupun menyebalkan tapi masih lebih baik daripada mencuri data.

Secara umum: menginstall aplikasi tidak dikenal bisa berbahaya. Jika Anda bukan orang teknis: jangan menginstall aplikasi dari luar Play Store atau App Store. Aplikasi dari app store dan play store sudah diverifikasi dan biasanya aman (walau kadang ada juga yang lolos).

Untuk aplikasi atau game dari luar app store, risikonya cukup besar. Semakin tua versi sistem operasi Anda, semakin berbahaya. Jika aplikasi mendapatkan akses “root”, maka aplikasi tersebut bisa melakukan apa saja. Termasuk juga mengganti semua aplikasi Anda (termasuk banking) dengan aplikasi lain yang ada backdoornya.

Jadi sekali lagi: sebuah aplikasi bisa berbahaya, baik itu aplikasi VPN ataupun bukan jika sumbernya tidak jelas.

Keamanan VPN

Khusus untuk aplikasi VPN, ada tambahan bahwa aplikasi tersebut bisa memonitor data yang keluar dan masuk. Dalam hal ini kemampuan sebuah aplikasi VPN untuk memonitor dan memodifikasi data tidak beda dengan access point WIFI yang Anda pakai di publik.

Sekarang ke bagian yang saya sebutkan di atas mengenai traffic tertentu yang bisa diakses oleh VPN atau penyedia WIFI gratis. Sebagai pemilik access point WIFI di rumah saya, saya bisa:

  • mengetahui koneksi ke server mana saja
  • memonitor traffic tertentu
  • mengarahkan koneksi dari satu server ke server lain
  • mengganti isi koneksi yang tidak terenkripsi

Perlu dicatat bahwa ada koneksi ke server yang terenkripsi dan tidak terenkripsi. K0neksi yang tidak dienkripsi bisa dimodifikasi. Ini seperti menulis pesan dengan kartu pos, semua bisa membacanya dan mencoret/mengubah isinya.

Apakah koneksi terenkripsi aman? Tergantung aplikasinya. Koneksi terenkripsi seperti memakai amplop untuk mengirim pesan. Tentunya bisa saja seseorang di tengah untuk membongkar amplopnya dan menggantinya dengan amplop baru. (Catatan teknis: sebenarnya tidak semudah itu, kita perlu menginstall root certificate di ponsel).

Sebuah aplikasi yang tidak aman akan menerima “amplop” dari siapa saja asalkan pesannya masih dalam amplop. Tapi aplikasi yang memakai SSL Pinning akan memeriksa detail dan cap di amplop tersebut dan tidak akan mau melakukan koneksi jika amplopnya berbeda.

Perlu dicatat juga: defaultnya jika kita mengetik alamat saja: bni.co.id, maka defaultnya akan memakai koneksi tidak terenkripsi, lalu kita diforward ke koneksi yang terenkripsi.

Beberapa situs mengijinkan koneksi HTTP lalu memforward ke koneksi HTTPS. Contohnya ketika kita mengetik bni.co.id, maka

Tapi beberapa tidak, misalnya jika kita mencoba ibank.klikbca.com maka koneksi tidak bisa dilakukan. Tapi koneksi awal ini bisa menimbulkan masalah: koneksi yang tidak terenkripsi ini bisa dimodifikasi, misalnya jadi Location: https://bni.co.id.bank-negara-indonesia-secure-connection.com/ dengan bank-negara-indonesia-secure-connection.com adalah server saya.

Jadi ketika mengetik pertama kali secara manual, ada risiko bisa terarahkan ke server lain. Tapi jika koneksinya dilakukan langsung dengan aplikasi ebanking maka ini lebih aman. Karena:

  • alamat sudah di-hardcode ke URL HTTPS
  • Umumnya aplikasi bank sudah mengimplementasikan SSL Pinning (setidaknya yang saya cek)

Secara umum, mengganti SSL sebuah koneksi langsung akan ditolak oleh kebanyakan aplikasi (ini ditolak di level library SSL). Jika ingin agar koneksinya diterima, kita bisa menginstall root certificate. Dengan menginstall root certificate, kebanyakan aplikasi (yang tidak memakai SSL Pinning) akan bisa dimonitor.

Bagaimana memeriksa jika kita menginstall Root Certificate? dari menu ini di Android. Jika Anda menemukan list ini tidak kosong, dan Anda tidak pernah menginstallnya, tandanya ada sesuatu yang tidak beres (Android akan memberi peringatan network monitoring)

Di dalam gambar berikut saya menginstall beberapa certificate saya sendiri dan dari sebuah aplikasi yang saya pakai.

Atau ini di iOS (di About: Certificate Trus Settings)

Saya sudah mengecek beberapa aplikasi perbankan seperti: BCA, Mandiri, BRI, BNI, semuanya sudah memakai SSL Pinning. Jadi secara umum: memakai VPN gratis yang didownload dari play store aman untuk transaksi banking melalui aplikasi banking.

Aplikasi VPN bisa mencatat beberapa hal mengenai browsing Anda meskipun tidak bisa melihat semua traffic:

  • Bisa tahu Anda mengunjungi situs tertentu (terutama jika situs tersebut hanya punya 1 IP)
  • Bisa tahu besarnya data yang lewat (jadi bisa tahu apakah kira-kira Anda mengupload sesuatu atau sekedar mendownload/browsing)
  • Bisa tahu kapan Anda mengakses situs-situs tersebut

Data-data tersebut (beserta IMEI, dsb) bisa dijual ke pihak lain.

Ada satu lagi bahaya aplikasi VPN, ini pernah ketahuan di aplikasi HolaVPN. Perlu diketahui bahwa informasi mengalir dua arah: dari komputer/ponsel ke provider VPN dan sebaliknya. Sebuah aplikasi VPN bisa saja menjual bandwith Anda. Artinya: pengguna layanan VPN lain bisa saja dilewatkan trafficnya melalui ponsel/komputer Anda. Jika ternyata isi trafficnya illegal (misalnya pornografi anak), Anda bisa kena masalah.

Aplikasi Hola VPN pernah tertangkap menjual bandwidth

VPN untuk mengamankan Wifi Publik

VPN yang tidak bisa dipercaya sama bahayanya dengan WIFI publik. VPN yang bisa dipercaya, bisa menambah keamanan ketika memakai WIFI publik. Dengan VPN, seluruh traffic keluar sampai ke server VPN terenkripsi, dan artinya pemilik WIFI publik tidak bisa menguping.

Memakai VPN akan membuat pemilik WIFI publik tidak bisa melihat/memodifikasi traffic jaringan kita

Sekali lagi: dalam kasus ini yang bisa menguping adalah provider VPN. Jadi pilih provider yang terpercaya, atau setup sendiri server VPN Anda.

Mensetup VPN Sendiri

Sulitkah mensetup VPN sendiri? sebenarnya tidak asalkan punya dasar teknis administrasi Linux/Windows. Ada beberapa skrip di Internet yang bisa dijalankan untuk mengotomasi ini. Contoh yang cukup terkenal adalah openvpn road warrior. Cukup butuh semenit untuk membuat sebuah server dedicated ataupun VPS dengan skrip ini:

https://github.com/Nyr/openvpn-install

Skrip tersebut ditujukan untuk mensetup server OpenVPN dan menghasilkan file ovpn yang siap dipakai dari berbagai OS (Linux, Windows, OS X, iOS dan Android). Cara memakai file ovpn yang dihasilkan skrip: copy file tersebut ke device Anda, install software OpenVPN (bisa dicari di app store/play store), lalu buka filenya dan tekan “connect”.

OpenVPN dengan server sendiri

Tentunya ini bukan satu-satunya cara mensetup VPN. Ada banyak software VPN lain, contohnya di blog ini saya pernah membahas cara setup software tinc. Secara umum setup berbagai software VPN cukup memakan waktu.

Dulu saya pernah juga memberikan layanan VPN + Hack supaya bisa menginstall aplikasi secara tidak resmi di Blackberry 10 via OTA (tapi layanannya sudah saya tutup). Ini memakai Openswan dengan skrip custom. Videonya masih ada:


Bagaimana dengan biayanya? Sebuah server dedicated bisa didapatkan dengan harga mulai 10an USD. VPS bisa didapatkan dengan harga mulai 1 USD. Dengan 5 USD kita bisa mendapatkan VPS DigitalOcean yang berlokasi di Singapore yang cukup cepat diakses dari Indonesia. Tentunya satu server (baik dedicated maupun VPS) bisa dipakai beberapa orang, jadi biayanya bisa lebih rendah lagi

DNS alternatif

Sebenarnya jika hanya ingin mengatasi blokir internet, DNS alternatif bisa digunakan. Contohnya yang mudah adalah 1.1.1.1 dari Cloudflare.

Prinsip pemblokiran sebuah situs adalah seperti ini:

  • Ketika akan melakukan koneksi ke facebook.com, kita perlu IPnya, ini ditanyakan ke DNS
  • DNS akan memeriksa apakah ada di daftar blokir, jika ya, maka redirect ke internet positif
  • Jika aman, makan DNS akan memberikan IP yang benar.

Jadi untuk mengatasinya ada beberapa cara:

  • Menggunakan server DNS alternatif. Tapi kadang port 53 diblok ke server lain, sehingga kita hanya bisa memakai DNS milik ISP
  • Memakai DNS over HTTPS (memakai port 443). Ini mudah memakai DNS Cloudflare: https://1.1.1.1/ (silakan download aplikasi yang tersedia di website tersebut)
  • Mengedit sendiri file hosts dan memasukkan kombinasi host name dan IP address secara manual. File ini ada di /etc/hosts (Linux/BSD), di /etc/private/hosts (OS X), atau %SYSTEMROOT%\System32\Drivers\etc\hosts (Windows)

Membuat Software VPN Sendiri

Mensetup dan memakai software VPN tidak membuat Anda jadi ahli dalam soal VPN. Jika ingin benar-benar paham, cobalah membuat software VPN sendiri dengan API yang disediakan oleh berbagai sistem operasi.

Mengapa membuat VPN ini latihan yang bagus:

  • Anda jadi mengerti pemrosesan paket jaringan
  • Anda jadi mengerti bagaimana mengimplementasikan enkripsi paket jaringan
  • Bisa paham jika ingin mengevaluasi security sebuah aplikasi VPN

Software provider VPN akan membuat jalur terenkripsi dari sebuah komputer ke komputer lain. Untuk membuat software VPN sendiri, kita perlu pemahaman yang cukup baik mengenai networking sampai ke level paket jaringan.

Di tahap awal, kita bisa membuat VPN yang tidak terenkripsi sama sekali . Kemudian kita bisa menambah enkripsi sederhana, lalu yang lebih rumit.

Pertama agar software ini bisa menerima dan meneruskan paket jarigan, maka kita perlu membuat sebuah network interface baru untuk menerima dan mengirim paket data. Biasanya ada dua jenis network interface: level paket di layer 3 (Internet Protocol/IP atau protokol lain) dan layer 2 (ethernet frame)

Setelah interface VPN bisa digunakan, kita perlu memberitahu berbagai program agar memakai interface tersebut untuk mengirim dan menerima data. Ini bisa dilakukan dengan mengubah default route agar melalui interface tersebut. Perlu dicatat: program yang memiliki privilege tinggi bisa membypass VPN dengan langsung memakai network interface tertentu.

Ada banyak ide yang bisa dan sudah banyak yang diimplementasikan yang bisa dilakukan dengan mengintersepsi network:

  • Membuat ad blocker berbasis VPN
  • Membuat network sniffer (Contoh yang sudah ada di play store: Packet capture)
  • Membuat protokol VPN yang jika disniff seolah-olah hanya saling mengirimkan gambar (padahal ada datanya di dalam gambar tersebut dengan steganografi).

Dengan membuat sendiri software VPN kita bisa terbebas dari spyware yang mungkin ada di software seperti kasus Onavo dari Facebook.

Network interface virtual: TUN dan TAP

Untuk sistem operasi Linux, ada dua network jenis network adapter virtual TUN dan TAP yang bisa dibuat. Bedanya dengan network interface fisik adalah: jika ada paket jaringan masuk ke interface ini, maka paket tersebut tidak dikirimkan ke hardware, tapi ke sebuah program yang bisa kita buat sendiri (user space program). Program ini yang perlu kita buat yang akan memproses tiap paket jaringan yang lewat.

TUN (Tunel Network) bekerja di layer 3 sedangkan TAP bekerja di layer 2. Dalam kebanyakan aplikasi kita cuma butuh TUN saja karena hanya butuh melewatkan paket network, tidak perlu memproses level ethernet frame.

Untuk mengakses tunnel device ini kita bisa menggunakan API tertentu atau dengan ioctl. Tutorial contohnya bisa dibaca di sini:

Windows tidak memiliki API sederhanya untuk user mode networking. Network driver di Windows perlu diimplementasikan dengan NDIS dan ini cukup kompleks plus butuh code signing yang cukup repot dan mahal. Untungnya sudah ada yang membuatkan driver TUN dan TAP . Kita bisa memakai kedua driver ini (OpenVPN, Tinc, dan berbagai software lain memakai pendekatan ini).

VPN API di Android

Di Android kita tidak bisa dengan mudah membuat interface network ini. Jika kita ingin membuat service VPN baru, kita perlu menggunakan API VPN Service. API ini sebenarnya hanya membungkus interface TUN dan sekaligus mensetup default route agar lewat VPN. Dengan API ini, program kita perlu membaca raw packet, mengenkrip paket tersebut, lalu meneruskannya.

Untuk parsing paket IP, Android tidak menyediakan API-nya. Dalam kasus tertentu kita bisa parsing sendiri header IP-nya (misalnya sekedar membaca destination IP dan port). Untuk kasus kompleks kita perlu library stack IP. Contoh kasus kompleks misalnya jika kita ingin menangani stream SSL lalu mendekrip stream tersebut.

Kebanyakan aplikasi VPN yang saya periksa menggunakan native library untuk parsing dan processing paket jaringan (tidak diparse di Java). Jika ingin mempelajari bagaimana membuat aplikasi VPN sendiri, ada banyak proyek open source Android yang bisa dilihat, misalnya:

https://github.com/M66B/NetGuard

VPN API di iOS dan macOS

Apple menyediakan beberapa API untuk VPN. Secara high level kita bisa memakai protokol VPN yang sudah ada dan sekedar membuat aplikasi untuk mengendalikan koneksinya (misalnya membuat layar login yang lebih bagus atau terkoneksi ke sistem billing). Secara low level, kita bisa membuat protokol kita sendiri

https://developer.apple.com/documentation/networkextension

Untuk memakai ini di iOS kita perlu memakai Network Extension Entitlement, tadinya memakai ini di iOS butuh ijin khusus dari Apple, tapi sekarang sudah tidak perlu lagi. Contoh penggunaan API sudah disediakan Apple di:

https://github.com/ios-sample-code/SimpleTunnel

Penutup

VPN adalah nama sebuah teknologi yang sebenarnya cakupannya cukup luas, tapi sekarang banyak dipersempit jadi sekedar: mengakses internet lewat komputer orang lain. Lalu mulai ada banyak informasi tidak benar berdasarkan penyederhanaan ini.

Semoga informasi yang di tulisan ini bisa memperluas wawasan Anda mengenai VPN. Mungkin ada juga yang jadi ingin mengimplementasikan protokol VPN sendiri.

Saya tidak menyarankan layanan VPN tertentu, karena takut salah:

  • Kadang ada layanan super populer (dulu Hola) yang ternyata kemudian ketahuan tidak aman
  • Ada layanan VPN yang sekarang aman, tapi nanti bisa saja berubah total, entah karena tekanan bisnis atau dibeli pihak lain

Jika butuh VPN:

  • untuk sekedar keamanan pribadi (misalnya ketika memakai WIFI publik) setuplah VPN sendiri
  • Jika ingin mengamankan diri dari pihak berwajib atau orang jahat pakailah TOR anonymity network
  • Jika ingin mengakses konten dari negara lain: silakan pakai layanan berbayar

Server rumah dengan IP publik

Sebagian orang ingin menghosting sendiri berbagai hal di rumah (atau kantor kecil), baik itu web, email, maupun layanan lain. Biasanya koneksi ISP tidak akan memberikan IP publik yang statik tanpa membayar ekstra (biasanya mahal), jadi biasanya banyak trik digunakan supaya server rumah bisa diakses dari luar.

Sebagai catatan sebelum menggunakan trik yang ada di sini: pertimbangkan memakai VPS atau dedicated server. Membuat server di rumah punya banyak kelemahan jika ANda tidak mengerti apa yang Anda lakukan:

  • Koneksi internet dan pasokan listirk di rumah biasanya kurang reliable dibanding data center
  • Jika salah konfigurasi, hacker bisa lebih mudah masuk ke jaringan rumah
  • Mengkonfigurasi semuanya sendiri cukup melelahkan/membuang banyak waktu

Dynamic DNS

Beberapa layanan tertentu seperti web cukup memakai dynamic DNS dan tidak perlu server eksternal tambahan. Artinya sebuah nama domain selalu diupdate IP-nya dengan IP terbaru saat ini. Untuk mengupdate ini bisa digunakan berbagai layanan Dynamic DNS dan server di rumah perlu diinstall software untuk mengupdate pemetaan nama ke IP.

Gambarannya kira-kira seperti ini:

Masalah dengan pendekatan ini adalah: akan ada jeda ketika ada update nama ke IP. Jeda ini karena DNS server akan mengcache informasi IP. TTL terkecil yang bisa diset biasanya 30 detik dan berbagai layanan DNS biasanya mengeset waktu minimumnya 1 menit. Jadi ketika ada pergantian IP, sekitar 1 menit kemudian kita baru bisa mengakses nama tersebut dengan IP baru.

Masalah lainnya adalah: layanan tertentu tidak akan berjalan dengan baik menggunakan pendekatan ini:

  • ISP kadang memblok port tertentu (saat ini ISP saya di sini memblok incoming connection ke port 80 dan 443), tidak bisa menjalankan web server di rumah dengan port standar
  • Andaikan tidak diblok, beberapa layanan seperti email tidak suka dengan IP dinamik (kadang IP masuk ke daftar spam list)

SSH Forwarding

Solusi ini dan berikutnya akan butuh sebuah server VPS. Kalau butuh VPS, kenapa tidak dihosting di VPS saja sekalian? ada beberapa alasan mengapa kita ingin hosting di rumah dengan menggunakan IP VPS:

  • Mungkin VPS-nya kurang powerful (VPS termurah hanya sekitar 5 USD, tapi disk dan RAM-nya kurang besar)
  • Kita ingin data tetap ada di rumah/kantor karena berbagai alasan. Alasannya bisa mengenai privasi, mengenai kemudahan update data/program, dsb.

Jika keperluannya hanya sederhana, SSH Forwarding bisa dilakukan. Saya pernah menjelaskan teknik ini di artikel saya yang lain mengenai SSH. Ini merupakan cara sederhana karena:

  • Tidak perlu setup sesuatu yang kompleks di server (cukup akses SSH yang biasanya memang sudah aktif), hanya perlu mensetup konfigurasi agar Remote Port Forwarding diijinkan
  • Tidak perlu setup sesuatu di client, cukup perlu SSH Client saja.

Satu VPS juga bisa dikoneksikan dengan beberapa server rumah. Mungkin server yang satu untuk web server, dan server yang lain untuk keperluan backup atau email. Atau bisa juga beberapa domain ditangani oleh satu VPS dan diforwarde (dengan apache/nginx atau yang lain) sesuai dengan domainnya.

Intinya adalah: dari server di rumah, kita melakukan SSH ke VPS. Koneksi ke port tertentu ke VPS akan diforward ke server di rumah. Kelemahan SSH forwarding adalah: dari sisi server di rumah semua incoming IP dianggap dari localhost.

Contohnya: pengunjung web dari Belanda, akan melakukan koneksi VPS server tersebut (misalnya di Singapura) lalu koneksinya di forward ke server rumah (misalnya di Indonesia). Di web server di Indonesia, terlihat koneksinya dilakukan dari IP localhost. Jaid bukan dari Belanda ataupun dari Singapura.

Masalah lain SSH adalah: koneksinya bisa putus. Di Linux program autossh bisa dipakai untuk menjaga agar koneksi tetap hidup. Di Windows kita bisa memakai SSH Client dari BitVise yang bisa melakukan auto reconnect.

VPN + DNAT

Ada banyak solusi VPN yang bisa dipakai. Salah satunya yang pernah saya bahas adalah dengan tinc. Bahkan VPN dengan SSH juga bisa dilakukan (dengan menggunakan tunnel device). Dengan VPN, sebuah VPS akan memiliki 2 network interface, satu yang menghadap publik, dan satu yang menghadap ke client VPN (dalam hal ini server di rumah).

Dengan menggunakan DNAT kita bisa mengarahkan agar paket yang diterima di server akan diforward ke client VPN. Perhatikan bahwa ada banyak cara melakukan forwarding ini. tergantung setting firewall dan cara forwardingnya, maka ada dua kemungkinan:

  • Source IP koneksi bisa berasal dari IP VPN server publik (biasanya bukan ini yang diharapkan)
  • Source IP koneksi bisa dari client yang melakukan koneksi ke VPS

Saat ini ada banyak jenis firewall, tergantung OS yang dipakai (iptables, nftables, ipfw, dsb), jadi saya tidak akan membahas detail settingnya, tapi hanya beberapa hal saja yang penting diperhatikan ketika mensetup ini:

  • Pastikan IP forwarding diaktifkan di VPS
  • Pastikan bahwa firewall rule paket dari IP publik berhasil diterima dan diteruskan ke VPN (bisa dicek dengan menggunakan tcpdump -i INTERFACEVPN)
  • Di sisi server rumah: pastikan koneksi yang datang memiliki source address yang benar
  • Ketika server rumah membalas paket yang datang, pastikan koneksi harus lewat VPN lagi (jangan salah membalas langsung lewat IP rumah)

Penutup

Artikel ini tidak membahas detail tiap perintah dan setting yang diperlukan untuk mengimplementasikan masing-masing solusi. Silakan dicari lagi detailnya dengan berbagai kata kunci yang dipelajari di sini (misalnya: Dynamic DNS, Remote Port Forwarding, DNAT dsb). Artikel ini sekedar memberikan pemahaman saja, bukan tutorial.

Salah satu pertanyaan yang paling tidak saya sukai adalah mengenai jaringan komputer. Untuk bisa menjawab suatu pertanyaan, biasanya saya perlu bertanya banyak hal mengenai konfigurasi jaringan saat ini, software yang dipakai dsb. Menanyakan hal semacam ini butuh waktu yang biasanya sangat lama. Setelah itu ada masalah: versi kernel, versi software dsb. Belum lagi jika ada masalah ISP memblokir sesuatu. Semuanya ini bisa dicari sendiri di Internet.

Semoga informasi ini berguna, dan sekali lagi mohon jangan bertanya detail cara melakukan setup semuanya. Silakan digoogling sendiri detailnya.

VPN dengan Tinc

Saat ini ada banyak sekali solusi VPN yang tersedia dengan segala kelebihan dan keterbatasannya. Beberapa contoh solusi yang populer dan gratis adalah OpenVPN, strongSwan, WireGuard, berbagai implementasi PPTP, tinc, dan VPN via SSH. Posting ini akan membahas mengenai tinc yang memiliki fitur mesh networking.

Beberapa perbedaan dari berbagai solusi VPN ini adalah:

  • Support platformnya. Contoh: saat ini wireguard tidak memiliki client di Windows, jadi kalau Anda memakai Windows, ini jelas tidak akan dipertimbangkan.
  • Kemudahan instalasinya (contoh: VPN melalui SSH cukup rumit setupnya, terutama di Windows)
  • Kecepatannya (ini biasanya hanya jika Anda memakai link dengan kecepatan tinggi) dan CPU usagenya (jika memiliki komputer dengan spesifikasi rendah)
  • Keamanannya, walau secara praktis serangan terhadap berbagai protokol VPN ini jarang/sulit dilakukan kecuali pada protokol kuno seperti PPTP.

Selain berbagai perbedaan teknis, pertimbangan lain memilih VPN adalah: apakah protokol VPN tertentu atau port tertentu diblok oleh ISP. Contohnya di ISP saya saat ini VPN dengan PPTP diblok, jadi harus menggunakan yang lain.

Karena ada begitu banyak software VPN, maka saya tidak akan membandingkan semuanya dan hanya akan membahas tinc saja di posting ini. Pengetahuan di atas sekedar untuk memberitahu bahwa tinc mungkin bukan solusi terbaik di berbagai skenario.

Seperti saya singgung di atas Kelebihan tinc adalah kemampuannya membuat mesh network. Mungkin ada yang bertanya-tanya: maksudnya mesh networking seperti apa sih? Maksudnya adalah sebuah node bisa terkoneksi ke node lain tanpa melalui hierarki tertentu dan sifatnya dinamik.

Semua VPN bisa kita gunakan untuk membuat konfigurasi seperti ini: ada server dan banyak client.

Dengan tinc kita bisa membuat konfigurasi seperti gambar berikut.

Garis yang saya gambarkan ini sekedar menunjukkan bahwa ada setting agar suatu node melakukan koneksi ke node tertentu. Dalam praktiknya: setelah kita mengkonfigurasi ini, kita bisa melakukan koneksi dari satu node ke node manapun.

Contoh konfigurasi di atas kira-kira seperti ini:

  • Ada 2 VPS (Node 1 dan Node 4) dengan IP Publik
  • Node 2 dan 3 diset bisa melakukan koneksi ke node 1 (IP node i ini publik jadi mudah setting ini)
  • Node 5 dan 6 diset bisa melakukan koneksi ke node 4
  • Node 7 (mungkin ini sebuah virtual machine di Node 6) diset untuk melakukan koneksi melalui Node 6

Tentunya konfigurasi jaringannya bisa seperti apa saja: intinya sebuah node bisa dikoneksikan ke satu atau lebih node lain (contohnya bisa saja dibuat setting bahwa Node 2 bisa terkoneksi langsung ke Node 3).

Setelah setting ini selesai, koneksi dari node manapun ke manapun bisa dilakukan seolah-olah semuanya ada di jaringan yang sama. Jadi node 7 ke node 2 bisa langsung dilakukan.

Bagaimana jika kita ingin menambah node baru? misalnya ingin menambah VM di node 6, sehingga ada Node 8 yang terkoneksi ke node 5, apakah kita perlu susah payah mengubah semua konfigurasi? Jawabannya: tidak, kita cukup menambahkan di node 6 bahwa ada node bernama Node 8 dengan public key tertentu, dan di Node 8 perlu diberi public key Node 6 supaya bisa tahu bahwa Node 6 ini adalah node yang valid.

Kehebatan tinc adalah jika kita menambahkan Node 8 yang terkoneksi ke Node 6, maka Node 7 dan 8 bisa berkomunikasi langsung di jaringan lokal, tidak melalui VPS. Bahkan bisa juga kita mengkonfigurasi agar Node 2 dan 3 juga melakukan koneksi ke dua VPN bukan cuma 1 (ke Node 1 dan Node 4). Jika Node 1 down, otomatis route lain akan diambil (lewat Node 4).

Atau jika masih sulit dibayangkan. Anggap saja semua node tersebut seolah terhubung ke sebuah switch virtual (atau hub, tergantung modenya di konfigurasi tinc). Karena terhubung ke switch maka semua seolah berada di jaringan yang sama.

Konfigurasi di Linux

Untuk menkonfigurasi sebuah node, yang perlu dilakukan:

  • membuat sebuah direktori dengan nama jaringan yang kita inginkan
  • membuat file tinc.conf di direktori itu
  • membuat private dan public key untuk host kita
  • mengcopy public key host lain yang ingin kita hubungi
  • mengkonfigurasi interface jaringan

Bagian terakhir (konfigurasi interface jaringan) ini yang berbeda di tiap OS. Kita bisa memakai skrip atau mensetup manual.

Tentunya sebelum mulai, kita perlu menginstall tinc. Gunakan software package manager yang sesuai untuk OS masing-masing atau gunakan installer untuk Windows. Di ubuntu/debian:

apt-get install tinc

Saya contohkan jaringan kecil pertama, dengan node1 ada di eksternal (punya IP publik), sedangkan yang lain IP-nya private. Saya beri nama jaringan ini: jaringanku. Bayangkan saja nama jaringan ini seperti nama sebuah switch dalam ilustrasi sebelumnya.

Untuk contoh ini host eksternal saya beri nama “serverku” dan host internal “komputerku“. Sekarang kita konfigurasi serverku:

Buat direktori baru:

sudo mkdir -p /etc/tinc/jaringanku/hosts

Buat file tinc.conf (pathnya: /etc/tinc/jaringaku/tinc.conf). Isinya:

Name = serverku
AddressFamily = ipv4
Interface = tun0

Buat file /etc/tinc/jaringanku/hosts/serverku dengan isi:

Address = alamat_ip_publik_serverku
Subnet = 10.0.0.1/32

Artinya IP server ini dalam jaringaku adalah 10.0.0.1, tentunya ini bisa diganti dengan IP private manapun. Saya sendiri sudah memakai IP 192.168 di jaringan rumah saya, jadi saya memakai 10.x.x.x untuk tinc.

Lalu buat private/public key untuk server ini, tekan saja enter untuk berbagai pertanyaan defaultnya

 tincd -n jaringanku -K4096

Sekarang kita butuh skrip untuk mengeset IP ketika jaringan up dan menghapus IP ketika jaringan down.

Buat: /etc/tinc/jaringanku/tinc-up dengan isi:

#!/bin/sh
ifconfig $INTERFACE 10.0.0.1 netmask 255.255.255.0

Catatan: sebenarnya cara yang lebih modern adalah menggunakan perintah “ip addr add”. Tapi cara ini masih kurang cross platform (tidak jalan di BSD dsb). Jadi saya masih lebih suka memakai ifconfig.

Dan /etc/tinc/jaringanku/tinc-up

#!/bin/sh
ifconfig $INTERFACE down

Jangan lupa diset modenya agar bisa dieksekusi:

sudo chmod +x /etc/tinc/jaringanku/tinc-*

Sekarang untuk komputerku (yang ipnya private) langkahnya sangat mirip. Hanya saja di sini ada konfigurasi agar koneksi dilakukan dari host ini ke server publik (tidak bisa sebaliknya karena server publik tidak bisa melakukan koneksi ke jaringan internal).

sudo mkdir -p /etc/tinc/jaringanku/hosts

Isi tinc.conf disesuaikan: namanya dan ada ConnectTo

Name = komputerku
AddressFamily = ipv4
Interface = tun0
ConnectTo = serverku

Sekarang buat file /etc/tinc/jaringanku/hosts/komputerku dengan isi:

Subnet = 10.0.0.2/32

Cukup itu saja, kita akan memberi alamat 10.0.0.2 ke komputerku. Buat juga key untuk node ini

 tincd -n jaringanku -K4096

Isi /etc/tinc/jaringanku/tinc-down sama dengan serverku, tapi isi tinc-up sedikit berbeda (IP-nya disesuaikan)

#!/bin/sh
ifconfig $INTERFACE 10.0.0.2 netmask 255.255.255.0

Nah sekarang langkah penting: setiap kali 2 node terhubung langsung, kedua node tersebut perlu tahu key satu sama lain. Jadi intinya:

  • Copy isi /etc/tinc/jaringaku/hosts/serverku di server ke
    /etc/tinc/jaringaku/hosts/serverku di komputerku
  • Copy isi /etc/tinc/jaringaku/hosts/komputerku ke
    /etc/tinc/jaringaku/hosts/komputerku di server

Jadi misalnya kita mau menambah laptop (misalnya namanya: laptopku yang akan dipakai jalan-jalan dengan IP yang berbeda-beda), settingnya sama dengan komputerku. Kita cukup perlu copy key laptopku ke serverku dan isi key serverku ke laptop dan dari laptop kita bisa konek ke komputerku.

Dalam kasus itu kita tidak perlu mengcopy key komputerku ke laptop, walau boleh saja kalau mau. Misalnya supaya gampang, semua isi file hosts dicopy ke sebuah hosting atau dropbox dan tiap kali setup komputer baru, semua file-file di copy ke /etc/tinc/jaringaku/hosts/. Isinya hanya public key yang tidak rahasia, yang rahasia adalah private keynya.

Nah sekarang saatnya testing. Di server dan komputer jalankan:

 tincd -D -d4 -n jaringanku

Jika semua beres, dari server kita bisa ping ke 10.0.0.2 (ke komputer) dan dari komputer kita bisa ping ke 10.0.0.1 (ke server). Jika semua lancar, kita bisa men-kill tincd dan membuatnya permanen. Supaya permanen, di sistem yang memakai systemd kita bisa menggunakan ini:

systemctl enable [email protected]
systemctl start [email protected]

Setting di Windows

Sebenarnya konfigurasinya sama saja dengan Linux. Yang berbeda adalah instalasinya dan lokasi direktorinya. Supaya tidak terlalu panjang artikelnya, silakan lihatpetunjuk instalasi di : https://www.tinc-vpn.org/examples/windows-install/

Lokasi direktori konfigurasi ada di: C:\Program Files (x86)\tinc (pada Windows 64 bit) atau C:\Program Files\tinc (Windows 32 bit). Buat direktori: “jaringanku” di dalam direktori tersebut (butuh hak admin, seperti halnya di Linux butuh root).

Untuk konfigurasi IP: kita tidak memakai skrip up dan down, IP di setting manual melalui GUI. Cara testingnya sama:

 tincd -D -d4 -n jaringanku

Dan jika sudah OK, untuk membuat permanen (diinstall sebagai service).

 tincd -n jaringanku

Jika ingin merestart, mendisable, atau menghapus service ini, maka bisa dilakukan melalui GUI Services di Windows. Atau jika menguasai PowerShell ini juga bisa dilakukan via PowerShell

Berikutnya

Setting tinc yang saya jelaskan hanya supaya kedua host terkoneksi dengan ip internal. Setelah itu kita bisa mensetup banyak hal lain, tapi tidak akan dibahas di sini. Contohnya yang bisa disetting:

  • Jika kita ingin membagi koneksi internet server ke client (supaya client bisa browsing web dengan IP server seperti koneksi VPN pada umumnya) kita bisa memakai IP masquarading atau menginstall proxy server di server.
  • Jika kita ingin server di rumah kita diakses dari luar, kita bisa memakai DNAT (atau SSH remote port forwarding).

Sebagai penutup: mengetahui berbagai teknologi VPN bisa sangat berguna dan bisa dipakai untuk menyelesaikan masalah sesuai kebutuhan kita.

Apache Guacamole

Apache Guacamole adalah clientless remote desktop gateway. Atau mudahnya: jika kita menginstall ini di sebuah gateway (atau di server remote), kita bisa mengakses Windows (via RDP), Linux (via VNC), atau SSH ke manapun dengan menggunakan browser saja.

Saat ini saya masih memakai Mini PC Router yang dibeli sekitar 2 tahun lalu. Mini PC ini cukup powerful untuk menjalankan berbagai aplikasi (memorinya 4 GB, dengan SSD 120 GB) termasuk juga Apache Guacamole yang memakai Java. Meskipun dalam 99% kasus saya lebih suka memakai aplikasi SSH langsung, tapi Guacamole ini sangat berguna ketika butuh akses GUI.

Dengan chrome melakukan koneksi ke rumah, lalu menjalankan Firefox

Sebelum memakai Guacamole saya memakai Team Viewer, tapi dulu sempat ada kecurigaan bug di team viewer yang memungkinkan orang masuk ke komputer kita. Selain masalah bug itu, TeamViewer juga kadang error ketika melakukan remote connection ke Linux. Solusi berikutnya yang saya coba adalah SSH + Port forwarding plus remote desktop dan VNC viewer. Hal ini cukup merepotkan, jadi jarang saya lakukan.

Sekarang dengan browser saja saya bisa melakukan koneksi ke rumah via Guacamole ke server Windows dan juga Linux. Untuk Linux saya menggunakan beberapa VNCServer (di satu server) untuk tujuan tertentu. Misalnya ada satu VNCServer untuk pentesting (yang memakai OWASP ZAProxy dengan GUI).

Saya juga memasang guacamole di server dedicated di Eropa. Kadang download sesuatu lebih cepat dilakukan dari server di Eropa. Dalam 90% kasus biasanya download bisa dilakukan di command line, tapi ada website yang melakukan banyak proteksi sehingga sulit dilakukan.

Contoh proteksi downloadnya:

  • Hanya boleh ada 1 koneksi setiap waktu
  • Harus memakai Cookie dan Cookienya terikat pada IP tertentu (jadi ketika dicopy paste ke server, jadi tidak valid)
  • Harus memakai user agent tertentu (jadi jika memakai command line, user agent harus dicopy persis)
  • Download menggunakan Javascript dan file didekrip di level Javascript

Daripada menghabiskan waktu mengakali, yang saya lakukan adalah:

  • membuka guacamole
  • memilih koneksi VNC ke server di Eropa
  • menjalankan browser di dalam koneksi VNC
  • mendownload file via browser yang berjalan di cloud
  • mentransfer file dari server ke rumah

Sepertinya langkah tersebut merepotkan, tapi dalam kasus tertentu bisa menghemat waktu sangat banyak. Kadang download yang butuh 3 jam bisa dilakukan dalam 10 atau 15 menit.

Penjelasan DNS Flag Day

Tanggal 1 Februari nanti akan ada perubahan bersangkutan dengan DNS (Domain Name System). Secara singkat: berbagai domain yang terdaftar di berbagai DNS server yang tidak compliant dengan standar EDNS akan bermasalah sejak tanggal itu. Sebagai user: kemungkinan beberapa domain menjadi tidak bisa diakses sejak tanggal tersebut (atau beberapa hari/minggu setelahnya).

Sayangnya penjelasan singkat tersebuttidak cukup dan bikin penasaran banyak orang: sebenarnya apa sih yang akan terjadi? Saya coba cari sekilas belum ada penjelasan dalam bahasa Indonesia yang mudah dimengerti, jadi saya akan mencoba menjelaskannya di sini. Sebelum masuk ke penjelasan flag day ini, saya akan mulai dulu dengan penjelasan singkat tentang DNS dan sedikit sejarahnya karena ini ada hubungannya dengan masalah saat ini.

Apa itu DNS?

Pada Internet Protocol (IP) ketika sebuah program melakukan koneksi ke sebuah server berdasarkan nama, maka diperlukan proses translasi dari nama menjadi alamat IP. Proses translasi ini dulunya hanya memakai file teks (hosts.txt) ketika internet belum besar. Sampai sekarang pun ini masih didukung berbagai sistem operasi dengan file hosts.

Ketika jumlah domain makin banyak, maka diperlukan sistem baru. Mulai tahun 1983 sudah dibuat standar DNS (RFC 882 dan RFC 883), dan pada tahun 1984 software berdasarkan standar tersebut sudah mulai dibuat (namanya BIND). Kemudian pada tahun 1987 dibuat standar baru (RFC 1034 dan RFC 1035) menggantikan standar pertama.

Sebenarnya cara kerja DNS cukup sederhana: daripada semua nama dikelola satu pihak, biarlah dikelola masing-masing pihak dengan hierarki tertentu. Kenapa bentuknya hierarki seperti ini? Setiap level dari hierarki ini bisa diatur oleh sebuah otoritas untuk nama tersebut. Saya ambil contoh sebuah universitas ITB yang memiliki banyak jurusan.

  • Tiap jurusan bisa punya subdomain sendiri (misalnya if.itb.ac.id untuk informatika)
  • Tiap jurusan bisa memiliki DNS server sendiri, supaya bisa menambah/mengubah subdomainnya sendiri (tidak perlu repot lapor ke universitas)
  • Di level itb.ac.id perlu diset, bahwa NS record untuk if.itb.ac.id ditangani oleh server tertentu di jurusan informatika

Ini berlaku untuk semua domain, bukan hanya domain organisasi seperti itu. Ketika kita mencari apakah IP untuk sebuah domain blog.compactbyte.com, maka pertama yang dilakukan adalah:

  • Mencari tahu server mana yang menangani .com. Untuk pertanyaan paling atas ini bisa ditanyakan ke root name server (ada beberapa di dunia ini). Kita akan mendapatkan daftar server-server (bisa lebih dari satu) yang menangani domain .com
  • Kita bisa bertanya ke salah satu server tersebut: mana server yang menangani compactbyte.com?
  • Kita bisa bertanya ke server yang menangani compactbyte.com: apa alamat untuk blog.compactbyte.com

Proses di atas dinamakan resolving, dan proses selangkah demi selangkah dari titik atas itu disebut recursive resolving. Tentunya kalau saya membuat program, saya tidak akan menulis sendiri kode untuk melakukan resolving. Sudah ada library resolver yang akan melakukan semua proses di atas.

Server-server di atas memiliki daftar seluruh domain .com di dunia

Sebenarnya dalam dunia nyata, proses seperti itu tidak benar-benar dilakukan karena lambat, tiap kali ingin pergi ke facebook, harus mencari dulu di root server mana yang menangani .com, lalu mana yang menangani facebook.com dst. Dalam praktiknya: kalau sudah tahu nama domainnya, hasilnya akan dicache. Jadi setiap kali proses tidak perlu lagi bertanya ke root server untuk .com karena jawaban sudah dicache.

Supaya lebih efektif biasanya kita memakai sebuah server DNS publik. Ini biasanya dari ISP tapi bisa juga memakai milik Google (8.8.8.8), Cloudflare (1.1.1.1), dan masih banyak lagi. Ketika kita bertanya ke DNS milik ISP kita, maka biasanya jawaban bisa instan karena banyak orang mengakses situs yang sama dan jawabannya masih diingat (dicache). DNS server semacam ini disebut sebagai “caching server“.

Artikel di Wikipedia memberikan gambar yang lebih real mengenai proses ini. Ketika kita bertanya ke DNS milik ISP, maka server tersebut bisa bertanya ke server DNS lain, atau melakukan sendiri proses rekursif yang saya jelaskan di atas untuk mencari IP sebuah domain.


Di dalam server DNS, catatan pemetaan nama ke IP disimpan sebagai sebuah record. Tepatnya lagi ini disebut sebagai address record (singkatnya satu huruf: A). DNS juga memiliki berbagai record lain. Contoh record lain adalah mail exchanger (singkatnya MX) untuk mengetahui server mana yang digunakan untuk menangani email. Kenapa harus ada banyak record? karena kegunaannya berbeda-beda. Contohnya dengan adanya record MX yang terpisah dari record address (A) maka kita bisa punya email yang dihosting di server lain (misalnya Google) dan tidak harus di server kita sendiri.

Saya juga akan menjelaskan sedikit apa yang terjadi waktu kita membeli domain. Domain kita akan didaftarkan di server TLD. Lalu biasanya tempat kita membeli domain akan mengeset otomatis name server ke server milik registar tempat kita membeli. Ini bisa kita ubah agar memakai server lain, misalnya server sendiri atau Cloudflare

Blog ini memakai cloudflare

Beberapa hal yang perlu diketahui adalah:

  • Di dalam mesin (PC/Mobile) ada software resolver
  • Dalam server DNS juga ada resolver untuk bertanya pada server DNS lain
  • Software di berbagai server ini bisa berbeda (tidak hanya ada satu software server DNS, ada banyak, dan masing-masing ada banyak versi)
  • Satu server DNS bisa menangani banyak domain

Extension Mechanism for DNS (EDNS)

Spesifikasi awal DNS kurang fleksibel sedangkan diperlukan banyak fitur baru untuk DNS baik itu untuk meningkatkan performance maupun security. Contoh masalah performance: pada sistem DNS lama ukuran paket yang bisa ditransfer maksimum hanya 512 byte via UDP. Dalam hal security: sebuah DNS server bisa dibajak dengan relatif mudah karena tidak ada signature atau tanda tangan digital yang menyatakan bahwa record yang terdaftar adalah benar adanya.

Pada tahun 1999 diperkenalkanlah Extension Mechanism for DNS. Kemudian standar ini diperbaiki lagi tahun 2013. Jadi EDNS ini sudah dicetuskan 20 tahun yang lalu. Mekanisme EDNS ini backward compatible dengan DNS. Di atas EDNS ini dibangunlah berbagai teknologi baru seperti DNSSEC (Domain Name System Security Extensions).

Untuk mengetahui apakah sebuah server DNS kompatibel dengan EDNS, maka ini yang dilakukan:

  • Resolver akan menanyakan record OPT yang tidak dikenali oleh DNS server lama
  • Server lama (tidak mendukung EDNS) akan mengabaikan OPT, dan menjawab record yang bisa dijawab
  • Server yang baru (mendukung EDNS) akan menjawab bahwa OPT didukung

Sejak diciptakannya, DNS sudah menjadi sistem yang sangat kompleks, dengan 185 RFC yang total halamannya lebih dari 2000 halaman jika dicetak. Ini membuat detail DNS sulit dipahami, dan banyak orang tidak mau pusing memakai software baru yang mendukung berbagai fitur DNS, selama semuanya masih berjalan normal. Ini salah satu alasan kenapa orang tidak mengupdate semua ke server versi terbaru.

Masalah EDNS

Sekarang masalahnya adalah: ada server yang tidak menjawab jika ditanya dengan record OPT, atau jawabannya tidak benar (silakan lihat presentasi ini untuk berbagai jawaban yang salah). Sebenarnya yang diharapkan cuma ini:

  • Kalo kamu mendukung EDNS, jawab yang tegas dengan benar
  • Kalo kamu tidak mendukung EDNS, jawablah bahwa tidak mendukung EDNS

Banyak server yang jawabannya tidak jelas, atau bahkan tidak menjawab. Untuk mengatasi ini, resolver DNS harus bekerja ekstra (istilahnya untuk akal-akalan ini adalah workaround): Jika server ditanya dengan protokol EDNS dan menjawab dengan sempurna, maka diasumsikan server tersebut memang mendukung EDNS. Tapi jika ternyata tidak mendukung, maka ditunggu dulu sampai timeout, terus dicoba lagi ditanya pakai protokol DNS lama (dan kadang tidak menjawab juga, tunggu lagi sampai timeout).

Proses ini tentunya membuat lambat proses resolving. Karena sudah lama sekali standar ini diperkenalkan, maka diputuskan begini:

  • Mari kita stop workaroundnya: kalau jawaban server nggak standar, ya sudah ignore aja servernya (anggap sudah mati)
  • Mari kita buat internet lebih aman dengan mengadopsi standar baru

Kapan ini harus dilakukan? setelah dilihat bahwa sebagian besar (>90% server) sudah mendukung EDNS, maka diputuskan bahwa tanggal 1 Februari 2019 merupakan saat yang tepat. Berbagai DNS publik dunia akan menghentikan workaround yang dilakukan dan berbagai software yang tadinya mendukung workaround juga akan diupdate.

Flag Day

Kenapa namanya flag day? nama ini sifatnya historis. Dulu ada perubahan definisi ASCII di sistem operasi Multics yang dilakukan di Flag Day (hari bendera amerika). Sejak itu istilah ini digunakan untuk perubahan besar pada sistem komputer.

Seperti dijelaskan di atas: software resolver ini ada di device (PC/mobile) kita, dan juga ada di DNS publik seperti ISP dan Google). Biasanya resolver di mesin (komputer/ponsel) kita hanya akan bertanya ke caching server lain di ISP atau DNS publik lain.

Pada flag day, resolver publik yang besar (seperti Google, Quad9, CloudFlare) akan mematikan support untuk workaround. Server DNS untuk domain tertentu yang tidak menjawab dengan benar akan dianggap mati. Sebenarnya yang diharapkan bukan semua server harus support EDNS, tapi harus menjawab dengan jujur dan benar support atau tidak support. Jika kita memakai salah satu server DNS publik tersebut (baik langsung maupun tidak langsung), maka kita akan gagal mengakses domain-domain tertentu.

Untuk sementara waktu, ketika ISP belum mengupdate softwarenya, mungkin situs tersebut masih bisa diakses, tapi setelah beberapa waktu, berbagai ISP di dunia akan mengupdate server/resolver mereka dengan versi terbaru dan akhirnya domain-domain tersebut akan tidak bisa diakses sama sekali jika software DNS pada server yang tercantum di nama domain tidak diupdate.

Sebagai catatan: bukan pemilik domain yang harus mengupdate software, tapi pemilik server DNS yang dipakai di domain tersebut. Jadi misalnya Anda membeli domain dari sebuah registrar dan memakai nameserver registrar, maka registrar tersebut yang harus mengupdate software DNS-nya. Alternatif lain adalah: pemilik domain bisa memakai server DNS lain yang sudah memakai software DNS terbaru.

Selain perubahan di DNS publik, ada juga perubahan kode pada berbagai library resolver dan server DNS, misalnya BIND supaya mendrop workaround. Contoh realnya perubahan kode yang dilakukan di BIND bisa dilihat di URL ini:

https://gitlab.isc.org/isc-projects/bind9/commit/615ebc39e39abd06e97131339cb508a8651ac65c

Apakah domain saya akan baik-baik saja?

Domain yang Anda miliki bisa dicek di situs https://dnsflagday.net. Jika hasilnya OK, maka sudah aman. Jika hasilnya STOP, maka ini sangat berbahaya, dan jika hasilnya SLOW maka sebaiknya setting server diperbaiki atau versinya diupdate. Sebelum panik, cobalah testnya sekali lagi, karena jika server sedang sibuk, kadang hasilnya bisa salah. Jika mengerti penggunaan dig, maka sebaiknya cek juga secara manual dari jaringan yang dekat dengan server (misalnya jika server di Indonesia, cek dari ISP Indonesia).

Ketika hasilnya SLOW atau STOP akan muncul link yang menjelaskan masalah detail eksaknya untuk domain tersebut. Jika situs Anda cuma diakses puluhan atau ratusan orang, response “SLOW” mungkin tidak apa-apa, tapi jika situs Anda sangat ramai, ya sebaiknya diperbaiki.

Seperti yang sudah saya sebutkan sebelumnya, sebagai pemilik domain, yang bisa dilakukan adalah:

  • Pindah name server ke yang sudah mendukung software terbaru
  • Menghubungi pemilik server DNS untuk mengupdate softwarenya

Jika Anda sekedar pemakai sebuah situs, Anda bisa juga memeriksa situs tersebut dan memberi tahu adminnya, supaya dia bisa melakukan perubahan yang perlu. Ini terutama untuk situs yang kecil/kurang populer karena situs besar biasanya sudah menangani ini.

Penutup

Kadang masalah tertentu sulit dijelaskan tanpa mengetahui detail teknis, dan DNS Flag Day ini merupakan salah satu contohnya. Semoga artikel ini cukup bisa menjelaskan. Secara umum: tidak perlu panik. Para admin mungkin harus bekerja ekstra keras, tapi persiapan DNS Flag Day ini sudah cukup lama, jadi harapannya semua akan berjalan lancar pada tanggal yang ditentukan nanti.

Kisah sebuah bug kecil

Saya mau cerita tentang sebuah bug yang saya perbaiki dan dapat bounty 200 USD plus kerjaan ekstra yang menyusul dari ini. Meski secara nilai ini kecil dibandingkan banyak proyek lain, tapi ada banyak hal yang membuat gembira dari satu bug kecil ini sehingga ingin saya ceritakan.

Maaf, ini bukan cerita tentang serangga, tapi bug software

Cerita singkatnya: teman saya┬ámemakai software open source QZ, sebuah library untuk printing via web browser. Jadi jika client menginstall software ini di PC-nya maka web app yang memakai library QZ bisa mengakses langsung printer lokal. Langsung di sini artinya bisa mengirimkan kode mentah, sehingga printing bisa cepat dan mendukung berbagai fitur spesifik printer. Fitur semacam ini dibutuhkan untuk software Point Of Sales, aplikasi bank atau sejenisnya yang butuh langsung mencetak ke printer yang tidak standar (misalnya printer thermal, printer buku tabungan, dsb). Lanjutkan membaca “Kisah sebuah bug kecil”

SSH Tunneling dan Internet Gratis

Saat ini sepertinya semua developer sudah memakai SSH sehari-hari. Sebagian mungkin sudah mengenal beberapa fitur ekstra SSH, tapi kebanyakan tidak tahu fitur lengkapnya. Wajar saja sih, meski RFC untuk SSH ini singkat (terbagi dalam beberapa RFC), ada banyak fitur di luar RFC yang diimplementasikan oleh berbagai software SSH. Sampai-sampai ada beberapa buku yang khusus hanya membahas SSH saja.

Di tulisan ini, saya tidak akan membahas semua fitur SSH, hanya beberapa fitur yang menarik yang berhubungan dengan port forwarding, serta pembahasan bagaimana SSH ini bisa menjadi jalan untuk internet gratis atau tanpa restriksi.

Fitur paling dasar yang dikenal orang adalah login ke server lain, dan berikutnya mungkin melakukan scp atau sftp ke server lain untuk mentransfer file. Fitur menarik berikutnya adalah X11 forwarding yang untuk mengakses aplikasi GUI di server (unix) lain.
client-server

SSH mendukung multi channel dalam satu koneksi, dan ini bisa dimanfaatkan untuk TCP/IP forwarding (mengenai ini bisa dibaca di RFC 4254). Saya akan jelaskan beberapa kegunaan forwarding ini. Channel yang dibentuk oleh mekanisme forwarding ini disebut juga sebagai tunnel.

Lanjutkan membaca “SSH Tunneling dan Internet Gratis”