Pendaftaran Training Mikrotik dasar MTCNA

PT. Dinamika Cipta Solusi (DCS) bekerja sama dengan dengan Mikrotik mengadakan pelatihan Mikrotik RouterOS dan Wireless, pelatihan ini bertujuan memberikan pengenalan dasar-dasar jaringan Internet (TCP/IP) menggunnakan perangkat Mikrotik Routerboard, peserta training akan memperoleh wawasan dan praktek langsung menggunakan fungsi-fungsi dasar RouterOS termasuk bagaimana mengkonfigurasi Mikrotik RouterOS sebagai server PPPoE, PPTP,L2TP,SSTP.

Pada setiap materi, akan diadakan praktek langsung menggunakan routerboard Mikrotik, untuk mencoba fitur-fitur yang sedang dibahas.
Pada akhir masa training akan diadakan ujian resmi dari Mikrotik.com, peserta yang lulus akan mendapatkan sertifikat dengan gelar MTCNA (Mikrotik Certified Network Associate)

Materi yang akan diberikan pada pelatihan ini meliputi:
• Pengenalan Mikrotik
• DHCP
• Bridging
• Routing
• Wireless
• Firewall
• QoS (simple queue bandwidth management)
• Tunnels (PPPoE, SSTP, PPTP) , contoh kasus penerapan PPPoE Server untuk ISP secara sederhana
• Tools untuk analisa dan monitoring jaringan

Fasilitas yang akan didapatkan oleh peserta:

  1. Makan siang setiap hari pelatihan
  2. Coffee Break pagi dan sore
  3. Ujian Resmi dari Mikrotik.com
  4. Sertifikat (jika lulus ujian)
  5. Gratis 1 buah Router Indoor
  6. Materi pelatihan
  7. Router Mikrotik untuk latihan, 1 router per peserta

Biaya Rp. 2,500,000 sudah termasuk pajak

Jadwal Training MTCNA:

  • 22 sd 24 Januari 2019 jam 09:00 sd 17:00 
  • 12 sd 14 Februari 2019 jam 09:00 sd 17:00
  • 12 sd 14 Maret 2019 jam 09:00 sd 17:00
  • 9 sd 11 April 2019 jam 09:00 sd 17:00

Yang tidak termasuk dalam harga pelatihan ini adalah :
• Biaya konsumsi selain disebutkan di atas
• Biaya akomodasi dan transportasi peserta ke tempat pelatihan

Setiap peserta wajib membawa laptop, dengan spesifikasi :
• WiFi ready
• 10/100 ethernet port ready
• 2 buah kabel UTP cat5 (2 meter)
• Operating system Windows XP atau yang lebih baru
(untuk pengguna Mackbook pastikan Mac OS X yang sudah terinstall wine utk menjalakan winbox.exe)

Alamat DCS Training Center (AFCWAVE):
Jl. Pangeran Jayakarta No.129 Blok D30, RT.7/RW.7, South Mangga Dua, Sawah Besar, Central Jakarta City, Jakarta 10730
https://goo.gl/maps/djNQPhcSf3U2

Pendaftaran
Tata cara pendaftaran:

  1. Seluruh proses pendaftaran training akan dilakukan melalui google form
  2. Pendaftar harus mengisi alamat email yang valid
  3. Setelah pendaftaran dilakukan, kami akan mengkonfirmasikan apakah masih tersedia tempat via email.
  4. Pembayaran harus dilakukan selambat-lambatnya 10 hari setelah konfirmasi ketersediaan tempat diberikan. Calon peserta yang tidak dapat melakukan pembayaran sampai batas yang ditentukan akan dibatalkan pendaftarannya dan dapat diisi oleh peserta lain.
  5. Pendaftaran Anda baru dianggap lengkap setelah kami menerima pembayaran.
  6. semua pertanyaan perihal pendaftaran bisa menghubungi 0819-5257-9860 atau email ke training@dcsindo.com

Daftar via google form berikut : https://goo.gl/forms/4BrtG1UYgQE4mVQp1

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

Mencari Sumber Serangan DDoS (Distribute Denial of Service) / Flooding dari salah satu host/server yang berjalan di Vsphere Server

Hari ini saya harus mencari sumber DDoS/Flooding dari salah satu server yang running sebagai virtual-machine/host di Vsphere, kendalanya saat ini vlan vcenter dan host di dalam vsphere masih dalam satu vlan, sehingga investigasi harus dilakukan satu persatu di tiap host yang running di vsphere (server fisik), dimana terdapat 3 vsphere yang mejalankan banyak host/server di dalamnya. belajar dari pengalaman tersebut sebaiknya vlan/interface untuk managemen vsphere/vcenter dipisah dengan vlan/interface yang di assign ke host/server.

