Mengapa admin router berhenti merespons setelah perubahan VPN

Anda mengubah rute atau aturan firewall untuk menguji tunnel di router, dan sekarang halaman admin tidak merespons dari laptop yang sepuluh menit lalu masih berfungsi normal. Refleksnya adalah menyalahkan VPN. Sering kali tunnel sehat dan salah satu dari tiga hal lain rusak: tidak ada rute kembali ke alamat router itu sendiri, kebijakan masuk membuang permintaan, atau layanan web tidak mendengarkan di alamat yang Anda panggil. Ketiganya terlihat sama di browser, itulah sebabnya orang me-restart tunnel selama satu jam dan tidak belajar apa-apa.

Inilah mitos yang layak dibunuh lebih dulu: tunnel yang berfungsi bukan jalan kembali masuk. Itu koneksi jaringan baru dengan pertanyaan kepercayaannya sendiri, dan bisa diam-diam menghapus jalur manajemen lama Anda sambil membuka jalur baru yang tidak ditinjau siapa pun.

Tunnel tidak pernah menjadi jalur manajemen

Penerusan dan masukan adalah pekerjaan yang berbeda. "Bisakah klien menjangkau NAS melalui tunnel?" adalah pertanyaan penerusan tentang paket yang melewati router. "Bisakah saya membuka port SSH router?" adalah pertanyaan masukan tentang paket yang dialamatkan ke router itu sendiri. Aturan izin yang ditulis untuk lalu lintas yang diteruskan tidak melakukan apa pun untuk pertanyaan kedua, dan itulah alasan paling umum sebuah tunnel yang mengangkut lalu lintas dengan sempurna tetap menolak sesi admin Anda.

Kesalahan sebaliknya adalah memercayai nama antarmuka. Tunnel dienkripsi ke peer, bukan ke setiap layanan di belakangnya, dan kata VPN pada label antarmuka tidak mengatakan apa pun tentang sumber mana yang seharusnya diizinkan masuk.

Lapisan satu: apakah ada rute ke alamat router itu sendiri?

Mulailah di klien dan tanyakan ke kernel ke mana paket akan pergi. Di Linux, ip route get 10.6.0.1 mencetak rute yang dipilih, antarmuka keluar, dan alamat sumber. Jika ia melaporkan rute default menuju penyedia Anda, paket tidak pernah masuk ke tunnel, dan tidak ada aturan di router yang bisa menyelamatkannya.

Sisi tunnel punya versi pertanyaannya sendiri. WireGuard memperlakukan AllowedIPs sebagai tabel perutean kunci kripto: di setiap ujung ia menyatakan alamat sumber mana yang boleh dipakai peer dan tujuan mana yang dikirim ke peer tersebut. Jika entri klien tidak memuat alamat tunnel router, klien tidak punya rute ke sana. Jika entri server untuk klien itu tidak mencakup alamat tunnel klien, server membuang paket sebelum aturan firewall mana pun diperiksa.

Pastikan alamat persis yang ingin Anda jangkau sebelum men-debug kebijakan. Catatan DNS yang usang atau entri tetangga yang di-cache dari sebelum perubahan mengirim Anda ke alamat yang tidak pernah dimiliki router.

Lapisan dua: kebijakan masuk, bukan kebijakan penerusan

Firewall mengevaluasi aturan pada antarmuka tempat paket tiba. Di pfSense dan OPNsense, tab antarmuka dan urutan aturan menentukan apakah lalu lintas ke layanan firewall itu sendiri diizinkan; aturan yang membiarkan klien LAN keluar ke internet bukan aturan yang mengizinkan peer tunnel membuka GUI web. Di OpenWrt dengan firewall4, setiap zona membawa kebijakan masuk, option input 'ACCEPT' atau 'REJECT', dan antarmuka tunnel di zona dengan masukan REJECT akan menolak koneksi manajemen sambil tetap meneruskan lalu lintas jika penerusan diizinkan.

Jangan menonaktifkan aturan anti-lockout agar jalur baru berfungsi. Aturan itu menjaga alamat manajemen LAN agar tidak terkunci oleh aturan yang buruk; ia melindungi subnet LAN, bukan subnet tunnel yang baru Anda buat. Tambahkan satu aturan sempit untuk sumber administrator dan biarkan jaring pengamannya. Dokumentasi pfSense tentang akses admin menjelaskan di mana kontrol itu berada.

# on the router: bind addresses and the loaded ruleset
ss -ltnp | grep -E ':(22|80|443)\b'         # Linux / OpenWrt
sockstat -4 -l | grep -E ':(22|80|443)\b'   # FreeBSD / pfSense
nft list ruleset | grep -A6 'chain input'    # firewall4
pfctl -sr | head -40                         # pf / pfSense

