Dokumentasi

Memilih apa yang melewati terowongan

Resep RouterOS opsional untuk router ForestVPN — mengirim satu kelompok aplikasi, mengirim semuanya, dan menghentikan kebocoran lalu lintas saat terowongan sedang mati.

Diperbarui 8 Oktober 2026

Semua yang ada di halaman ini bersifat opsional. Router ForestVPN menyalurkan lalu lintasnya sendiri melalui terowongan begitu tersambung, dan tidak satu pun dari isi halaman ini diperlukan untuk itu. Ini adalah tugas yang berbeda: menentukan lalu lintas LAN mana yang keluar melalui server keluar, dan apa yang terjadi saat server keluar tidak bisa dijangkau.

Pembagian tugasnya tidak pernah berubah. RouterOS memutuskan apa yang masuk ke terowongan, container menyalurkan apa pun yang diserahkan kepadanya, dan akun Anda memutuskan ke mana keluarnya. Jadi semua ini adalah konfigurasi RouterOS biasa — tanda mangle, tabel routing, aturan firewall — dan tidak satu pun menyentuh container.

Baca ini dulu

Tiga fakta menentukan apakah semua ini berhasil atau tidak. Melewatkannya berarti kehilangan waktu semalaman yang tidak akan kembali.

Tempelkan aturan ini di kotak yang benar-benar me-routing LAN Anda. Chain prerouting milik RouterOS hanya melihat lalu lintas yang benar-benar dirutekan oleh kotak itu sendiri. Pada access point yang berada di belakang gateway asli Anda, setiap aturan di bawah ini tidak akan berpengaruh — diukur pada sebuah cAP ax yang rute bawaannya sendiri adalah router di atasnya: container tersebut menyalurkan lalu lintas dengan sempurna dan lalu lintas klien LAN mana pun tidak pernah mendekatinya. Container itu boleh tetap berada di access point tersebut; aturan-aturannya yang harus ada di gateway.

Server keluar hanya menerima satu alamat sumber per perangkat — yaitu overlay lease yang diterbitkannya. Paket yang datang dengan sumber internal lain akan di-drop, bukan dirutekan, seberapa pun benarnya aturan Anda. Sesuatu harus menuliskan ulang (rewrite) LAN Anda ke lease tersebut, dan hal itu bergantung pada containernya:

ContainerYang perlu Anda lakukan
suquant/fvpn — aplikasi yang dikelola akunTidak ada. Sejak versi 0.3.9, container ini melakukan masquerade atas apa pun yang Anda forward ke dalamnya ke lease-nya sendiri, dan mengikuti lease itu saat berpindah. Perintah instalasi mengaktifkan ini.
suquant/fvpnq — terowongan mentah, dari .conf yang Anda tulis sendiriTambahkan src-nat ke Address di .conf Anda, yang juga menjadi nilai yang Anda masukkan ke AllowedIPs milik server keluar. Anda sendiri yang memilihnya, jadi nilainya stabil dan bisa disebut dalam sebuah aturan.

Menjalankan container yang lebih lama dari 0.3.9? Jalankan ulang perintah instalasinya — aturan-aturan di bawah akan menandai dan merutekan dengan sempurna, tetapi server keluar akan men-drop setiap paket, yang terlihat seolah LAN kehilangan akses internet sepenuhnya begitu Anda menambahkan aturan routing.

Fasttrack melewati mangle. Firewall bawaan pabrik MikroTik melakukan fasttrack pada koneksi yang sudah terbentuk, dan koneksi yang di-fasttrack tidak akan pernah mencapai chain mangle lagi — sehingga tanda Anda hanya berlaku untuk paket pertama sebuah flow dan tidak untuk paket setelahnya. Setiap resep di bawah ini menyertakan satu aturan yang menjaga koneksi bertanda agar tidak masuk fasttrack, dan aturan itu harus berada di atas aturan fasttrack-connection.

Dan sisi IPv6-nya, yang tidak bisa ditangani aturan-aturan ini untuk Anda

Semua yang di atas adalah IPv4. Jika router Anda memiliki IPv6 yang berfungsi, setiap tujuan yang Anda pilih di bawah ini juga bisa dijangkau lewat v6, di luar terowongan, tanpa ada peringatan apa pun. Sebaliknya, jika router justru mengumumkan dirinya sebagai router IPv6 tanpa memiliki rute bawaan v6, klien LAN akan mengirim v6 ke sana dan tidak mendapat balasan apa pun — bahkan tidak ada errornya, karena RouterOS 7 tidak memiliki rute "tidak terjangkau" untuk v6, hanya blackhole yang diam-diam. Perangkat tanpa Happy Eyeballs — TV, jam tangan pintar, apa pun yang melakukan koneksi langsung ke rekaman AAAA — akan macet menunggu hingga batas waktu koneksi penuh untuk setiap tujuan v6, yang terlihat seperti "internet kadang rusak" dan disalahkan ke Wi-Fi. Satu baris ini melaporkan Anda berada di kondisi yang mana:

