Pi4 di rumah dijadwalkan restart setiap jam 6 pagi untuk recover hdmi display & semua port USB yang dimatikan malam harinya. Beberapa kali hal ini menimbulkan masalah dimana dns query seperti stuck, Pihole tidak merespon otomatis melainkan harus di trigger manual dulu via cli.
Browsing di Internet, kemungkinan besar hal ini karena pihole dns dijalankan ketika interface/network belum siap (Pi4 di rumah menggunakan wifi), sehingga solusinya adalah dengan implementasi delay startup (utk Pihole v5 ke atas), DELAY_STARTUP, pada file /etc/pihole/pihole-FTL.conf. Saya buat pihole dns untuk delay selama 60 detik sbb.
Beberapa hari kemarin di WAG alumni sekilas berdiskusi soal DNS server untuk rumahan (kegunaanya seperti yang saya tulis di artikel sebelumnya). Ada satu topik tentang aplikasi mana yang dipilih, antara pihole dan Adguard (menurut saya sebenarnya ada satu kandidat lagi nextdns). Ada rekan yang memilih Adguard karena lebih sederhana ketika membutuhkan DoH/DoT. Memang dengan Pihole, ketika membutuhkan DoH/DoT harus menambahkan resolver tambahan misal menggunakan Unbound. Sementara di Adguard fitur ini sudah built-in.
Ada rekan lain yang punya pengalaman jelek ketika menggunakan Pihole, yaitu respon DNS yang lama.. sehingga ingin mengganti ke Adguard. Saya jadi penasaran kira-kira secara performansi, dalam hal ini repsonse time, mana yang lebih baik ya ? Mustinya sih gak terlalu jauh bedanya..
Biar tidak penasaran langsung saya coba untuk deploy Adguard (untung ada teknologi container, hitungan menit siap pakai !) jadi ingat jaman dulu kala untuk install DNS server musti pakai ribet, mana sempat buat bapak rumah tangga macam saya.
Untuk test cepat ini saya menggunakan dua mekanisme sederhana :
command line ‘time’ dan dig, ini sekaligus bisa memperlihatkan CPU response time
dig response time (spesifik DNS response time)
Saya deploy Adguard via Docker dengan setup sederhana, IP yang sama tapi listen di port yang berbeda (tidak pakai macvlan) karena hanya untuk kebutuhan test sesaat.
pi@raspberrypi:~ $ sudo docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
aa33afc14548 adguard/adguardhome "/opt/adguardhome/Ad…" 46 hours ago Up 2 hours 0.0.0.0:3000->3000/tcp, 0.0.0.0:5352->53/tcp, 0.0.0.0:5553->53/udp, 0.0.0.0:6767->67/udp, 0.0.0.0:6868->68/tcp, 0.0.0.0:6868->68/udp, 0.0.0.0:8080->80/tcp, 0.0.0.0:4443->443/tcp, 0.0.0.0:8853->853/tcp adguardhome
Pihole+Unbound listen di port 53, DoH/DoT upstream menggunakan Google (8.8.8.8) sedangkan Adguard di port 5553, DoH/DoT upstream menggunakan default (9.9.9.9)
Pihole berjalan sebagai aplikasi standar di host (karena memang kami sudah menggunakan Pihole sehari2), sedangkan Adguard sebagai container. Ini tentu akan berkontribusi ke response time sebenarnya, tapi untuk saat ini kita abaikan.
Test 1 – Dua query DNS (mewakili non-cache & cached) dan diukur dengan time
#Pihole 1st try - non-cache
pi@raspberrypi:~ $ time dig -u wordpress.com @127.0.0.1 -p 53
...
;; Query time: 123840 usec <--
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Aug 16 13:27:46 WIB 2020
;; MSG SIZE rcvd: 74
real 0m0.190s <--
user 0m0.023s
sys 0m0.045s
#Pihole 2nd try - cached
pi@raspberrypi:~ $ time dig -u wordpress.com @127.0.0.1 -p 53
...
;; Query time: 468 usec <--
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Aug 16 13:27:50 WIB 2020
;; MSG SIZE rcvd: 74
real 0m0.078s <--
user 0m0.038s
sys 0m0.040s
#Adguard, 1st try
pi@raspberrypi:~ $ time dig -u wordpress.com @127.0.0.1 -p 5553
...
;; Query time: 354242 usec <---
;; SERVER: 127.0.0.1#5553(127.0.0.1)
;; WHEN: Sun Aug 16 13:27:59 WIB 2020
;; MSG SIZE rcvd: 74
real 0m0.425s <---
user 0m0.048s
sys 0m0.023s
#Adguard, 2nd try
pi@raspberrypi:~ $ time dig -u wordpress.com @127.0.0.1 -p 5553
...
;; Query time: 2070 usec <--
;; SERVER: 127.0.0.1#5553(127.0.0.1)
;; WHEN: Sun Aug 16 13:28:02 WIB 2020
;; MSG SIZE rcvd: 63
real 0m0.079s <---
user 0m0.048s
sys 0m0.031s
Sekilas dari test sederhana tadi, hasilnya signifikan jika tidak memfaktorkan Adguard yang berjalan di container dimana terlihat Pihole lebih cepat daripada Adguard. Tapi bila dilihat di waktu ‘real’ cpu hasil dari CLI ‘time’ maka hasilnya cukup mirip .078s vs 0.079s (berbeda ~ 1 milidetik)
Test 2 – Test query 10 random domain, data diamati setelah stabil (cached)
Test yang kedua saya coba query random DNS sebanyak 10 buah, yang bisa diambil dari:
Dari data query 10 random domain tadi, juga terlihat Pihole hasilnya lebih bagus (~ 250 mikrodetik) daripada Adguard ( ~ 1 milidetik). Hmm… mustinya tidak sejuah itu ya… tapi sekali ada 2 hal yang belum difaktorkan yaitu applikasi native vs container dan 8.8.8.8 vs 9.9.9.9. Nanti kalau ada waktu coba ditest lagi dengan environment yang lebih ekuivalen…
Akhirnya controller xbox 360 sampai juga di rumah. Dan plug N play di Pi4 4B (Pi OS Buster), tanpa perlu install driver apapun. yea…
pi@raspberrypi:~ $ lsusb | grep -i xbox
Bus 001 Device 003: ID 045e:028e Microsoft Corp. Xbox360 Controller
Di redream juga langsung dikenali sebagai Xbox360 Controller, jadi tidak perlu adjust key binding lagi untuk main game SEGA. (sambil berkaca-kaca… LOL) … Jaman masih anak2 dulu, karena kondisi ekonomi tidak sanggup membeli SEGA Dreamcast…
Hanya saja, dengan adanya stik xbox ini, ternyata option uhubctl nya perlu dirubah :
#mematikan port usb
#sudo /home/pi/uhubctl/uhubctl -l 1-1 -a 0 #harus diganti menjadi
sudo /home/pi/uhubctl/uhubctl -l 1-1 -p 4 -a 0
Jika tidak diganti hub usb akan menyala lagi setelah beberapa saat.
*Stik yang saya beli kualitas “ori pabrik”, 100 ribuan. Yang original MS Xbox mustinya pasti bisa juga…
Kemarin ramai di pemberitaan bahwa Internet via Indihome mengalami gangguan massal. Kami sendiri di rumah juga menggunakan Indihome tapi saya tidak merasakan dampak yg signifikan, hanya sempat lambat beberapa saja (hitungan menit). Membaca penjelasan dari Telkom terkait masalah ini bahwa salah satu penyebabnya adalah adanya gangguan pada DNS (Domain Name System) server, alias buku alamatnya Internet. Ooo.. pantes! Saya jadi paham kemungkinan kenapa di rumah tidak terdampak.
Di rumah kami menggunakan DNS server kami sendiri! (server ini dijalankan di komputer anak berbasis Raspberry Pi4)
Memang salah satu dari berbagai alasan menggunakan DNS server sendiri adalah untuk menghindari ketergantungan dengan provider. Dengan memiliki DNS server sendiri, kontrol ada di tangan kita sendiri. Beberapa alasan yang lain adalah sbb:
Internet yang lebih aman untuk keluarga dengan memblokir iklan, konten berbahaya, tracking, mining dsb. Di Indonesia DNS milik provider sebenarnya sudah menyediakan filter (mandat dari pemerintah), tapi hanya fokus untuk konten berbahaya (internet positif, filter konten2 yang termasuk negatif). Secara bisnis memang tidak ada justifikasi bagi provider untuk melakukan blokir tambahan misal untuk iklan, tracking dll, malah merugikan bisnis provider sendiri pastinya :).
Perlindungan otomatis (via setting DHCP) untuk semua perangkat Internet di rumah (termasuk smarthome kami seperti CCTV, lampu, vaccum cleaner dan mesin cuci) yang mana tidak memungkinkan untuk setting satu per satu.
Menghindari filter DNS provider yang tidak perlu (untuk beberapa site yang saya masih membutuhkan, misal Reddit, karena tidak semua sub forum reddit itu tidak baik kok!)
Iseng, butuh menyalurkan hobi yang lama tidak tersalurkan :D
Berikut ilustrasi 3 model Internet dan trafik DNS nya.
Internet dari Indihome diilustrasikan oleh model nomer 2 dimana Telkom DNS server tidak hanya melakukan filtering berdasarkan nama domain, melainkan Telkom juga melakukan spoofing IP DNS server populer (misal 1.1.1.1) dengan melakukan redirection atau spoofing atau ‘route poisoning’ dimana ada alamat IP yg sama (atau mengaku-ngaku sama) dari DNS server populer itu di jaringan internal Telkom. Sehingga ketika pelanggan mencoba menggunakan DNS server lain tersebut maka tetap akan direspon oleh DNS server internal Telkom, karena trafik trafik sudah redirected/spoofed. Dari sisi keamanan, sebenarnya ini tidak sesuai dengan prinsip transparansi Internet dan merupakan bentuk MITM (Man In The Middle) attack tapi bedanya ini dilakukan dengan niat ‘baik’ dan sesuai peraturan pemerintah :).
Di rumah kami menggunakan model nomer 3 dimana trafik DNS dienkripsi menggunakan HTTPS atau TLS (dikenal sebagai DNS over HTPPS/TLS, DoH/DoT) sehingga trafik DNS kami akan tetap direspon oleh server upstream yang digunakan. Note: untuk melakukan DoH/DoT ini sebenarnya juga tidak butuh install DNS server, melainkan juga bisa dilakukan di level host atau bahkan browser. Tapi ya jadinya harus dilakukan satu-persatu di setiap perangkat, yang mana tidak memungkinkan (misal perangkat rumah tangga pintar macam CCTV, lampu pintar dll.)
Bisa kita buktikan dengan mencoba melakukan tracing path untuk trafik DNS (UDP port 53).
#trafik standar
raspberrypi:~ $ traceroute 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
1 192.168.1.1 (192.168.1.1) 2.196 ms 3.192 ms 3.239 ms
2 10.44.abc.x (10.44.abc.x) 16.780 ms 18.580 ms 18.135 ms
3 125.160.1.197 (125.160.1.197) 11.823 ms 12.186 ms 11.234 ms
4 180.252.3.241 (180.252.3.241) 11.996 ms 11.904 ms 11.810 ms
5 180.240.190.194 (180.240.190.194) 36.346 ms 33.346 ms 34.027 ms
6 180.240.190.193 (180.240.190.193) 32.414 ms 33.934 ms 31.927 ms <-- Telkom/Telin
7 180.240.205.82 (180.240.205.82) 380.416 ms * * <-- Telkom/Telin
8 162.158.160.248 (162.158.160.248) 34.430 ms 34.395 ms 32.104 ms <-- Cloudflare
9 one.one.one.one (1.1.1.1) 35.002 ms 29.921 ms 32.241 ms <-- Cloudflare
#trafik DNS UDP port 53
raspberrypi:~ $ sudo /usr/sbin/tcptraceroute 1.1.1.1 53
Running:
traceroute -T -O info -p 53 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
1 192.168.1.1 (192.168.1.1) 2.022 ms 2.024 ms 2.030 ms
2 36.80.224.x (36.80.224.x) 15.863 ms 17.376 ms 17.204 ms
3 125.160.1.197 (125.160.1.197) 19.228 ms 18.412 ms 19.245 ms
4 180.252.3.241 (180.252.3.241) 10.909 ms 9.144 ms 8.624 ms
5 180.240.190.194 (180.240.190.194) 34.588 ms 34.589 ms 31.895 ms
6 180.240.190.193 (180.240.190.193) 34.658 ms 29.738 ms 31.252 ms <-- Telkom/Telin
7 one.one.one.one (1.1.1.1) <syn,ack> 27.429 ms 28.095 ms 29.579 ms <-- Telkom/Telin
*Hasil whois untuk mengetahui kepemilikan alamat IP:
ARUSIAWA-M-86AF:~ arusiawa$ whois -S 180.240.190.193 | grep -i netname
netname: TELIN-NET-SG
ARUSIAWA-M-86AF:~ arusiawa$ whois -S 180.240.205.82 | grep -i netname
netname: TELIN-NET-SG
ARUSIAWA-M-86AF:~ arusiawa$ whois -S 162.158.160.248 | grep -i netname
NetName: CLOUDFLARENET
Membandingkan 2 hasil diatas bisa dilihat bahwa trafik DNS menuju 1.1.1.1 (Cloudflare) dibelokkan ke alamat 1.1.1.1 internal Telkom (atau spoofing, direspon oleh alamat IP lain tapi seakan2 dari 1.1.1.1). Karena contoh untuk trafik yang bukan DNS bisa sampai ke alamat 1.1.1.1 yang legitimate maka metode selective redirection (port, protocol) lah yang dipakai di Indihome. Jika lebih detail mengamati ketika proses traceroute untuk UDP port 53, maka akan juga bisa dilihat bahwa setelah hop 125.160.1.197, akan menunggu beberapa waktu (seperti akan timed-out).. maka kemungkinan proses redirection nya dimulai disini (bisa jadi ada inspection juga specific untuk UDP port 53)
Bedtime thought:
Filtering dengan DPI (deep packet inspection) mahal jadi memang tidak cocok dipakai untuk skala kapasitas yang besar, dan juga tidak efektif untuk trafik yang terenkripsi (misal https). Filtering berdasarkan DNS adalah yang paling murah, tapi juga banyak ‘workaround’ atau jalan tikusnya, salah satunya yang dibahas di atas :D
Saya kepikiran mungkin ada cara yang efisien tapi tetap murah dengan menggunakan kombinasi DNS, BGP Flowspec dan automation. Prinsipnya adalah: selain DNS provider malakukan filtering, server juga akan melakukan komunikasi dengan BGP Flowspec server untuk melakukan update blokir IP (berdasarkan informasi DNS) dan BGP Flowspec policy ini bisa melakukan enforcement ke router gateway Internet atau router lain (misal BNG/BRAS) untuk melakukan IP filtering. Kalau alamat IP nya sudah diblok, mau pakai DoH/DoT ya percuma…. Atau malah jangan diblok langsung tapi dicekik bandwidth nya (BGP Flowspec memungkinkan ini) sehingga yang pengin akses konten itu jadi frustasi sendiri .. hahaha
*sekedar kepikiran, butuh proof of concept untuk membuktikan feasibility nya…
Disclaimer: Saya sedang dan pernah bekerja dengan PT Telkom Indonesia sebagai pelanggan saya, namun lingkup pekerjaan saya tidak pernah di area layanan akses Indihome ataupun server yang digunakan di Indihome dan selalu berkomitmen terhadap NDA. Artikel ini juga dibuat dan ditulis murni dari sudut pandang saya sebagai pelanggan Indihome dan informasi diatas bisa diperoleh semua orang tanpa insider knowledge. Saya juga mengoleksi TLKM, jadi tidak mungkin ada niat untuk menjatuhkan nama baik TLKM (dan artikel diatas memang murni teknikal).
Kemampuan Teknologi Informasi yang dimiliki oleh para guru berbeda-beda. Mayoritas guru yang sudah sepuh atau senior tidak memiliki kemampuan yang cukup untuk bisa kreatif dalam membantu siswa belajar dari rumah. Alhasil rata-rata hanya menggunakan group Whatsapp sebagai sarana pembelajaran. Maka PC yang digunakan oleh anak untuk sarana sekolah dari rumah haruslah bisa digunakan untuk mengakses Whatsapp. Kami tidak mengijinkan anak untuk memegang HP ketika jam sekolah di rumah.
Cara akses paling gampang untuk Whatsapp di PC adalah melalui browser. Browser default dari Pi OS menggunakan Chromium yang versinya tidak disupport lagi oleh Whatsapp web. Solusinya adalah dengan melakukan instalasi browser Firefox (versi ESR) sebagai berikut:
sudo apt update
sudo apt install firefox-esr
Jika mengalami masalah konektivitas ke repository maka bisa download dan menginstal secara manual. Saya menggunakan versi 68.11
Rusiawan Asli Klaten 