[🛠] IT Operations #1: Cara Saya Mengatasi Masalah ‘Tidak Ada Koneksi Internet’ pada Router Perusahaan (bersama Codex)

✨ Ringkasan GPT-5.6 Sol

Catatan tentang menghubungkan ponsel ke router lantai dua dan browser Mac ke router utama agar Codex dapat mendiagnosis langsung perangkat nyata, sambil mempelajari jaringan secara real-time hingga gangguan pulih.

Hari ini Wi-Fi lantai dua di kantor bermasalah. Sinyalnya sangat kuat, tetapi Internet tidak berfungsi. Router menyala dan ponsel juga terhubung, tetapi layar terus menampilkan Tidak ada koneksi Internet.

Router di depan saya menyala dan indikator LAN-nya bergerak. Dari tampilan luarnya saja, saya tidak bisa mengetahui bagian mana yang terputus.

Dulu, saya mungkin akan mematikan dan menyalakan router beberapa kali, memeriksa apakah kabel jaringan salah terpasang, lalu mulai mencari di Internet jika masalahnya tetap ada. Namun, dua hari sebelumnya, saat menulis Jika tahu cara memanfaatkan AI secara aktif, kemungkinan yang dapat dilakukan menjadi tak terbatas, saya mempelajari satu cara kerja baru.

Saya hanya perlu menghubungkan perangkat dan layar nyata kepada AI.

Kali ini saya langsung memakai cara itu. Ponsel saya sambungkan ke Mac melalui USB dan ADB saya buka. Ponsel terhubung ke Wi-Fi lantai dua yang bermasalah. Di Chrome ponsel, saya membuka layar administrasi router lantai dua dan login. Di Chrome Mac, saya membuka layar administrasi router utama perusahaan dan login. Lalu saya berbicara kepada Codex.

Intinya bukan saya menemukan sendiri seluruh pengaturan router, melainkan saya terlebih dahulu menyiapkan perangkat fisik, lingkungan eksekusi perintah, dan layar administrasi yang sudah login agar Codex benar-benar dapat bekerja.

Pahami dulu situasinya sekarang. Mengubah sesuatu sembarangan mungkin menimbulkan masalah. Sebisa mungkin, coba selesaikan dengan perintah terlebih dahulu.

Kini Codex bukan lagi chatbot yang hanya memberi penjelasan. Ia dapat membaca status jaringan ponsel melalui perintah, berpindah dengan Computer Use di antara dua layar administrasi tempat saya sudah login, lalu memeriksa dan mengubah pengaturan yang sebenarnya.

Saya menghubungkan ponsel dan browser untuk menunjukkan dua jaringan sekaligus

Pada awalnya saya bahkan tidak tahu mengapa 192.168.0.1 tidak dapat dibuka. Setelah diperiksa, kedua router ternyata memiliki peran yang berbeda.

Router utama 192.168.0.1
  └─ WAN ipTIME lantai dua 192.168.0.86
       └─ Wi-Fi / LAN lantai dua 192.168.1.x
            └─ Layar administrasi router lantai dua 192.168.1.1

Karena Mac terhubung ke jaringan utama, router perusahaan 192.168.0.1 dapat dibuka. Sebaliknya, ponsel yang terhubung ke Wi-Fi lantai dua menerima alamat 192.168.1.x dan menggunakan 192.168.1.1 sebagai gateway. Karena itu, router utama dibuka di browser Mac, sedangkan router lantai dua dibuka di browser ponsel.

Saya tidak hanya menunjukkan layarnya. Karena ADB terhubung, Codex dapat membaca IP dan route yang diterima ponsel, lalu menentukan antarmuka Wi-Fi lantai dua untuk menguji komunikasi secara langsung. Ponsel dapat berhasil mengirim permintaan Internet melalui data seluler ketika Wi-Fi terputus, jadi sekadar menjalankan ping dapat menghasilkan kesimpulan yang salah.

adb shell "ping -I wlan0 -c 3 -W 2 192.168.1.1"
adb shell "ping -I wlan0 -c 3 -W 2 192.168.0.1"
adb shell "ping -I wlan0 -c 3 -W 2 1.1.1.1"