indikator terjadinya flooding adalah banyaknya traffic dari sumber ip address yang tidak valid (ip tidak aktiv atau blok ip tersebut tidak di assign pada vlan/interfafce yang ada, atau ip tersebut tidak ada mac-address pasangannya di table /ip arp print) , dalam kasus ini traffic mencapai hampir 900mbps sehingga semua transfer data dari dan ke port switch 1gbps yang digunakan server vsphere mengalami intermitten (kemacetan)

karena vlan927 adalah vlan server vsphere dan banyak host/server di dalamnya maka selanjutnya saya login ke vcenter/vsphere satu persatu, dan ditemukan di vsphere2 dari tab Monitor->Performance->Overview->Networks, tercatat traffic yang cukup tinggi mencapai 900mbps, artinya data history utilisasi network di vsphere2 setara dengan utilisasi vlan927 yang terbaca pada router mikrotik yang ditemui adanya anomaly traffic yang sangat tinggi kadang mencapai 900mbps tetapi traffic tersebut hanya diterima (RX) oleh vlan927 lalu tidak di teruskan (TX) ke interface lainnya

selanjutnya satu persatu host di vsphere2 di cek perihal Monitoring->Performance View:Network, dan di dapati host mrtg memiliki pola-traffic dan besar-traffic yang sama dengan pola traffic DDoS/flood tersebut dan setelah dilakukan scan clamav pada host mrtg ternyata ditemukan sebuah Trojan

Dengan demikian maka sumber serangan DDoS/Flood dari salah satu host/server di Vsphere telah ditemukan dan dapat dilakukan tindakan mitigasi yang diperlukan.

semoga bermanfaat bagi yang membaca artikel ini

Informasi Training Mikrotik oleh Trainer Harijanto Pribadi bisa di pantau melalui http://gurumikrotik.com/wp/2019/01/03/pendaftaran-training-mikrotik-dasar-mtcna/

PPPOE over L2TP-BCP-MLPPP running over xDSL PPPOE antar Mikrotik RouterOS

kali ini saya mencoba mendokumentasikan percobaan/oprekan saya yang mungkin berguna dan memberi inspirasi bagi pembaca.

Seperti yang kita ketahui layanan internet broadband atau biasa disebut xDSL seperti layanan : Indihome, BiznetHome, MyRepublik, Firstmedia dkk menggunakan metode PPPOE untuk mengatur authentikasi user dan passsword sesuai RADIUS untuk mengatur IP address, Bandwidth Profile berdasarkan paket layanan, dan ternyata jika koneksi PPPOE tersebut berhasil terkoneksi akan menghasilkan inteface PPPOE dengan MTU 1480Byte berkurang 20Byte untuk header IP address PPPOE, sebagai perbandingan MTU Ethernet standar minimal 1500Byte agar semua aplikasi terutama protokol HTTP bisa diakses dengan lancar , nah karena MTU PPPOE interface tinggal 1480Byte maka jika ada IP datagram sebesar 1500Byte akan di fragmentasi (ip datagram 1500Byte di pecah jadi dua IP datagram yang lebih kecil lalu sesampainya di tujuan ip datagram tersebut di defragmentasi menjadi ip datagram yang utuh kembali)

Karena harga layanan Internet Broadband tersebut cukup murah dan terjangkau dengan kapasitas bandwidth yang cukup besar dari kisaran 20mbps/50Mbps/100Mbps/1Gbps dengan lastmile fiberoptic berbasis teknologi GPON atau Docsis 3.0 maka sudah barang tentu pelanggan lebih suka berlangganan layanan Internet Broadband kalau kebutuhannya hanya sebatas mengakses Internet, karena sekarang semua konten dan layanan semakin umum di letakkan di “system cloud” atau setidaknya di “colocation di datacenter” maka kebutuhan mengoperasikan server fisik di kantor semakin tidak populer

Tetapi ingat harga tidak pernah bohong kan?…. jika kita berlanggan layanan Metro-Ethernet atau Leased-Line sudah barang tentu MTU nya minimal 1500 bahkan sekarang sudah banyak operator yang bisa kasih jumbo frame dengan MTU 9600Byte dan mengijinkan QinQ (vlan dalam vlan) karena layanan metro-ethernet atau leased-line seharusnya end to end murni layer2 (layanan layer2 tidak memberikan IP address, IP address di provide oleh pelanggan sendiri, umumnya pelanggannya adalah ISP atau perusahaan besar seperti Bank, Enterprise dll), setidaknya sampai akhir desember 2018 harga layanan per 100mbps FiberOptic innercity layer2 di jabodetabek end-to-end berkisar di Rp 8.000.000,- sd Rp. 10.000.000,- perbulannya (baru biaya pipanya saja belum ada konten internetnya), bandingkan dengan pake layanan Indihome 100mbps beriksar di harga Rp. 1,120,000,- perbulan (sudah include konten internet lengkap)

