Pelatihan InHouse Mikrotik

Pelatihan Mikrotik

Pelatihan Mikrotik diadakan dengan titik berat penguasaan dan pemahaman terhadap Mikrotik RouterOS dan juga penggunaan perangkat-perangkat wireless Mikrotik Routerboard. Peserta pelatihan umumnya adalah orang-orang yang bekerja pada Internet Service Provider, ataupun pada perusahaan yang telah menggunakan jaringan, sehingga bisa melakukan pengaturan jaringan secara efektif.

Private Training / in-house Training

Kami juga dapat melakukan private training secara in-house di lokasi perusahaan yang diinginkan.

Untuk kebutuhan khusus, materi pelatihan dapat disesuaikan dengan kebutuhan perusahaan.

Materi Pelatihan :

  • Pengenalan Jaringan Dasar, IP Address dan Subneting
  • Pengenalan Mikrotik
  • DHCP
  • Bridging
  • Routing
  • Wireless
  • Firewall
  • QoS (Simple Queue Bandwidth management)
  • Tunnels (PPPoE, SSTP, PPTP)
  • Tools untuk analisa dan monitoring jaringan

Praktikum jaringan dasar Pelatihan dilakukan selama 3 hari penuh, pukul 09.00 – 17.00. Pada akhir pelatihan, akan diselenggarakan ujian sertifikasi. Peserta yang lulus akan mendapatkan sertifikat kelulusan yang diakui secara internasional, dengan predikat Mikrotik Certified Network Administrator (MTCNA).

Info Lebih Lanjut

Untuk informasi lebih lanjut, dapat menghubungi:

HarijantoPribadi, email: harijanto@gurumikrotik.com

WhatsApp : 081806727777

Dampak Covid19 terhadap traffic Internet di Indonesia

Sejak pertama kali ditemukan pasien positif covid19 pada awal maret 2020 di Indonesia berikut adalah trend grafik traffic Internet di Indonesia

Berdasarkan grafik MRTG/Cacti di ISP HTSNET untuk ip transit (global Internet)

Upstream #1
Upstream #2

Dapat disimpulkan terjadi penurunan traffic menuju IP Transit Internet global pada bulan maret 2020

Sedangkan untuk traffic domestik melalui beberapa Local Internet Exchange di ISP HTSNET

IIX – APJII
OIXP NICE IDC
CDIX
JKT-IX NTTI

Penurunan traffic juga terjadi pada port IIX-APJII, OIXP, CDIX dan JKT-IX pada bulan maret 2020

Sedangkan peningkatan terjadi pada port backhaul untuk layanan residensial/rumahan HomeAccess HTSNET

Backhaul layanan HomeAccess

Bisa disimpulkan gerakan Kerja Di Rumah / Work From Home , School From Home secara significant terjadi dan berdampak pada traffic layanan di perumahan yang masuk coverage area layanan HomeAccess dari HTSNET

Lalu bagaimana dengan total traffic di IIX dan OIXP? berikut grafiknya

IIX MLX_Cyber
IIX MLX_CSF
OIXP

Dapat disimpulkan relatif terjadi peningkatan traffic pada IIX karena adanya penambahan port 10G Telkomnet2 di IIX dan adanya bilateral peer ke Facebook melalui Switch IIX , sedangkan traffic pada OIXP relatif turun sedikit

Dari grafik traffic Internet baik global maupun lokal/domestik disimpulkan dengan adanya pandemi covid19 ini traffic Internet pelanggan perusahaan/corporate dan Hotel terjadi penurunan yang significant terutama Hotel karena industri pariwisata adalah salah satu industri yang kena dampak langsung dari pandemi covid19, ada informasi okupansi hotel saat ini drop sampai dengan dibawah 10% sehingga mengakibatkan 75% hotel di bali mengajukan putus berlangganan Internet untuk sementara waktu dan sisanya mengajukan downgrade, hal ini tentu sangat berdampak pada omzet perusahaan 500 Internet Service Provider (ISP) Anggota APJII di seluruh Indonesia, kecuali ISP yang punya basis layanan retail untuk perumahan/apartemen (residential) dan operator selular (3G/4G) seperti Telkomsel/XL-Axiata/Tree(3)/Indosat-Ooredoo/SmartFren yang mengalami peningkatan traffic Internet akibat pandemi covid19.