# Does this router tell LAN clients it is their IPv6 router?
/ipv6/nd/print where ra-lifetime!=none
 
# Does it have somewhere to send their v6 traffic?
/ipv6/route/print where dst-address="::/0" and routing-table="main"

Ada jawaban untuk yang pertama tetapi tidak ada untuk yang kedua berarti Anda berada di kondisi kedua. Berikan rute bawaan yang sesungguhnya untuk IPv6, atau hentikan pengumumannya dengan /ipv6/nd/set [find] ra-lifetime=none.

Langkah 1 — kerangka dasarnya

Sama untuk ketiga resep. Ganti 172.31.254.2 dengan alamat container Anda sendiri (bawaan dari instalasi; ada di /interface/veth/print) dan ganti 192.168.88.0/24 dengan prefix LAN Anda sendiri.

Periksa /container/print detail terlebih dahulu. remote-image harus menunjukkan 0.3.9 atau versi yang lebih baru, dan cmd harus mengandung --nat-lan. Keduanya berasal dari perintah instalasi yang sekarang; container yang dipasang sebelum itu tidak memiliki keduanya, dan gejalanya adalah LAN kehilangan akses internet sepenuhnya begitu Anda menambahkan aturan routing di langkah 2.

# A routing table of its own, so nothing here can disturb your normal
# default route.
/routing/table add name=via-fvpn fib
 
# Where marked traffic goes: the container, on the address RouterOS itself
# gave it.
/ip/route add dst-address=0.0.0.0/0 gateway=172.31.254.2 \
    routing-table=via-fvpn comment="fvpn: traffic leaves via the container"
 
# Collapse the LAN to one source address on the way IN to the container. The
# exit never sees this one either -- the container masquerades again onto its
# own lease -- so this is about keeping your LAN's layout out of the
# container's connection table, not about being admitted.
/ip/firewall/nat add chain=srcnat out-interface=veth-fvpn action=masquerade \
    comment="fvpn: hide LAN addressing from the container"
 
# The tunnel costs 80 bytes of MTU. Without this, large TCP flows stall
# rather than fail, which presents as "the internet is broken on Tuesdays".
/ip/firewall/mangle add chain=forward action=change-mss new-mss=clamp-to-pmtu \
    protocol=tcp tcp-flags=syn connection-mark=via-fvpn \
    comment="fvpn: clamp MSS on tunnelled TCP"
 
# Fasttrack bypasses mangle, so marked connections have to be accepted
# before they reach it. This rule is inert if it ends up below the fasttrack
# rule -- check with /ip/firewall/filter/print that it did not.
/ip/firewall/filter add chain=forward action=accept connection-mark=via-fvpn \
    place-before=[find action=fasttrack-connection] \
    comment="fvpn: marked flows skip fasttrack"

Kemudian pilih salah satu dari dua langkah berikutnya. Keduanya menghasilkan connection mark via-fvpn yang sama, sehingga akan saling berebut lalu lintas yang sama jika Anda menempelkan keduanya.

Langkah 2a — opsional: hanya panggilan dan aplikasi pesan

Penyiapan ini sudah berjalan di RB3011 milik kami sendiri selama berbulan-bulan. Penyiapan ini membagi masalahnya sesuai cara lalu lintasnya benar-benar terbagi: signalling adalah segelintir hostname vendor, media adalah rentang port pada relai yang tidak dipublikasikan siapa pun.

# Signalling, by hostname. A hostname in a RouterOS address list is not a
# static entry -- the router resolves it and keeps the answers fresh, which
# is the only form that survives a CDN moving under you.
/ip/firewall/address-list
add list=fvpn-via address=g.whatsapp.net      comment="fvpn: signalling"
add list=fvpn-via address=media.whatsapp.net  comment="fvpn: signalling"
add list=fvpn-via address=mmg.whatsapp.net    comment="fvpn: signalling"
add list=fvpn-via address=static.whatsapp.net comment="fvpn: signalling"
add list=fvpn-via address=web.whatsapp.com    comment="fvpn: signalling"
add list=fvpn-via address=api.telegram.org    comment="fvpn: signalling"
add list=fvpn-via address=core.telegram.org   comment="fvpn: signalling"
add list=fvpn-via address=web.telegram.org    comment="fvpn: signalling"
add list=fvpn-via address=chat.signal.org     comment="fvpn: signalling"
add list=fvpn-via address=storage.signal.org  comment="fvpn: signalling"
 