Tapi jangan sedih karena ternyata dengan memanfaatkan fitur Mikrotik RouterOS yaitu:

akan di dapat tunnel l2tp yang terintegrasi dengan bridge dan mtu interface l2tp nya adalah 1596Byte wow kok bisa?… dan kenapa harus di integrasi dengan bridge? karena jika l2tp terintegrasi ke dalam sebuah bridge artinya bisa menggantikan peran EOIP tunnel yang kurang bersahabat dengan layanan Internet Broadband yang belum tentu mendapatkan IP address fix, berbeda dengan layanan dedicated yang IP address nya IP Publik dan fix (tidak berubah-ubah).

Dengan fitur “Multilink point to point protokol” maka koneksi ppp antar Mikrotik RouterOS (yang termasuk ppp adalah: l2tp, pptp, pppoe) sudah tidak perlu lagi di mangle change-mss lagi di firewall seperti pada versi-versi terdahulu. Untuk mengaktifkan fitur MLPPP tersebut cukup mengisi kotak MRRU dengan angka 1600 di kedua sisi Mikrotik RouterOS, bahkan ada juga yang mengisi dengan angka terbesar yang bisa di masukkan sebagai nilai MRRU. Dengan demikian maka kita bisa memanfaatkan layanan Internet Broadband sebagai alternativ untuk mengkoneksikan kantor-kantor cabang di remote area dengan biaya yang lebih terjangkau dibandingkan dengan menyewa layanan MPLS yang relative masih belum ekonomis harganya karena layanan MPLS adalah layanan ber SLA (Service Level Agrement) 98% sd 99% sedangkan layanan Internet Broadband umumnya tidak menerapkan SLA karena termasuk layanan “Best Effort” (kalau sedang ada gangguan out of service silahkan telp customer service dan mendapatkan nomor tiket aduan semoga segera dapat kembali normal layanannya). Atau bisa juga dimanfaatkan sebagai link backup mendampingi link utama yang biasanya menggunakan fiberoptic intercity yang masih mahal harga bulanannya bagi ISP-ISP kecil di daerah diluar Jabodetabek. Karena jika harus berlangganan dua fiberoptic intercity sekaligus dijamin sangat memberatkan bagi sebagian besar ISP di daerah.

Ok rasanya sudah cukup saya menyampaikan ide dan dasar pemikirannya, sekarang saya akan paparkan percobaan yang telah saya lakukan di unit apartemen saya daerah Jakarta Utara.

Saat ini saya berlangganan Internet Broadband kepada salah satu ISP kawan saya yang juga sama-sama anggota APJII, kenapa saya berlangganan Internet Broadband ke ISP kawan saya? karena perangkat radio bullet PTP di unit saya lantai 17 semula bisa konek ke BTS di Slipi saat ini sudah tertutup Gedung Baru yang lebih tinggi dari unit apartemen saya, maka paling ekonomis ya berlangganan layanan Internet Broadband ke ISP Kawan saya saja, dengan budget dikisaran Rp. 400,000,- sudah termasuk layanan TV Kabel dan Internet 30mbps, plus kalau ada gangguan tinggal WhatsApp ke VP ISP tersebut ops… jangan ya jangan di tiru gak baik, ikuti prosedur telpon customer service emang pelanggannya cuman gue wkwk kidding.

Langkah Pertama

pppoe dial ke ISP kawan saya dilakukan di Routerboard 951Ui-2HnD (bertugas sebagai router sekaligus wireless access point untuk melayani beberapa smartphone dan mackbookpro)

bisa dilihat pada status interface pppoe MTU:1480 dan MRU:1480