Juga di beritakan Pak Menteri KOMINFO menyarankan agar layanan Netflix dan Youtube menurunkan kualitas videonya selama masa panemi covid19 karena beban jaringan Internet menjadi sangat berat melayani traffic Work From Home dan School from Home, mungkin Pak Menteri lupa kalau Internet di Indonesia tidak hanya dilayani oleh satu atau dua ISP/Operator tetapi ada 500 lebih izin ISP yang telah diterbitkan , mengapa hal ini terjadi? karena saat ini hanya satu ISP dominan yang dapat melayani pelanggan rumahan di seluruh Indonesia, harusnya pemerintah ikut terlibat memfasilitasi agar 500 lebih ISP yang sudah memiliki izin penyelenggaraan di seluruh Indonesia dapat leluasa melayani pelanggan rumahan dengan biaya infrastruktur yang terjangkau dengan memanfaatkan infrastruktur yang ada dapat digunakan secara bersama atau dikenal dengan Open Access atau Open Virtual Mobile Network sehingga ketika terjadi Pandemi dan memaksa masyarakat untuk kerja di rumah beban traffic yang ada dapat terdistribusi ke 500 lebih jaringan inti (core network) dari 500 ISP di seluruh Indonesia sekaligus menghindari single point of failure yang pada akhirnya meningkatkan pertahanan cyber di NKRI.

Semoga pelajaran berharga dari pandemi covid19 bisa merubah pola berpikir pemerintah khususnya BUMN yang menguasai 70% lebih infrastruktur di Indonesia.

Training MTCNA/MTCRE/MTCSE 2020

Sehubungan dengan adanya pandemi global covid-19 yang juga telah menginveksi Indonesia maka training GuruMikrotik baru akan di buka di bulan April sesuai dengan himbauan pemerintah untuk melakukan Social Distancing selama 14 Hari dibulan Maret 2020

Pantau https://www.facebook.com/gurumikrotik/

dan website http://gurumikroitk/com

Gurumikrotik, Jalan Pos Pengumben No.20A Jakarta 11560, Tel: 021-53665477

Melindungi Router Border

Router border adalah router paling ujung yang terhubung dengan upstream, harusnya router ini tidak perlu dapat diakses dari global Internet

Agar Router Border terlindung dari serangan melalui interface upstream bisa dibuat firewall sbb:

di contoh ini In.Interface=e2-IXINET adalah interface yang digunakan untuk menghubungkan router swadaya dan hts sebagai upstream.

buat IP->Firewall->Filter Rules chain input sbb:

In.Interface = e2-IXINET artinya hanya koneksi ke router melalui Interface e2-IXINET yang di atur melalui Firewall Rule ini.

Src. Address List: htsnet-swadaya berisi blok ip hts dan swadaya yang di percaya untuk mengakses router ini.

Action : Accept , artinya koneksi ke In.Interface=e2-IXINET dari source address list : htsnet-swadaya di terima / di izinkan

Berikutnya buat IP->Firewall->Filter Rules chain input berikutnya


Tetap In.Interface: e2-IXINET

Action : Drop , dengan demikian maka semua akses ke router tsb akan di drop, sehingga router tidak bisa diakses maupun di monitor dari global Internet kecuali dari source address list : htsnet-swadaya sehingga relative lebih aman dari kemungkinan di scan dan di exploit oleh mallware/bot dll.

mengatur interface neighbor

sejak ROS versi 6.4x.x setingan /ip neighbor di mikrotik ada perubahan pada setingan Discovery Settings, yaitu hanya dapat memilih: all , dynamic dan none

jika pada Discovery Settings kita pilih “!” dynamic berarti semua interface yang “bukan”dynamic

