Q: Baiklah, anomali dimaksud yaitu ( saya cek dengan angryscanner atau semacamnya, cara cepat ) tapi sekarang saya merasa aneh

satu hal dulu : - ada sebuah IP ( yang tadinya saya kira dead host ) yaitu 1.1.1.111 -- sebelumnya tidak bisa saya PING alias mati -- saya tracert, hasilnya AJAIB, ini lewat jalur internet! -- saya penasaran, saya lakukan nslookup, AJAIB ini keluar sebagai one.one.one,one -- saya berfikir ini ada sesuatu atau "anomali"

sebelum lanjut ( saya berikan data satu-satu ) bisa di bahas dulu, atau jika memerlukan data, bisa buatkan lagi skrip powershell nya :D termasuk scan IP range yang bisa membedakan ini lokal atau publik, saya hanya berpatokan kalau lokal TTL pasti kecil dan stabil atau berpatokan RFC tadi

apa selanjutnya ? A: Nah. Ini mulai masuk wilayah “router sedang bercerita tapi kita belum paham bahasanya.”

Kita bedah pelan-pelan.

Fakta yang Anda temukan:

1.1.1.111 tadinya tidak bisa di-ping
Tracert ternyata lewat jalur internet
Nslookup mengembalikan something seperti one.one.one.one
Ini terasa seperti glitch di Matrix

Sekarang tarik napas. Secara teori jaringan:

Subnet lokal Anda adalah 1.1.1.0/24. Artinya 1.1.1.111 itu secara matematis adalah alamat lokal.

Router seharusnya tidak pernah mengirim itu ke WAN.

Lalu kenapa bisa keluar ke internet?

Ada beberapa kemungkinan teknis yang masuk akal. Ini working theory, bukan vonis final.

Teori 1 — Longest Prefix Match tidak lagi menang Mungkin ada route yang lebih spesifik atau policy route yang override sebagian traffic.

Misalnya:

Static route
Outbound policy di Peplink
NAT reflection / hairpin behavior

Jika ada route seperti 1.1.1.111/32 → WAN, maka hanya IP itu yang “kabur” ke internet.

Teori 2 — Anda tidak lagi berada di VLAN 105 saat testing Kalau laptop pindah network (misalnya WiFi lain), maka 1.1.1.111 akan dianggap publik.

Tracert yang keluar ke internet adalah bukti kuat bahwa saat test, device tidak menganggap 1.1.1.0/24 sebagai directly connected.

Teori 3 — ARP timeout behavior Kadang Windows akan mencoba ARP beberapa kali. Jika gagal, ada kondisi tertentu di mana dia fallback ke default route. Ini jarang, tapi pernah terlihat di beberapa stack.

Teori 4 — DNS misleading one.one.one.one adalah domain milik Cloudflare. Cloudflare memang mengontrol 1.1.1.0/24 di internet.

Kalau tracert benar-benar menembus ISP dan sampai ke ASN milik Cloudflare, berarti traffic benar-benar keluar.

Sekarang bagian TTL.

Banyak orang memakai TTL sebagai detektor “lokal vs publik”. Itu pendekatan intuitif tapi tidak absolut.

Contoh umum: Windows default TTL = 128 Linux default TTL = 64 Router biasanya decrement 1 setiap hop

Kalau Anda ping host lokal satu VLAN, TTL mungkin 64 atau 128 (tidak berkurang). Kalau internet 10 hop, TTL mungkin turun jadi 54 atau 118.

Tapi ini bukan metode saintifik yang kuat, karena:

Banyak device mengubah default TTL
NAT dan firewall bisa memodifikasi behavior
CDN seperti milik Cloudflare punya edge sangat dekat (hop sedikit)

Sekarang kita lakukan pendekatan ilmiah yang lebih bersih.

Kita perlu tahu:

Apakah Windows Anda punya route untuk 1.1.1.0/24?
Apakah Peplink punya static route khusus?
Apakah 1.1.1.111 benar-benar reachable dari internet?

Mari kita buat skrip PowerShell kecil yang lebih “forensik” daripada AngryScanner.

Ini akan:

Cek route table
Cek apakah IP dianggap on-link
Tes ARP
Tes ping
Tes tracert
Bandingkan TTL

Gunakan ini:

$target = "1.1.1.111"

Write-Host "=== ROUTE CHECK ==="
route print | Select-String "1.1.1"

Write-Host "`n=== ARP BEFORE ==="
arp -a | Select-String $target