adb shell "curl --interface wlan0 -k -sS -o /dev/null \
  -w '%{http_code}' --connect-timeout 5 --max-time 10 \
  https://www.google.com/generate_204"

Hasilnya seperti ini.

• Router lantai dua 192.168.1.1 merespons dari ponsel.
• Router utama 192.168.0.1 tidak merespons.
• IP eksternal 1.1.1.1 juga tidak merespons.
• Pemeriksaan HTTPS berakhir dengan 000.

Saya menyaksikan seluruh proses itu dari samping. Tertangkapnya sinyal Wi-Fi hanya berarti ponsel dan router lantai dua sudah terhubung. Masalahnya berada setelah itu, pada bagian ketika WAN router lantai dua keluar menuju jaringan utama.

Saya tidak membuka buku jaringan terlebih dahulu lalu mempelajari LAN, WAN, gateway, dan double NAT secara berurutan. Dengan melihat Codex memisahkan dan menguji gangguan satu per satu, saya langsung memahami mengapa 192.168.0.1 dan 192.168.1.1 sama-sama ada.

Lease DHCP yang normal tetap dapat menyembunyikan komunikasi yang terblokir

Pada hari yang sama, IP NAS pengembangan dan NAS data juga berubah. Di daftar klien DHCP router utama, saya mencari alamat saat ini dan alamat MAC-nya, lalu membuat reservasi agar kedua NAS tetap menerima alamat yang sama pada koneksi berikutnya. Port forwarding HTTP dan HTTPS yang menerima otomasi cuti yang sebelumnya dipindahkan ke NAS juga disesuaikan agar mengarah ke alamat baru.

Dalam proses itu, saya mempelajari DHCP tepat ketika pengetahuan tersebut dibutuhkan.

• Alokasi DHCP biasa meminjamkan IP yang tersedia kepada perangkat.
• Reservasi DHCP memberikan IP yang sama ketika alamat MAC tertentu terhubung.
• Menetapkan IP statis pada perangkat berbeda dengan membuat reservasi DHCP pada router.

Namun, masalah router lantai dua tidak dapat dijelaskan hanya dengan reservasi DHCP. Layar administrasi ipTIME menampilkan IP eksternal 192.168.0.86 dengan status Terhubung ke Internet. Router utama juga memiliki catatan bahwa IP tersebut sedang dipinjamkan kepada ipTIME.

Di tengah proses, Codex hanya melihat halaman daftar DHCP yang sedang terbuka dan keliru menyimpulkan bahwa .86 tidak ada. Ada lebih dari 90 klien sehingga daftar terbagi menjadi beberapa halaman, sedangkan saya sudah melihat baris tersebut pada halaman lain.

Ada, kan?

Ketika saya kembali menunjukkan alamat MAC dan baris lease .86, arah investigasi berubah. Masalahnya bukan gagal mendapatkan IP, melainkan mencari pengaturan yang memblokir komunikasi setelah IP diterima.

Melepas lalu menyambungkan kembali koneksi WAN tidak mengubah hasilnya. Kontrol akses aktif, tetapi blacklist kosong. Kemudian penyebabnya muncul di layar IP&MAC Binding. .86 tidak terikat pada MAC WAN ipTIME saat ini, melainkan pada MAC komputer desktop lama.

Server DHCP: saat ini meminjamkan 192.168.0.86 kepada ipTIME
IP&MAC Binding: mencatat 192.168.0.86 sebagai milik MAC PC lama

DHCP memberikan alamat tersebut kepada perangkat saat ini, tetapi pengaturan keamanan menganggap pemilik alamatnya adalah perangkat lain. Karena itu, ipTIME tampak menerima IP di layar administrasi, tetapi tidak dapat berkomunikasi dengan router utama.

Menerima IP dan dapat berkomunikasi menggunakan IP tersebut bukanlah hal yang sama. Saya memahami perbedaannya secara alami karena mengikuti alur gangguan ini.