all: berarti semua interface yang ada, dynamic: berarti semua interface dynamic seperti l2tp, pptp, pppoe, dan none: berarti tidak ada interface yang mengaktivkan neighbours discovery

lalu bagaimana caranya kalau kita hanya ingin mengaktivkan neighbor discovery pada interface yang menuju ke internal jaringan kita saja tanpa harus mengaktivkan protocol neighbor discovery ke arah upstream atau exchange? caranya dengan melakukan grouping interface melalui fitur interface list

contoh script diatas adalah cara membuat grouping interface yang digunakan untuk bgp peer ke exchange, dengan cara demikian kita bisa memanfaatkan interface list name=exchange untuk interface firewall maupun untuk neighbor discovery interface

Dengan Discovery Settings “!” exchange , berarti /ip neighbor hanya aktiv pada interface “Bukan” exhange sehingga protocol neighbor discovery tidak broadcast ke luar dari jaringan internal kita untuk lebih meningkatkan resiko keamanan Mikrotik yang kita gunakan

Bagaimana teknik dan cara mengamankan Mikrotik yang kita gunakan dari ancaman exploit dan hacker materi tersebut akan di dapatkan dari Workshop Training Mikrotik Certified Security Engineer (MTCSE), jika ada yang tertarik untuk mengikuti Workshop dan sertifikasi MTCSE bisa mengajukan In-House Training, informasi lebih lanjut baca di: http://gurumikrotik.com/wp/2019/09/24/pelatihan-inhouse-mikrotik/

Mikrotik Routing Workshop (MTCRE) IDNOG 2019

Bagi yang ingin ikut Trainig MTCRE pada 23-24 Juli bisa mendaftarkan diri di:
https://www.idnog.or.id/id/workshop/9

Memberikan pengetahuan menyeluruh dan pelatihan langsung menggunakan MikroTik RouterOS untuk routing basic dan advance di jaringan kecil menengah , Setelah menyelesaikan kursus, Anda akan dapat merencanakan, menerapkan, menyesuaikan, dan men-debug Konfigurasi jaringan menggunakan MikroTik RouterOS.

Garis Besar Kursus MTCRE:

Simple routing: Distance, Policy Routing, ECMP, Scope, Dead-End and Recursive Next-Hop Resolving
OSPF : Areas, Costs, Virtual links, Route Redistribution and Aggregation Routing and point-to-point interface: VLAN, IPIP, EOIP,point-to-point addressing

Persyaratan: Peserta harus sudah memiliki sertifikat MTCNA.

Ujian online di hari terakhir untuk mendapatkan sertifikat MTCRE.

Biaya sudah termasuk RB941 Hap Lite dan peserta dapat mengikuti sebagai peserta IDNOG Conference 2019

Taktik membedakan limiter bandwidth IX dan IIX pada koneksi vpn l2tp

mungkin terasa aneh dan gak ada kerjaan ngapain membedakan limiter IX (Internet eXchange : global Internet) dan IIX (Indonesia Internet eXchange: domestic Internet) di koneksi vpn l2tp? sepertinya hal ini kurang ber faedah ya?…..

Eit… nanti dulu… bukan Indonesia namanya kalau tidak kreatif , aselinya penduduk Indonesia itu kreatif dan pinter-pinter

Jadi gini demi untuk bisa menggunakan IP Public milik ISP Induk maka para RtRwNet berusaha untuk mengikuti regulasi yang ada dimana salah satu pilihannya adalah menjadi reseller ISP yang punya izin penyelenggaraan KOMINFO , nah jika RtRwNet tersebut jadi reseller ISP maka diharuskan menggunakan Nomor IP dari blok Nomor IP ISP induknya. Sebenarnya untuk bisa menggunakan nomor IP dari ISP Induk itu mudah, tinggal berlangganan intercity dari salah satu Penyelenggara Jaringan Tertutup seperti PT. Icon, PT. Telkom, PT. Moratel dkk untuk menghubungkan jaringan distribusi RtRwNet di daerah ke Core Network ISP Induk yang menurut saya 90% pasti di colocation di Gedung Cyber jakarta atau di PT. IDC Duren Tiga Jakarta, yang tidak mudah adalah bagaimana caranya membayar biaya intercity 100mbps seharga Rp. 10.000.000 sd Rp. 20.000.000 perbulannya (asumsi jawa-bali) sedangkan sudah terbiasa cukup membayar Rp. 1.890.000 saja sudah dapat Indihome 100mbps….