kalau saya ping ke ip yang di routing statik lewat pppoe ISP kawan saya dan size datanya di set 1500Byte (ukuran data maksimal yang dapat dilewatkan ethernet standar di 1500Byte, artinya jika sebuah interface bisa running di MTU 1500 atau lebih maka semua paket data yang di kirim akan berjalan dengan cepat dan lancar sehingga tidak perlu proses fragmentasi dan defragmentasi yang relative membutuhkan resource utk memprosesnya

Langkah Kedua

Enable L2TP server di Mikrotik RouterOS yang ada di rak server HTS di Datacenter IDC Duren Tiga

Yang perlu di perhatikan adalah Max MTU dan Max MRU L2TP Server defaultnya adalah 1460 atau 1450 dan jangan lupa tetapkan MRRU 1600, parameter lainnya disisi L2TP server tergantung kebutuhan di masing-masing router pembaca.

Langkah Ketiga

Buat bridge yang akan di masukkan ke profile yang akan di gunakan oleh secret l2tp, contoh yang saya buat bridge nya saya kasih nama : pppoe-laguna , karena nantinya setelah l2tp bcp mlppp nya running interface bridge pppoe-laguna akan saya add ke interface pppoe server HTS dan dari RB951Ui-2HnD router di unit apartemen akan dial pppoe ke server pppoe HTS di IDC Duren Tiga, oleh karena itu artikel ini saya kasih judul “PPPOE over L2TP over PPPOE”

di tab STP by default terpilih RSTP , harusnya fungsi RSTP ini adalah untuk mengantisipasi jika terjadi looping di layer2 maka RSTP harus mendrop atau menonaktivkan interface, sebagai informasi konfigurasi bridge sangat rentan dengan bahaya looping atau braoadcast mac-address antar port bridge yang terjadi di layer2 dan dalam beberapa kasus dapat melumpuhkan keseluruhan jaringan yang terkoneksi langsung dengan sebuah bridge yang mengalami looping dan tidak mengaktifkan fitur RSTP atau STP (Spanning Tree Protocol)

Langkah ke Empat

Buat ppp profile di /ppp profiles dalam contoh ini saya kasih nama: pppoe-laguna seperti nama bridge nya juga pppoe-lagunan

Local Address kebetulan sudah fix menggunakan ip 202.61.100.254 sedangkan Remote Address akan di ambil dari ip pool eksisting : vpn-dynamic , tentunya kotak Local Address dan Remote Address bisa disesuaikan dengan kebutuhan pembaca masing-masing

Langkah ke Lima

Buat Secret dalam contoh ini saya kasih nama secretnya : pppoe.laguna , profilenya: pppoe-laguna, servicenya l2tp, passwordnya rahasia dong…

Langkah ke Enam

Buat L2TP-Client di RB951Ui-2HnD, sebelumnya saya harus membuat routing statik di RB951Ui-2HnD agar ip server l2tp harus selalu lewat pppoe-ispkawansaya

Kemudian buat interface l2tp-client melalui /interface l2tp-client , dicontoh ini saya kasih nama l2tp-pppoe-laguna, Max MTU: 1450, Max MRU: 1450 (l2tp MTU nya lebih kecil lagi karena harus mempertimbangkan jika L2TP over PPPOE maka MTU L2TP harus lebih kecil dari MTU PPPOE standar 1480 karena headernya bertambah selain header PPPOE ditambah header L2TP, tapi tidak usah kawatir karena dengan mengisi MRRU : 1600 maka interface l2tp yang running MTU nya menjadi 1596

bisa dibaca di tab status interface l2tp-pppoe-laguna MTU nya : 1596 , kok bisa ya? mari kita test apakah benar interface l2tp tsb mampu mengirim data sebesar 1500 tanpa defragmentasi?

terbukti saya bisa ping ke ip gateway l2tp-server disisi rak server HTS di datacenter IDC Duren Tiga dengan size sampe sebesar : 1596Byte, di atas itu 1597Byte tidak bisa replay jika tidak menjalankan defragmentasi

Langkah ke Tujuh

Selanjutnya saya iseng penasaran apakah BCP yang menjembatani antara bridge: pppoe-laguna dengan interface l2tp -pppoe-laguna bisa meneruskan signal PPPOE dari PPPOE Server HTS yang running di mesin Mikrotik RouterOS yang sama dengan L2TP-Server yang tadi saya config. Jika di RB951Ui-2HnD interface bridge pppoe-laguna bisa scaning keberadaan PPPOE Server maka berarti saya bisa dial PPPOE ke Server PPPOE HTS dengan user pppoe yang ada di radius server.

saya masukan bridge pppoe-laguna yang di BCP dengan l2tp-pppoe-laguna sebagai interface di PPPOE Server, perihal: one session per host, mschap2, mschap1,chap,pap,service name, keepalive timeout dan default profile itu disesuaikan saja dengan router pembaca. Yang penting jangan lupa Max MTU: 1480, Max MRU: 1480 dan MRRU: 1600

Langkah ke Delapan

Buat interface pppoe-hts di RB951Ui-2HnD melalui /interface pppoe-client, saya coba PPPoE Scan di interface bridge pppoe-laguna dan server PPPoE HTS dapat dikenali

Langkah ke Sembilan

Kita uji coba interface pppoe-hts yang running via bridge pppoe-laguna BCP dengan l2tp-pppoe-laguna , dimana l2tp-pppoe-laguna running via PPPOE ISP kawan saya.

pastikan default route via pppoe-ispkawansaya di buat distance 2 supaya ketika pppoe-hts running maka default routenya akan aktive yang via pppoe-hts

selanjutnya kita cek menggunakan tool traceroute dan ping apakah size = 1500 do-not-defrag tetap bisa replay

Hasil pengecekan untuk menuju www.mikrotik.com routing melalui pppoe-hts dengan MTU:1596 terbukti ping ke www.mikrotik.com size=1500 do-not-defrag ping nya tetap reWah kalau begitu tidak selalu harus pakai EoIP kan untuk membuat tunnel antar Mikrotik RouterOS , karena kalau teman-teman ngakali koneksi xDSL yang PPPOE nya ber MTU 1480 dengan terlebih dahulu bikin l2tp antara remote area ke kantor pusat (HQ) dimana l2tp MTU nya 1450 lalu baru dibuat EoIP dengan local-address dan remote-address mengacu dari ip di interface l2tp tsb maka kebayang berapa banyak kerugian dari tidak efisiennya header pppoe+l2tp+eoip, oleh karena itu tidak heran kalau throughputnya turun drastis jika di bandwidth test interface EoIP tersebut, berikut saya kasih link ada seseorang yang sudah melakukan pengetesan perihal seberapa drop throughput dari interface tunnel dibandingkan interace fisiknya tetapi sepertinya pengetesan ini tidak membahas apakah beliau menggunakan MLPPP atau tidak, adapun informasinya sbb: Mikrotik-VPNS

Menurut RickFreyConsulting besarnya loss dari masing-masing tipe tunnnel yang ada di mikrotik seperti pada tabel berikut

Jadi gimana? mau coba implementasi L2TP+BCP+MLPPP sebagai alternative tunnel pengganti EoIP jika ternyata tidak memungkinkan untuk membuat EoIP interface karena IP address local dan remote salah satunya bukan IP Public dan tidak IP statis.

** Informasi Jadwal Training Mikrotik dasar MTCNA ** 
Tanggal 22-24 Januari 2019 atau 12 sd 14 Februari 2019
http://bit.do/mtcna-dcs2019-hp

Bandwidth Test Vlan Tx/Rx Tidak Imbang karena Tx-Drop

Beberapa waktu yang lalu kami menemukan kasus ketika link FO di alirkan via VLAN ke salah satu Ether di Mikrotik RouterOS menjalanan Bandwidth-Test TCP poin-to-point ternyata Bandwidth Transmitnya selalu drop jauh di banding Receive nya, ternyata permasalahanya di inteface VLAN terjadi Tx-Drop yang sangat masive

 

untuk mengatasi masalah tersebut solusinya adalah merubah “Interface Queues” dengan “ethernet-default” pfifo dan memperbesar “Queue Size” nya menjadi 2048 

 

hasilnya Bandwidth Test menjadi seimbang Tx/Rx nya walaupun menggunakan VLAN di Ether Mikrotik RouterOS

 

** Informasi Jadwal Training Mikrotik dasar MTCNA **
Tanggal 22-24 Januari 2019 atau 12 sd 14 Februari 2019
http://bit.do/mtcna-dcs2019-hp

Amankan Mikrotik RouterOS dari resiko Vulnerable & Exploit

Belakangan ini semakin banyak ancaman keamanan yang menarget RouterOS, yang terbaru adalah:

https://github.com/tenable/routeros/tree/master/poc/bytheway

Strategi paling sederhana dan cukup efektif agar RouterOS yang kita gunakan lebih aman lakukan hal-hal sbb:

  1. Rubah port service standar , misal port www dari 80 menjadi 88 , port winbox dari 8291 menjadi 9182, port ssh dari 22 menjadi 2222, port telnet dari 23 menjadi 2323, port ftp dari 21 menjadi 2121
  2. Disable service yang tidak digunakan, misal service API jika tidak digunakna disable saja
  3. Batasi source IP yang boleh mengakses Winbox dengan cara isi kotak Available From: dengan ip atau network yang dapat dipercaya, dengan demikian RouterOS relative lebih aman dari serangan hacker dan orang-orang iseng yang penasaran dengan script exploit “bytheway” , caranya seperti pada gambar berikut