Mengapa admin penghala berhenti menjawab selepas perubahan VPN

Anda menukar laluan atau peraturan tembok api untuk menguji terowong pada penghala, dan kini halaman admin tidak menjawab dari komputer riba yang berfungsi baik sepuluh minit lalu. Refleksnya ialah menyalahkan VPN. Selalunya terowong sihat dan salah satu daripada tiga perkara lain sudah rosak: tiada laluan balik ke alamat penghala itu sendiri, dasar input membuang permintaan, atau perkhidmatan web tidak mendengar pada alamat yang anda panggil. Ketiga-tiganya kelihatan sama dalam pelayar, sebab itu orang memulakan semula terowong selama sejam dan tidak belajar apa-apa.

Inilah mitos yang wajar dibunuh dahulu: terowong yang berfungsi bukan jalan balik masuk. Ia sambungan rangkaian baharu dengan soalan kepercayaannya sendiri, dan boleh membuang laluan pengurusan lama anda secara senyap sambil membuka satu yang baharu yang tiada siapa semak.

Terowong itu tidak pernah menjadi laluan pengurusan

Pemajuan dan input ialah kerja yang berbeza. "Bolehkah klien mencapai NAS melalui terowong?" ialah soalan pemajuan tentang paket yang melalui penghala. "Bolehkah saya membuka port SSH penghala?" ialah soalan input tentang paket yang dialamatkan kepada penghala itu sendiri. Peraturan izin yang ditulis untuk trafik yang dimajukan tidak melakukan apa-apa untuk soalan kedua, dan itulah sebab paling biasa sebuah terowong yang membawa trafik dengan sempurna masih menolak sesi admin anda.

Kesilapan sebaliknya ialah mempercayai nama antara muka. Terowong disulitkan kepada rakan, bukan kepada setiap perkhidmatan di belakangnya, dan perkataan VPN pada label antara muka tidak mengatakan apa-apa tentang sumber mana yang patut dibenarkan log masuk.

Lapisan satu: adakah laluan ke alamat penghala itu sendiri?

Mulakan pada klien dan tanya kernel ke mana paket akan pergi. Pada Linux, ip route get 10.6.0.1 mencetak laluan yang dipilih, antara muka keluar dan alamat sumber. Jika ia melaporkan laluan lalai menuju penyedia anda, paket itu tidak pernah masuk ke terowong, dan tiada peraturan pada penghala dapat menyelamatkannya.

Sisi terowong mempunyai versi soalan itu sendiri. WireGuard menganggap AllowedIPs sebagai jadual penghalaan kunci kripto: di setiap hujung ia menyatakan alamat sumber mana yang boleh digunakan rakan dan destinasi mana yang dihantar kepada rakan itu. Jika entri klien tidak merangkumi alamat terowong penghala, klien tiada laluan ke sana. Jika entri pelayan untuk klien itu tidak meliputi alamat terowong klien, pelayan membuang paket sebelum mana-mana peraturan tembok api dirujuk.

Sahkan alamat tepat yang anda jangkakan untuk dicapai sebelum menyahpepijat dasar. Rekod DNS yang lapuk atau entri jiran yang dicache dari sebelum perubahan menghantar anda ke alamat yang tidak pernah dimiliki penghala.

Lapisan dua: dasar input, bukan dasar pemajuan

Tembok api menilai peraturan pada antara muka tempat paket tiba. Pada pfSense dan OPNsense, tab antara muka dan susunan peraturan menentukan sama ada trafik ke perkhidmatan tembok api itu sendiri dibenarkan; peraturan yang membenarkan klien LAN keluar ke internet bukan peraturan yang membenarkan rakan terowong membuka GUI web. Pada OpenWrt dengan firewall4, setiap zon membawa dasar input, option input 'ACCEPT' atau 'REJECT', dan antara muka terowong dalam zon dengan input REJECT akan menolak sambungan pengurusan sambil masih memajukan trafik jika pemajuan dibenarkan.

Jangan nyahaktifkan peraturan anti-lockout supaya laluan baharu berfungsi. Peraturan itu menghalang peraturan buruk mengunci alamat pengurusan LAN; ia melindungi subnet LAN, bukan subnet terowong yang baru anda buat. Tambah satu peraturan sempit untuk sumber pentadbir dan biarkan jaring keselamatan itu. Dokumentasi pfSense tentang akses admin menerangkan di mana kawalan 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: adakah sesuatu mendengar pada alamat itu?

Perkhidmatan boleh berjalan dan masih tidak dapat dicapai kerana ia terikat pada satu alamat. uhttpd OpenWrt menyimpan entri pendengar eksplisit dalam /etc/config/uhttpd, contohnya list listen_http '0.0.0.0:80'; binaan yang mengikat hanya pada alamat LAN tidak menerima apa-apa pada alamat terowong, dan produk yang mendedahkan tetapan antara muka pendengar berkelakuan sama. Perintah pendengar di atas menjawab perkara ini secara langsung.

Kemudian pisahkan penolakan daripada kesenyapan. nc -vz 10.6.0.1 443 yang memulangkan sambungan ditolak bermakna paket itu sampai ke penghala dan sesuatu menolaknya, sama ada port tertutup atau peraturan penolakan eksplisit. Tergantung sehingga tamat masa bermakna paket itu dibuang atau tidak pernah dihalakan. Perbezaan itu memberitahu anda lapisan mana untuk diperiksa seterusnya, dan ia mengambil masa lima saat.

Antara muka VPN ialah sempadan, bukan laluan pemulihan

Penyulitan melindungi wayar; ia tidak mengatakan apa-apa tentang siapa yang boleh membuka halaman admin. Selepas terowong berfungsi, tahan dorongan untuk menyelesaikan kebolehcapaian dengan membenarkan segala-galanya pada antara muka terowong. Beri pentadbir peraturan yang terikat pada alamat terowong mereka sendiri atau terowong berasingan khusus admin, dan jauhkan pengguna biasa, NAS, kamera dan komputer riba keluarga daripada port pengurusan. Rakan yang memerlukan perkongsian fail tidak sepatutnya berada satu peraturan daripada log masuk penghala.

Peranan penghala mengubah jawapannya. Penghala yang menamatkan terowong boleh menerima pentadbir daripadanya secara sah, manakala penghala yang hanya menggunakan terowong sebagai jalan keluar internet biasanya tidak sepatutnya. Dalam kedua-dua kes, kebenaran subnet bukanlah log masuk, jadi biarkan pengesahan akaun dan keselamatan pengangkutan dihidupkan.

Langkah pampasan yang orang lakukan selepas terkunci lebih buruk: menghidupkan pentadbiran WAN atau memajukan port ke GUI web. Itu mengubah gangguan singkat menjadi pendedahan kekal, dan halaman log masuk kemudian boleh dicapai oleh setiap pengimbas di internet. Uji juga sisi yang ditolak, bukan hanya yang dibenarkan, supaya rakan yang tidak sepatutnya mempunyai akses admin menerima tamat masa atau penolakan dan bukannya gesaan log masuk.

Uji juga dengan sambungan baharu. Tembok api berkeadaan menyimpan aliran sedia ada dalam jadual keadaannya, jadi sesi SSH yang sudah anda buka boleh bertahan daripada perubahan yang menyekat setiap sambungan baharu. Itulah cara lockout kekal tidak kelihatan sehingga but semula seterusnya atau tidur komputer riba seterusnya.

Sediakan jalan balik sebelum anda menyentuh dasar

Tulis empat perkara sebelum perubahan pertama: bagaimana anda akan mencapai peranti jika terowong mati, seperti konsol bersiri, konsol penyedia atau mesin di LAN; ke mana konfigurasi semasa dieksport; peraturan atau laluan tunggal mana yang anda akan ubah; dan bagaimana anda akan mengembalikan item itu dengan tepat. Pada OpenWrt, sysupgrade -b /tmp/backup.tar.gz menangkap konfigurasi, dan suntingan kekal tergantung sehingga uci commit, yang memberi anda pembatalan murah jika anda perasan tepat pada masanya. pfSense menyimpan sejarah konfigurasi, dan AutoConfigBackup hanya membantu jika ia sudah dihidupkan. Jika penghala menjalankan set peraturan fail-closed, sahkan bahawa laluan penyelenggaraan yang anda rancang tidak berada di dalam trafik yang disekat oleh peraturan itu, dan ingat bahawa but semula menggunakan semula peraturan berterusan dan bukannya memadamkannya.

Ubah satu sempadan setiap percubaan, kemudian uji dari sambungan baharu dan bukannya dari shell yang anda biarkan terbuka. Jika ujian gagal, kembalikan satu perubahan itu sebelum menyentuh lapisan seterusnya. Terowong boleh kekal naik sepanjang masa, tetapi ikon status hijaunya bukan bukti bahawa anda masih boleh masuk.

Semakan pantas sebelum anda pergi:

• Bolehkah anda mencapai penghala dari sumber yang tidak bergantung pada peraturan yang baru anda sunting?
• Adakah dasar input pada antara muka terowong hanya membenarkan sumber pentadbir?
• Adakah perkhidmatan pengurusan terikat pada alamat yang wujud pada terowong?
• Adakah anda menguji satu rakan yang ditolak dan satu sesi baharu?
• Adakah permukaan pentadbiran WAN masih tertutup?