/ip/firewall/mangle
add chain=prerouting action=mark-connection new-connection-mark=via-fvpn \
    dst-address-list=fvpn-via \
    comment="fvpn: signalling by resolved vendor hostname"
 
# Media, by port -- the half an address list can never cover, because a call
# lands on whichever TURN relay the vendor picked that minute.
add chain=prerouting action=mark-connection new-connection-mark=via-fvpn \
    protocol=udp dst-port=3478-3481 \
    comment="fvpn: STUN/TURN media - calls in every major app"
add chain=prerouting action=mark-connection new-connection-mark=via-fvpn \
    protocol=tcp dst-port=3478-3481,5349,5350 \
    comment="fvpn: STUN/TURN over TCP and TLS"
add chain=prerouting action=mark-connection new-connection-mark=via-fvpn \
    protocol=udp dst-port=5060,5061 comment="fvpn: SIP"
add chain=prerouting action=mark-connection new-connection-mark=via-fvpn \
    protocol=tcp dst-port=5060,5061 comment="fvpn: SIP over TCP/TLS"
add chain=prerouting action=mark-connection new-connection-mark=via-fvpn \
    protocol=tcp dst-port=5222,5223 comment="fvpn: XMPP signalling"
 
# One routing decision for the whole connection. Marking the connection
# first and the route second -- rather than marking the route directly -- is
# what keeps a call that started on the tunnel on the tunnel.
add chain=prerouting action=mark-routing new-routing-mark=via-fvpn \
    passthrough=no src-address=192.168.88.0/24 connection-mark=via-fvpn \
    comment="fvpn: route marked connections via the exit"

Daftar hostname ini adalah titik awal, bukan sumber yang pasti benar. Vendor menambah dan menghapusnya tanpa memberi tahu siapa pun. Periksa /ip/firewall/mangle/print stats untuk mencari counter yang tetap di angka nol — itu berarti aturan tidak mencocokkan apa pun, bukan aturan yang sedang bekerja diam-diam.

Langkah 2b — opsional: semuanya

/ip/firewall/mangle
# The container's own packets must never be marked, or its tunnel gets
# routed into itself. The install puts the container's interface in the LAN
# list, so the rule below WOULD match it. Substitute the container's
# address.
add chain=prerouting action=accept src-address=172.31.254.2 \
    comment="fvpn: never mark the container's own traffic"
 
# Everything from the LAN that is not addressed to this router.
# `dst-address-type=!local` is what keeps DNS, WebFig and the status page
# off the tunnel; `in-interface-list=LAN` rather than a source prefix keeps
# the rule correct when the LAN is renumbered.
add chain=prerouting action=mark-connection new-connection-mark=via-fvpn \
    in-interface-list=LAN dst-address-type=!local \
    comment="fvpn: everything from the LAN"
# `dst-address-type=!local` on this rule too, and it is not decoration. The
# install puts the container's veth in the LAN list, so replies coming back
# OUT of the container also match `in-interface-list=LAN`, and they still
# carry the connection mark. Mangle prerouting runs before dstnat, so at
# this moment their destination is still the router's own srcnat address --
# local. Without the test they would take the routing mark and be sent back
# into the container instead of on to the client that asked.
add chain=prerouting action=mark-routing new-routing-mark=via-fvpn \
    passthrough=no in-interface-list=LAN dst-address-type=!local \
    connection-mark=via-fvpn \
    comment="fvpn: route marked connections via the exit"

Hitung apa yang Anda tempelkan sebelum mengujinya. /ip/firewall/mangle/print harus menampilkan ketiga aturan ini. Penempelan di terminal yang menghilangkan salah satu sambungan baris akan meninggalkan Anda dengan aturan penandaan tanpa aturan routing, yang terlihat persis seperti "terowongan diabaikan" — koneksi tetap membawa connection-mark=via-fvpn, tetapi tidak ada yang pernah memeriksa tabelnya, dan setiap paket keluar lewat koneksi normal Anda.

Mengirim semuanya berarti Anda juga mengirim DNS — dan memang itulah intinya, tetapi artinya resolver milik server keluar yang akan menjawab LAN Anda. Pastikan apa pun yang bergantung pada nama lokal (printer, NAS, router.lan) masih bisa di-resolve sebelum Anda memutuskan bahwa ini adalah mode yang Anda inginkan.

Langkah 3 — opsional: mencegah kebocoran lalu lintas saat terowongan mati

