OpenVPN iroute lawan laluan kernel: mana satu hilang?

Paket untuk 10.77.20.0/24 membuat dua keputusan berasingan pada pelayan OpenVPN: sistem pengendalian mesti menyerahkannya kepada antara muka VPN, dan OpenVPN mesti tahu klien bersambung mana yang memiliki awalan itu. Laluan kernel yang hilang menggugurkannya sebelum terowong, laluan rakan sebaya yang hilang menggugurkannya selepas itu. Kedua-dua kegagalan kelihatan sama dari LAN jauh, dan mendiagnosis mana satu yang anda ada memerlukan satu arahan pada setiap sisi.

Dalam laluan data ruang pengguna klasik, laluan kernel membawa paket ke proses terowong dan iroute memberitahu proses itu rakan sebaya mana yang patut menerimanya. Tiada satu pun menggantikan yang lain, dan konfigurasi yang hanya membawa satu daripadanya akan kelihatan munasabah sehingga ping pertama.

Dua keputusan, bukan satu laluan

Bayangkan pautan tapak-ke-tapak di mana 10.77.20.0/24 terletak di belakang satu klien. Laluan kernel pelayan, contohnya ip route add 10.77.20.0/24 dev tun0, menghantar paket yang sepadan ke peranti terowong. OpenVPN kemudian merujuk jadual dalamannya sendiri, yang dibina daripada entri iroute dalam direktori konfigurasi klien, untuk memutuskan sambungan rakan sebaya mana yang menerimanya. Tanpa laluan kernel paket tidak pernah sampai ke proses, dan tanpa laluan rakan sebaya ia sampai ke proses dan tidak ke mana-mana.

Pemisahan itu mudah dilupakan, kerana satu baris laluan dalam profil klien boleh kelihatan melakukan kedua-dua tugas. Ia tidak: menolak laluan memberitahu klien apa yang perlu dihantar melalui terowong, manakala iroute memberitahu pelayan siapa memiliki julat alamat di belakang klien. Kedua-duanya hidup dalam fail berbeza, dibaca oleh sisi berbeza, dan gagal dalam arah yang bertentangan.

Di mana iroute berada dan apa yang dikatakannya

Entri itu masuk ke fail setiap klien yang dinamakan sempena common_name klien, di bawah client-config-dir, sebagai iroute 10.77.20.0/24. Padanan nama fail bukan kosmetik: OpenVPN mencari identiti yang disahkan dan membaca fail dengan nama itu tepat, jadi fail bernama site-a hanya berkesan untuk klien yang nama umumnya site-a. Tambah ccd-exclusive jika klien tanpa fail sedemikian harus ditolak sepenuhnya, iaitu tetapan yang betul apabila setiap klien ialah get laluan tapak. Kekalkan satu fail bagi setiap get laluan dan namakannya sempena subjek sijil yang benar-benar anda keluarkan.

Uji entri itu dari pelayan sebelum menyalahkan LAN jauh. Fail status menyenaraikan klien bersambung dengan nama umum mereka, dan pelayan yang berjalan dengan --verb 4 merekod pemasangan iroute apabila rakan sebaya bersambung. Jika tiada apa-apa muncul semasa sambungan, fail itu berada dalam direktori yang salah atau menamakan identiti yang salah.

Perangkap: fail ada, identiti salah

iroute yang kelihatan betul tetapi terikat pada rakan sebaya yang salah membuang lebih banyak masa daripada fail yang hilang, kerana semuanya pada cakera kelihatan betul. Penamaan semula sijil, nama umum pendua, dan username-as-common-name yang mengubah identiti berkesan semuanya menghasilkannya. Periksa identiti mana yang disahkan oleh pelayan, bukan yang anda jangkakan: keluaran status adalah muktamad, manakala nama fail hanyalah kunci carian.

Laluan juga boleh hidup lebih lama daripada pemiliknya. Laluan statik dan entri iroute menerangkan awalan, bukan jaminan ketersediaan, jadi trafik boleh terus dihalakan ke arah rakan sebaya yang kini terputus.

Selesaikan laluan melepasi rakan sebaya

Pemilikan rakan sebaya ialah pertengahan laluan, bukan penghujungnya. Klien mesti memajukan paket dari terowong ke LAN-nya, yang bermaksud pemajuan IP dihidupkan pada hos itu dan peraturan tembok api membenarkan laluan itu. Hos di LAN jauh memerlukan laluan balik untuk alamat terowong: sama ada laluan yang menunjuk kembali ke get laluan, atau reka bentuk NAT yang disengajakan di sisi klien. Sahkan tetapan pemajuan pada klien dengan sysctl net.ipv4.ip_forward dan bukannya menganggap nilai lalai pengedaran.

Jika klien VPN lain mesti mencapai subrangkaian itu, susunannya bertambah lagi: pelayan memerlukan client-to-client, dan klien itu mesti menghalakan awalan melalui terowong. Tiada satu pun daripada itu tersirat oleh jadual laluan pelayan itu sendiri.

Sahkan satu destinasi dari sumber sebenar dan bukannya dari pelayan itu sendiri. Ping dari hos LAN yang tidak berkaitan ke hos di belakang klien menguji laluan balik, peraturan pemajuan dan pemilikan rakan sebaya dalam satu gerakan, manakala jabat tangan yang berjaya hanya membuktikan identiti. Kemudian putuskan rakan sebaya pemilik dan catat apa yang dilakukan laluan itu, kerana jawapan itu ialah mod kegagalan anda.