Nah di tengah kegalauan itu vpn l2tp menjadi salah satu pertolongan pertama agar para RtRwNet reseller ISP yang tersebar di pelosok nusantara untuk sementara waktu bisa terhubung langsung ke Core Network ISP Induk secara virtual menggunakan teknologi vpn l2tp, kenapa harus l2tp ? kenapa tidak pptp? karena beberapa provider misalnya Telkomsel terbukti memblokir pptp juga ada beberapa ISP besar yang di laporkan tidak mengijinkan koneksi PPTP melalui jaringan mereka, sedangkan l2tp relatif tidak mengalami kesulitan digunakan di beberapa provider yang ada.

pertanyaannya kenapa harus dibedakan antara IX dan IIX nya? ya karena RtRwNet Reseller ISP blom sanggup utk sewa IX yang besar, misalnya hanya sewa IX 2Mbps dan IIX nya minta di loss bandwidth sesuai kapasitas link Indihome yang ada, karena umumnya ISP Induk tidak menghitung lagi biaya IIX tetapi hanya menagih besarnya IX yang di sewa.

Ok sudah cukup intermezonya sekarang saya akan mulai memaparkan apa saja TakTik yang saya lakukan

Aktivkan L2TP Server di Mikrotik ISP Induk dengan cara: Klik PPP->L2TP Server dan ceklist Enable, Use IPsec : Yes , IPsec Secret : ispnet (misalnya)

Buat PPP Profile

Rate Limit (rx/tx) 10M/10M , ini fungsinya membatasi koneksi vpn l2tp tidak boleh lebih dari 10Mbps , jadi ini adalah kapasitas pipa vpn nya

Nah di bagian Scripts kita bisa isi script yang akan dijalankan pada saat terjadi koneksi Up dan script yang akan dijalankan pada saat terjadi koneksi Down. pada contoh ini saya menjalankan scripts yang bertujuan menambahkan /queue tree dengan parent interface=<l2tp-reseller> , jika koneksi vpn l2tp bermasalah sampai interfacenya down maka queue-tree harus di remove

Buat secret ppp yang berisi name, password, profile, Local Address, Remote Address dll

Selanjutnya menyiapkan address-list yang berisi IP apa saja yang digunakan oleh reseller

Buat Mangle untuk mendandai connection dan packet yang in dan out dari ether1 , karena ether1 adalah interface yang digunakan untuk koneksi ke dan dari IX (biasa di sebut juga upstream)

/ip firewall mangle \ add action=mark-connection chain=prerouting comment=reseller \
dst-address-list=reseller in-interface=ether1 \
new-connection-mark=reseller-dl-con passthrough=yes
add action=mark-packet chain=prerouting connection-mark=\
reseller-dl-con new-packet-mark=reseller-dl-packet passthrough=\
no
add action=mark-connection chain=postrouting new-connection-mark=\
reseller-ul-con out-interface=ether1 passthrough=yes \
src-address-list=reseller
add action=mark-packet chain=postrouting connection-mark=\
reseller-ul-con new-packet-mark=reseller-ul-packet passthrough=\
no

Queue Tree digunakan untuk membatasi bandwidth IX dari koneks vpn l2tp reseller , caranya buat Queue Tree untuk membatasi bandwidth Upload dari packet-packet yang telah di mangle sebagai paket data IX, nah untuk membatasi bandwidth Upload digunakan parent=ether1 karena ether1 adalah interface yang terhubung ke upstream IX sedangkan untuk membatasi bandwidth Download nanti baru akan di buat oleh scritps ketika koneksi vpn l2tp nya sudah Running , karena untuk membatasi Download parent nya harus interface <l2tp-reseller> sebagai interface yang terhubung langsung ke sisi router reseller di daerah. Kendalanya interface <l2tp-reseller> adalah interface dynamic yang akan hilang ketika koneksi L2TP nya tidak running.