Saya hanya menghapus satu binding lama dan memverifikasi kembali melalui Wi-Fi yang sebenarnya

Saya tidak menonaktifkan seluruh fungsi keamanan router. Hanya binding IP–MAC lama untuk .86 yang dihapus, lalu koneksi WAN ipTIME dinegosiasikan ulang.

Kali ini hasilnya langsung berubah.

192.168.0.1  ping berhasil
1.1.1.1      ping berhasil
HTTPS        204
Wi-Fi Android VALIDATED

Setelah pulih, saya menambahkan reservasi alamat DHCP agar MAC WAN ipTIME saat ini selalu menerima .86. Reservasi DHCP terus memberikan alamat yang sama kepada perangkat saat ini, sedangkan IP–MAC binding memaksa perangkat mana yang boleh menggunakan alamat tersebut. Gangguan ini muncul karena kedua catatan menunjuk perangkat yang berbeda.

Internet kembali hidup, tetapi struktur double NAT, dengan ipTIME lantai dua membuat jaringan 192.168.1.x tersendiri di bawah jaringan utama, tetap dipertahankan. Beralih ke mode AP atau hub bukan hanya memerlukan perubahan DHCP dan IP administrasi, tetapi juga perubahan tempat kabel fisik terpasang antara WAN dan LAN. Jika diubah sembarangan dari jarak jauh, layar administrasi dan perangkat lantai dua dapat hilang sekaligus. Karena itu, hari ini saya hanya memperbaiki penyebab gangguan Internet yang sudah dipastikan.

Saya tidak memperbaiki setelah mempelajari seluruh jaringan; saya belajar sambil memperbaiki

Inti pekerjaan saya hari ini bukan mempelajari seluruh pengetahuan jaringan terlebih dahulu lalu memperbaiki router.

Begitu masalah muncul, saya langsung memakai cara kerja yang ditemukan pada 22 Juli. Saya lebih dulu melakukan koneksi fisik dan login yang hanya dapat saya lakukan sendiri. Ponsel dihubungkan ke Wi-Fi lantai dua lalu ke Mac melalui USB. Kedua layar administrasi router dibuka secara terpisah. Saya menentukan lingkup perubahan dan, ketika Codex melewatkan baris DHCP, saya menunjukkannya kembali.

Setelah itu Codex dapat bergerak. Ia memeriksa melalui perintah sampai bagian mana komunikasi berjalan, membaca pengaturan di kedua layar administrasi dengan Computer Use, menghapus kemungkinan penyebab satu per satu, mengubah hanya satu catatan yang diperlukan, lalu memverifikasi kembali melalui ponsel yang sama.

Saya tidak mempelajari segala macam pengetahuan jaringan secara terpisah sebelum terjun ke praktik. Konsep yang diperlukan saat itu langsung melekat pada layar nyata dan hasil perintah. DHCP, alamat MAC, gateway, LAN dan WAN, IP–MAC binding, dan double NAT bukan lagi istilah yang harus dihafal, melainkan alat untuk menjelaskan mengapa gangguan di depan mata terjadi.

AI juga tidak selalu benar sejak awal. Ia membuat penilaian yang salah, seperti saat melewatkan .86. Namun, ketika saya melihat layar nyata dan kembali menunjukkan bagian yang janggal, Codex langsung melanjutkan ke pemeriksaan berikutnya. Saya tidak perlu mengetahui setiap perintah dan menu pengaturan terlebih dahulu, tetapi harus terus berperan menilai apakah hasilnya aneh dan menetapkan kembali sasaran.

Dua hari sebelumnya, saya pertama kali menyadari bahwa menghubungkan browser dan ponsel kepada AI memperluas wilayah yang dapat saya tangani secara langsung. Hari ini, saya aktif menerapkan kesadaran itu pada gangguan nyata di perusahaan.

Mempelajari bidang yang tidak diketahui selama berminggu-minggu lalu menerapkannya suatu hari nanti bukan satu-satunya cara. Saya juga dapat menyelesaikan masalah nyata bersama AI, mempelajari apa yang diperlukan saat itu, dan langsung menghasilkan hasil.