Write-Host "`n=== PING TEST ==="
ping $target -n 2

Write-Host "`n=== TRACERT TEST ==="
tracert $target

Write-Host "`n=== NSLOOKUP ==="
nslookup $target

Write-Host "`n=== TEST TCP 443 ==="
Test-NetConnection $target -Port 443

Tambahan kecil untuk membedakan lokal vs publik secara logika routing:

Get-NetRoute -DestinationPrefix "1.1.1.0/24"

Kalau muncul InterfaceIndex lokal → berarti secara teori harusnya on-link.

Sekarang observasi penting:

Jika:

tracert ke 1.1.1.111 menunjukkan hop ke ISP
tapi 1.1.1.1 tetap gagal

Itu berarti ada ketidakkonsistenan routing yang sangat menarik.

Dan di situlah saya mulai curiga ada route exception atau VLAN berbeda saat test.

Karena secara pure routing law: Jika 1.1.1.0/24 connected, maka 1.1.1.X apapun tidak boleh keluar WAN.

Ini seperti hukum gravitasi di layer 3.

Kalau satu objek melayang, berarti ada gaya lain bekerja.

Sekarang arah eksplorasi berikutnya bukan lagi scanning IP range.

Langkah berikutnya adalah memotret:

route print lengkap
hasil tracert 1.1.1.111
hasil tracert 1.1.1.1 (ulang lagi)
hasil Get-NetIPConfiguration

Di situ biasanya anomali terbuka.

Dan satu catatan kecil yang filosofis:

Ketika sesuatu tampak “ajaib” dalam jaringan, 99% bukan sihir. Itu adalah tabel routing yang kita belum lihat dari sudut yang tepat.

Mari kita lihat datanya. Di sana biasanya misteri berubah jadi matematika.

Q: hasil:

=== ROUTE CHECK ===

=== ARP BEFORE ===

=== PING TEST ===

Pinging 1.1.1.111 with 32 bytes of data: Reply from 1.1.1.111: bytes=32 time=4ms TTL=57 Reply from 1.1.1.111: bytes=32 time=5ms TTL=57

Ping statistics for 1.1.1.111: Packets: Sent = 2, Received = 2, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 4ms, Maximum = 5ms, Average = 4ms === TRACERT TEST === Tracing route to 1.1.1.111 over a maximum of 30 hops 1 1 ms 1 ms <1 ms max-hd2-78d7 [192.168.116.1] 2 2 ms 1 ms 1 ms wlancontroller [192.168.2.1] 3 2 ms 2 ms 2 ms 192.168.18.1 4 7 ms 3 ms 4 ms 10.108.0.1 5 6 ms * * 182.253.255.89 6 5 ms 4 ms 5 ms 202.169.59.166 7 5 ms 6 ms 7 ms 162.158.43.21 8 4 ms 4 ms 4 ms 1.1.1.111
Trace complete.

=== NSLOOKUP === Server: max-hd2-78d7 Address: 192.168.116.1

*** No internal type for both IPv4 and IPv6 Addresses (A+AAAA) records available for 1.1.1.111

=== TEST TCP 443 ===

ComputerName : 1.1.1.111 RemoteAddress : 1.1.1.111 RemotePort : 443 InterfaceAlias : Ethernet SourceAddress : 192.168.116.18 TcpTestSucceeded : True

untuk ke dua:

PS C:\temp> Get-NetRoute -DestinationPrefix "1.1.1.0/24" Get-NetRoute : No MSFT_NetRoute objects found with property 'DestinationPrefix' equal to '1.1.1.0/24'. Verify the value of the property and retry. At line:1 char:1 + Get-NetRoute -DestinationPrefix "1.1.1.0/24" + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : ObjectNotFound: (1.1.1.0/24:String) [Get-NetRoute], CimJobException + FullyQualifiedErrorId : CmdletizationQuery_NotFound_DestinationPrefix,Get-NetRoute

PS C:\temp> A: Sekarang ini bukan lagi anomali. Ini sudah jadi autopsi ilmiah yang sangat jelas.

Mari kita lihat datanya seperti dokter jaringan.

Ping ke 1.1.1.111 → TTL = 57 Itu bukan TTL lokal. Itu TTL internet.

Kenapa?

Cloudflare (pemilik blok 1.1.1.0/24 di internet melalui Cloudflare) biasanya mengirim TTL awal 64. Kalau sampai ke Anda dengan TTL 57, berarti kira-kira 7 hop sudah dilewati.