adapun scripts untuk menambahkan Queue Tree setelah L2TP nya running bisa dilihat di gambar berikut

Ok sudah siap semua tinggal di uji coba… eit lalu utk limitasi IIX nya mana? oh iya… gini untuk limitasi IIX akan otomatis akan dibuat Dynamic Simple Qeueu sesuai dengan limit yang ada di PPP Profile

Status Interface <l2tp-reseller>

Hasil SpeedTest ke Biznet => IIX



Hasil Speedtest Ke Singtel => IX

Akhirnya TakTik (Akal-Akalan) untuk memisahkan Limiter IIX dan Limiter IX pada sebuah koneksi vpn l2tp dapat di buktikan berhasil , tentunya proses mangle connection dan packet IX mensyarakatkan adanya satu interface khusus untuk koneksi ke Upstream IX yang dalam contoh kasus saya adalah ether1 , sedangkan connection dan packet IIX nya tidak perlu di mangle karena sudah cukup di limit di simple queue sesuai PPP Profile.

Semoga Artikel ini bermanfaat bagi yang memerlukannya

Masih relevankah menggunakan HTTP Accelerator?

19 tahun yang lalu saya masih berkutat dengan squid.conf untuk mengoptimalkan koneksi Internet 64Kbps 1:4 demi menghidupkan 4 lab komputer dengan jumlah PC 20 sd 30 PC per Lab di sebuah perguruan tinggi swasta di Cirebon menggunakan Squid Web Proxy di tambah Dansguardian yang di jalankan di Server Linux , waktu itu belum ada facebook, youtube, Bigo dkk. situs detik dll masih nyaman di akses melalui http, berbeda jauh dengan kondisi saat ini dimana aplikasi Internet umumnya sangat menuntut datarate yang besar, saat ini untuk satu gadget saja minimal butuh 2mbps jika ingin youtube tidak buffering dan semua aplikasi berjalan dengan lancar.

Saat ini di era ecommerce/marketplace dan internet banking mayoritas telah menggunakan HTTPSecure yang menyulitkan untuk di cache seperti pada HTTP.

Kemarin saya chat dengan salah satu vendor alat yang fungsinya kurang lebih sebagai HTTP accelerator dan tidak untuk meng cache youtube, facebook dkk. Lalu mengklaim dari 1Gbps traffic Internet alatnya mampu menghemat sampai dengan 300mbps dan ybs menyampaikan untuk HTTPS tidak mungkin bisa di cache… ada benarnya karena untuk koneksi HTTPS diperlukan sertifikat SSL yang masing-masing situs berbeda dan ada expire datenya.

Oleh karena itu saya penasaran mau tau berapa besar sih traffic HTTP vs HTTPS di real traffic yang ada saat ini. jadi saya coba untuk menandai packet http dan https lalu saya buat graffic nya agar dapat diketahui utilisasi antara HTTP dan HTTPS dari pelanggan yang ada di beberapa router distribusi

adapun cara menandai (mark-packet) di router distribusi nya bisa di lihat pada script berikut ini:

/ip firewall mangle
add action=mark-connection chain=forward dst-port=80 \
new-connection-mark=http-con passthrough=yes protocol=tcp
add action=mark-connection chain=forward dst-port=80 \
new-connection-mark=http-con passthrough=yes protocol=udp
add action=mark-packet chain=forward connection-mark=http-con \
new-packet-mark=http-packet passthrough=no
add action=mark-connection chain=forward dst-port=443 \
new-connection-mark=https-con passthrough=yes protocol=tcp
add action=mark-connection chain=forward dst-port=443 \
new-connection-mark=https-con passthrough=yes protocol=udp
add action=mark-packet chain=forward connection-mark=https-con \
new-packet-mark=https-packet passthrough=no