Routing selektif memiliki satu modus kegagalan yang perlu ditutup: ketika terowongan berhenti, lalu lintas bertanda bisa diam-diam kembali keluar lewat koneksi normal Anda. Ketiga aturan ini membuatnya berhenti sepenuhnya sebagai gantinya. Tambahkan aturan ini setelah resep mana pun yang Anda pilih.

Setiap perintah di bagian ini sudah dijalankan di RouterOS 7.24.1 sebelum dituliskan. Sintaksnya berbeda dari RouterOS 6 di satu tempat, yang ditandai di bawah.

# 1. The route to the container counts only while the container answers.
/ip/route/set [find routing-table=via-fvpn dst-address=0.0.0.0/0] \
    check-gateway=ping
 
# 2. When it stops counting, drop rather than fall back. The higher distance
#    keeps this route inactive for as long as the real one is up. `blackhole`
#    is a bare flag here, not `type=blackhole` -- RouterOS 7 has no `type`
#    property on a route at all, and rejects it with "bad parameter type".
/ip/route/add dst-address=0.0.0.0/0 blackhole distance=10 \
    routing-table=via-fvpn comment="fvpn: kill switch - no exit, no traffic"
 
# 3. The leak the first two cannot see: a container that is alive and
#    answering ping while its own tunnel is down forwards to its default
#    gateway, which is you. Traffic wearing the address the srcnat above gave
#    it must never reach the internet directly. Substitute your router's own
#    address on the container's /30 if you changed it.
/ip/firewall/filter/add chain=forward action=drop src-address=172.31.254.1 \
    out-interface-list=WAN \
    place-before=[find comment="fvpn: marked flows skip fasttrack"] \
    comment="fvpn: kill switch - overlay source must not leave over WAN"

Aturan 3 harus berada di atas aturan pengecualian fasttrack dari langkah 1, atau aturan itu akan menerima lalu lintas terlebih dahulu dan drop-nya tidak akan pernah tercapai. place-before yang melakukannya di sini; konfirmasi dengan /ip/firewall/filter/print.

Versi yang lebih ketat: perangkat yang hanya boleh memakai terowongan

Jika yang sebenarnya Anda inginkan adalah "laptop ini tidak punya akses internet kecuali lewat terowongan", nyatakan itu secara langsung, bukan menyimpulkannya dari status routing:

/ip/firewall/address-list/add list=fvpn-only address=192.168.88.50 \
    comment="fvpn: the work laptop"
/ip/firewall/filter/add chain=forward action=drop src-address-list=fvpn-only \
    out-interface-list=WAN \
    place-before=[find comment="fvpn: marked flows skip fasttrack"] \
    comment="fvpn: kill switch - these devices are tunnel-only"

Perangkat itu kini hanya bisa menjangkau internet lewat container atau tidak sama sekali, apa pun yang dikatakan tabel routing pada pagi tertentu.

Memeriksa apakah berhasil

# A rule sitting at zero packets is a rule matching nothing.
/ip/firewall/mangle/print stats
/ip/route/print where routing-table=via-fvpn
# The fasttrack-exemption rule has to be above the fasttrack rule.
/ip/firewall/filter/print

Dari perangkat LAN, buka halaman "what is my IP" mana pun. Halaman itu seharusnya menunjukkan negara server keluar untuk lalu lintas yang Anda pilih, dan negara Anda sendiri untuk semua yang lain. Jika yang muncul adalah negara Anda sendiri untuk semuanya, penyebab yang biasa terjadi adalah fakta pertama di halaman ini: aturan-aturannya berada di kotak yang tidak me-routing LAN.

Membatalkannya

Setiap baris di atas membawa komentar yang diawali fvpn:, sehingga menghapusnya bisa dilakukan secara presisi — dan tidak akan menyentuh objek milik container itu sendiri, yang diberi komentar forestvpn oleh installer.

/ip/firewall/mangle/remove [find comment~"^fvpn:"]
/ip/firewall/filter/remove [find comment~"^fvpn:"]
/ip/firewall/nat/remove [find comment~"^fvpn:"]
/ip/firewall/address-list/remove [find comment~"^fvpn:"]
/ip/route/remove [find comment~"^fvpn:"]
/ip/address/remove [find comment~"^fvpn:"]
/routing/table/remove [find name="via-fvpn"]

Container tetap berjalan, tetap mempertahankan tautan akunnya, dan kembali hanya menyalurkan lalu lintasnya sendiri melalui terowongan. Jika ada hal lain yang salah, lihat pemecahan masalah.

Kembali ke Bantuan

Bahasa Indonesia
Tanyakan apa saja pada kami