Lapisan tiga: apakah ada yang mendengarkan di alamat itu?

Layanan bisa berjalan dan tetap tidak terjangkau karena terikat ke satu alamat. uhttpd OpenWrt menyimpan entri pendengar eksplisit di /etc/config/uhttpd, misalnya list listen_http '0.0.0.0:80'; build yang hanya mengikat alamat LAN tidak menerima apa pun di alamat tunnel, dan produk yang menampilkan pengaturan antarmuka pendengar berperilaku sama. Perintah pendengar di atas menjawab ini secara langsung.

Lalu pisahkan penolakan dari keheningan. nc -vz 10.6.0.1 443 yang mengembalikan koneksi ditolak berarti paket sampai ke router dan sesuatu menolaknya, entah port tertutup atau aturan penolakan eksplisit. Menggantung hingga waktu habis berarti paket dibuang atau tidak pernah dirutekan. Perbedaan itu memberi tahu Anda lapisan mana yang harus diperiksa berikutnya, dan biayanya lima detik.

Antarmuka VPN adalah batas, bukan jalur pemulihan

Enkripsi melindungi kabel; ia tidak mengatakan apa pun tentang siapa yang boleh membuka halaman admin. Setelah tunnel berfungsi, tahan dorongan untuk menyelesaikan keterjangkauan dengan mengizinkan semuanya di antarmuka tunnel. Beri administrator aturan yang terikat ke alamat tunnel mereka sendiri atau tunnel terpisah khusus admin, dan jauhkan pengguna biasa, NAS, kamera, dan laptop keluarga dari port manajemen. Peer yang membutuhkan berbagi file tidak boleh berada satu aturan dari login router.

Peran router mengubah jawabannya. Router yang mengakhiri tunnel boleh menerima administrator darinya, sedangkan router yang hanya memakai tunnel sebagai jalan keluar internet biasanya tidak boleh. Dalam kedua kasus, izin subnet bukanlah login, jadi biarkan autentikasi akun dan keamanan transport tetap aktif.

Langkah kompensasi yang orang lakukan setelah terkunci lebih buruk: mengaktifkan administrasi WAN atau meneruskan port ke GUI web. Itu mengubah gangguan singkat menjadi paparan permanen, dan halaman login lalu dapat dijangkau setiap pemindai di internet. Uji juga sisi yang ditolak, bukan hanya yang diizinkan, agar peer yang seharusnya tidak punya akses admin mengalami waktu habis atau ditolak alih-alih menerima permintaan login.

Uji juga dengan koneksi baru. Firewall stateful menyimpan aliran yang ada di tabel statusnya, jadi sesi SSH yang sudah Anda buka bisa bertahan dari perubahan yang memblokir setiap koneksi baru. Begitulah cara lockout tetap tak terlihat sampai reboot berikutnya atau tidur laptop berikutnya.

Siapkan jalan kembali sebelum Anda menyentuh kebijakan

Tuliskan empat hal sebelum perubahan pertama: bagaimana Anda akan menjangkau perangkat jika tunnel mati, seperti konsol serial, konsol penyedia, atau mesin di LAN; ke mana konfigurasi saat ini diekspor; aturan atau rute tunggal mana yang akan Anda ubah; dan bagaimana Anda akan mengembalikan persis item itu. Di OpenWrt, sysupgrade -b /tmp/backup.tar.gz menangkap konfigurasi, dan perubahan tetap tertunda hingga uci commit, yang memberi Anda pembatalan murah jika Anda menyadarinya tepat waktu. pfSense menyimpan riwayat konfigurasi, dan AutoConfigBackup hanya membantu jika sudah diaktifkan. Jika router menjalankan set aturan fail-closed, pastikan jalur pemeliharaan yang Anda rencanakan tidak berada di dalam lalu lintas yang diblokir aturan itu, dan ingat bahwa reboot menerapkan ulang aturan persisten alih-alih menghapusnya.

Ubah satu batas per percobaan, lalu uji dari koneksi baru alih-alih dari shell yang Anda biarkan terbuka. Jika uji gagal, kembalikan satu perubahan itu sebelum menyentuh lapisan berikutnya. Tunnel bisa tetap menyala sepanjang waktu, tetapi ikon status hijaunya bukan bukti bahwa Anda masih bisa masuk.

Pemeriksaan cepat sebelum Anda pergi:

• Bisakah Anda menjangkau router dari sumber yang tidak bergantung pada aturan yang baru Anda edit?
• Apakah kebijakan masuk di antarmuka tunnel hanya mengizinkan sumber administrator?
• Apakah layanan manajemen terikat ke alamat yang ada di tunnel?
• Sudahkah Anda menguji satu peer yang ditolak dan satu sesi baru?
• Apakah permukaan administrasi WAN masih tertutup?