lalu buat simple queue dan gunakan mark-packet yang telah dibuat pada /ip firewal mangle

/queue simple
add name=http-traffic packet-marks=http-packet \
queue=ethernet-default/ethernet-default target=""
add name=https-traffic packet-marks=https-packet \
queue=ethernet-default/ethernet-default target=""

Kemudian menggunakan tools graphing untuk membuat grafik utilisasi dari simple queue yang telah dibuat

/tool graphing queue
add simple-queue=http-traffic
add simple-queue=https-traffic

dan hasilnya dari tiga router distribusi yang ada diperoleh hasil sbb:

Dari Router distribusi #1: HTTP max in 128,27Mb, HTTPS max in 589,54Mb

Dari router distribusi #2 : HTTP max in 86,78Mb, HTTPS max in 427,60Mb

Dari router distribusi #3 : HTTP max in 38,49Mb, HTTPS max in 199,58Mb

Dari ke tiga router distribusi jika di jumlahkan maka total HTTP max in = 253,54Mb , HTTPS max in = 1.189,31Mb (1,2Gb) dari hasil monitoring beberapa jam di tiga router distribusi sepertinya sulit untuk bisa menghemat 300Mb dari 1Gb atau setara dengan 30% penghematan menggunakan HTTP Accelerator / Web Caching karena total traffic HTTP faktanya tinggal 17.57% (253,54Mb/(253,54Mb+1.189,31Mb)) dari total gabungan HTTP+HTTPS = 1.442,85Mb (1,4Gb)

Dengan melihat real traffic pelanggan dari ketiga router distribusi tersebut, saya simpulkan di jaman Internet Broadband yang didukung teknologi lastmile fiberoptic, LTE dan 5G maka pemanfaaatan web-cache/proxy seperti squid dkk sudah tidak relevan lagi, alih-alih menghemat datarate yang terjadi malah bottleneck atau bahkan singlepoint of failure.

Bagi pembaca yang tertarik mengikuti training Mikrotik dasar MTCNA dengan Trainer Harijanto Pribadi silahkan isi data diri dan memilih jadwal melalui Formulir Online

Mikrotik Tools Packet Sniffer untuk mencari sumber pengirim ddos

masih ingat kasus DDoS yang saya ceritakan beberapa hari yang lalu? ternyata masih belum redah juga.

Akhirnya saya coba menggunakan “/tools packet sniffer” yang ada di Mikrotik

caranya /tools sniffer dan setting pada bagian general ceklist Only Headers dan Memory Scoll , tentukan File Name , misalnya kasih nama ddos1, File Limit biarkan defaultnya 1000

di bagian Filter pilih Interface yang akan di sniff, dalam contoh kasus saya akan menjalankan sniffer di vlan927, direction any (tx/rx) lalu klik Start ketika traffic flood terdeteksi di interface vlan927

ketika traffic flood di vlan927 terjadi dan Packet Sniffer running maka informasi packet sniffer akan di simpan di file ddos1

bisa di cek di menu File terdapat ddos1 dengan ukuran 1000KB , file ini harus di download ke notebook/komputer kita untuk selanjutnya di analisa menggunakan aplikasi WireShark, cara mendownloadnya cukup aktivkan service ftp di mikrotik dimana kita menjalakan Packet Sniffer.

Setelah di download kita bisa open file ddos1 menggunakan aplikasi WireShark

Hasilnya saya mendapatkan Mac-Address sumber Src: Vmware_a1:d8:04 (00:50:56:a1:d8:04)

Ternyata Mac Address tersebut digunakan oleh vm-webserver-1

Langkah selanjutnya saya mengisolir Network dari vm-webserver-1 tersebut untuk selanjutnya dilakukan pembersihan mallware/trojan di vmware tersebut.

dan hasilnya flood/ddos tersebut sudah redah, dengan demikian kita bisa memanfaatkan tools packet sniffer di mikrotik untuk melakukan analisa packet dan hasilnya bisa di analisa menggunakan aplikasi WireShark