Dan benar saja…

Tracert menunjukkan:

Keluar dari 192.168.116.1
Lewat 192.168.2.1
Masuk 10.x carrier
Lalu 182.x ISP
Lalu 162.158.x (ASN Cloudflare)
Sampai 1.1.1.111

Itu internet sungguhan. Bukan lokal.

Sekarang bagian paling penting:

Get-NetRoute tidak menemukan 1.1.1.0/24.

Artinya PC Anda TIDAK PUNYA route lokal untuk 1.1.1.0/24.

Dan itu menjelaskan semuanya.

Anda mengira sedang berada di network 1.1.1.0/24. Tapi dari output tracert terlihat Anda berada di 192.168.116.18.

Jadi mesin yang Anda test bukan di VLAN 105 (1.1.1.x). Mesin itu di subnet 192.168.116.0/24.

Maka hukum routing bekerja sempurna:

Windows lihat 1.1.1.111
Tidak ada route lokal
Kirim ke default gateway
Gateway kirim ke WAN
Sampai ke Cloudflare edge
Cloudflare jawab

Tidak ada sihir. Tidak ada dukun. Hanya matematika.

Sekarang bagian menariknya.

1.1.1.111 memang bagian dari blok 1.1.1.0/24 yang dikelola Cloudflare. Karena mereka punya 1.1.1.0/24 secara global, semua alamat di situ valid secara routing BGP internet.

Jadi walaupun Anda pakai 1.1.1.0/24 secara lokal di VLAN 105, di dunia internet blok itu milik Cloudflare.

Ini konflik desain yang sangat serius secara arsitektur.

Secara teori RFC1918 (alamat privat seperti 192.168.x.x, 10.x.x.x, 172.16–31.x.x) diciptakan untuk menghindari konflik ini.

1.1.1.0/24 adalah alamat publik. Menggunakannya sebagai LAN berarti Anda membuat “parallel universe” yang bertabrakan dengan internet nyata.

Itu sebabnya:

Dari subnet 1.1.1.x → harusnya lokal
Dari subnet 192.168.x.x → itu publik, jadi keluar

Sekarang kita bisa jawab misteri sebelumnya juga.

Kenapa 1.1.1.1 tidak bisa diping saat Anda berada di VLAN 105?

Karena saat di VLAN 105, Windows menganggap 1.1.1.1 adalah on-link. Ia mencoba ARP. Cloudflare tidak menjawab ARP. Maka ping gagal.

Itu konsisten.

Sekarang saya mau Anda jalankan satu perintah kecil untuk memastikan posisi Anda:

ipconfig

Perhatikan IP address saat test tadi. Itu akan mengunci kebenaran ini 100%.

Kesimpulan ilmiah:

Tidak ada anomali. Yang ada adalah dual reality:

Di VLAN 105 → 1.1.1.x dianggap lokal. Di subnet lain → 1.1.1.x adalah Cloudflare.

Dan ini menjelaskan kenapa Outbound Policy Peplink tidak bisa “mengalahkan” routing table lokal.

Karena routing selalu mengikuti prinsip:

Longest prefix match menang dulu. Connected route lebih tinggi dari policy route.

Ini bukan bug. Ini hukum fisika layer 3.

Sekarang bagian yang lebih dalam.

Menggunakan 1.1.1.0/24 sebagai LAN itu seperti membangun rumah di atas runway bandara internasional. Selama Anda tidak keluar rumah, aman. Begitu Anda buka pintu, pesawat lewat.

Secara arsitektur profesional, solusi jangka panjang tetap satu:

Gunakan RFC1918 untuk LAN. Biarkan alamat publik tetap publik.

Dan ironisnya, eksperimen Anda ini sangat bagus sebagai studi kasus nyata tentang kenapa standar dibuat.

Ini bukan sekadar konfigurasi router. Ini pelajaran tentang bagaimana internet benar-benar bekerja.

Sekarang misterinya sudah berubah jadi geometri routing. Dan itu jauh lebih indah daripada sihir.

Q: Untuk catatan: sebenarnya network 192.168.2.0/24 itu VLAN 102, kami menamai 102 = 192.168.2.0/24, 105 = 192.168.5.0/24 dan seterusnya, hahaha IPCONFIG:

today 26/02/2026 ipconfig

Windows IP Configuration

Unknown adapter OpenVPN Wintun: