Handshake OpenVPN di Synology Gagal? Semak Pemajuan LAN

Komputer riba anda melaporkan bahawa handshake TLS gagal, jadi godaannya ialah membina semula sijil. Sebelum itu, tanya soalan yang lebih membosankan: port Ethernet manakah yang sebenarnya didengari oleh Synology? NAS dengan dua port LAN mempunyai dua alamat, dan pakej VPN Server dalam DSM mengikat pendengar OpenVPN-nya pada salah satunya. Apabila penghala memajukan 1194 ke alamat yang lain, tiada paket pernah sampai ke perkhidmatan, dan klien tiada apa-apa untuk dirundingkan.

Teks ralat mengelirukan kerana ia menerangkan perkara terakhir yang dicuba klien, bukan perkara pertama yang menjadi kacau. Dua minit membandingkan halaman pakej dengan peraturan penghala menyelesaikannya.

Cari alamat tempat pendengar terikat

DSM melabel portnya sebagai LAN 1 dan LAN 2, dan setiap satu membawa alamat serta subrangkaian yang berasingan. Buka VPN Server, baca antara muka yang dinamakan pada tab OpenVPN, kemudian buka Panel Kawalan dan catat alamat IPv4 yang dimiliki DSM pada antara muka yang sama. Dua nilai itulah, bukan nama hos NAS, yang mesti dinamakan oleh pemajuan.

Kabel kedua yang dipasang tidak mencipta pendengar kedua. Kedua-dua pautan boleh kelihatan bersambung sedangkan hanya satu alamat menerima trafik, dan apabila kedua-dua antara muka berada dalam subrangkaian yang sama, dua alamat itu berbeza satu digit yang tiada siapa baca semula sebelum peraturan disimpan.

Lihat soket itu sendiri melalui SSH, kerana hanya di sini ditunjukkan kepada apa daemon benar-benar terikat, bukan apa yang dimaksudkan oleh halaman tetapan.

sudo netstat -anp | grep 1194

Sunting pemajuan sedia ada dan bukannya menambah yang lain

Dua peraturan untuk satu port luaran membiarkan penghala bebas memilih, dan yang mana ia pilih boleh berubah selepas kemas kini firmware atau but semula. Buka peraturan yang sudah ada, ubah alamat dalamannya, simpan, kemudian buka semula dan baca nilainya. Menamakan peraturan sempena perkhidmatan membantu, kerana senarai lima pemajuan yang serupa ialah cara yang salah terus hidup.

external 1194/udp  ->  192.0.2.20:1194/udp

Kekalkan port dalaman sama dengan port mendengar, dan kekalkan protokol secara konsisten. UDP 1194 ialah pendengar lalai, manakala profil TCP memerlukan pendengarnya sendiri di sebelah pakej dan pemajuan yang sepadan pada penghala. Memajukan TCP ke perkhidmatan yang hanya mendengar UDP menghasilkan kesunyian, bukan ralat.

Jika alamat NAS datang daripada DHCP, tempahkannya sebelum peraturan disimpan. Tamat pajakan menetapkan semula alamat, pemajuan terus menunjuk ke nilai lama, dan handshake mula gagal pada hari yang tiada siapa menyentuh NAS. Konfigurasi statik di sebelah NAS menyelesaikan masalah yang sama, dengan syarat alamat itu berada di luar julat DHCP penghala.

Buktikan sama ada paket benar-benar tiba

Mulakan tangkapan pada NAS dahulu, kemudian sambung dari klien, dan baca alamat sumber dalam output. Tangkapan yang dimulakan selepas kegagalan tidak menunjukkan apa-apa dan tidak membuktikan apa-apa.

sudo tcpdump -i any -n udp port 1194

Kesunyian bermakna trafik mati sebelum perkhidmatan: alamat dalaman yang salah, port tertutup pada tembok api DSM, atau antara muka yang dimatikan secara pentadbiran. Paket dalam output bermakna pemajuan berfungsi, dan baki kerosakan berada di atas lapisan rangkaian, iaitu kawasan carian yang jauh lebih kecil.

Tangkapan juga menamakan antara muka tempat paket tiba, dan satu butiran itulah yang memisahkan peraturan yang ditujukan ke port salah daripada peraturan yang ditujukan ke port yang tidak aktif. Perhatikan pembilang penghala sendiri semasa percubaan yang sama jika ia menunjukkannya. Pembilang yang tidak bergerak sementara tangkapan kekal kosong menunjuk kepada penghala, manakala pembilang yang bergerak dengan tangkapan kosong menunjuk kepada laluan antara dua peranti.

Apabila paket tiba, berhenti menyalahkan pemajuan

Profil ialah suspek seterusnya, dan sebab biasa ialah usia. Fail .ovpn yang dieksport mengandungi pihak berkuasa dan bahan dari saat eksport, jadi pakej yang sijilnya diganti kemudian akan menolak klien yang masih membawa salinan lama.

Pengangkutan ialah percanggahan lain yang wajar diperiksa secara eksplisit, kerana profil dan pakej disunting di tempat yang berbeza. Menukar profil daripada UDP ke TCP tanpa menukar pakej menyebabkan klien menunggu pendengar yang tidak wujud, dan klien melaporkan teks handshake generik yang sama seperti untuk segala-galanya. Baca baris proto dalam fail, kemudian lihat protokol yang dipilih pada halaman pelayan, dan hanya selepas itu simpulkan kedua-duanya sepadan. Membaca peraturan tembok api DSM ialah pemeriksaan ketiga: peraturan yang membenarkan port dari subrangkaian tempatan tetapi bukan dari internet mudah ditinggalkan selepas ujian, dan ia menghasilkan sambungan yang berfungsi dari dapur dan gagal dari mana-mana tempat lain.

Uji laluan yang benar-benar dilalui pengguna jauh

Klien dalam LAN yang sama boleh mencapai NAS tanpa pernah menyentuh pemajuan, jadi itu tidak membuktikan apa-apa tentang akses jauh. Gunakan telefon dengan Wi-Fi dimatikan, atau tanya seseorang di luar rangkaian, dan perhatikan pembilang penghala semasa percubaan itu. Jika percubaan jauh gagal sedangkan yang tempatan berjaya, pemajuan atau tembok api masih dalam gambaran.

Catat keadaan yang berfungsi semasa ia berfungsi: port luaran, alamat dalaman, protokol, antara muka pakej, serta nama profil dan tarikh eksport. Apabila handshake gagal lagi, perbezaan antara catatan itu dan konfigurasi semasa ialah kerosakannya, dan tiada siapa perlu menemui semula port mana antara dua port yang digunakan oleh perkhidmatan.