Egress IPv6 mati selepas OpenVPN dimulakan semula: semak pemilikan prefiks
IPv6 mati selepas terowong dicipta semula. Tentukan siapa memiliki prefiks yang diwakilkan, alamat klien dan laluan pulang sebelum memulakan semula apa-apa.
IPv6 berhenti menghantar trafik pada saat OpenVPN dimulakan semula, dan IPv4 terus berfungsi. Antara muka terowong dicipta semula, dan sesuatu yang lain yang menguruskan keadaan IPv6-nya sama ada kehilangan alamat atau kehilangan laluan yang menjadikan prefiks itu boleh dicapai. Terdapat tiga bahagian keadaan yang berasingan, dan setiap satu mempunyai pemilik yang berbeza: prefiks yang diwakilkan oleh penyedia dan jangka hayatnya, alamat yang diberikan kepada klien VPN, dan laluan huluan yang menghantar prefiks klien itu kembali ke pelayan. Kenal pasti pemilik setiap satu sebelum menyentuh mana-mana daemon, kerana memulakan semula yang salah menyembunyikan masalah selama sehari dan mengembalikannya pada sambungan seterusnya.
Tiga bahagian keadaan IPv6, tiga pemilik
| State | Typical owner | What breaks when it is wrong |
|---|---|---|
| Delegated prefix and lifetime | Upstream router or provider via DHCPv6-PD | Clients keep addresses that the upstream no longer routes |
| Client addresses inside the tunnel | OpenVPN server config or a delegation daemon | No global address, or an address outside the routed prefix |
| Return route for the client prefix | Upstream router, or the server's own routing table | Outbound works, replies never arrive |
Alamat dengan skop global di dalam terowong tidak mencukupi dengan sendirinya. Penghala huluan masih perlu menghantar prefiks itu kembali ke pelayan VPN, dan mereka tidak akan melakukannya kerana pelayan kebetulan mempunyai alamat daripadanya.
Itulah sebabnya menyalin /64 awam ke dalam kumpulan terowong juga berisiko. Prefiks yang dihalakan ke pelayan bukan sama dengan prefiks yang dianggap on-link oleh bahagian huluan, dan penemuan jiran tidak akan mengisi jurang itu.
Baca keadaan pelayan sebelum mengubah apa-apa
Tangkap keadaan dua kali, sekali semasa IPv6 berfungsi dan sekali selepas dimulakan semula, kemudian bandingkan. Paparan baca sahaja sudah memadai, dan ia tidak memerlukan kos semasa tetingkap penyelenggaraan:
ip -6 addr show
ip -6 route show table all
ip -6 rule show
sysctl net.ipv6.conf.all.forwardingCari tiga perbezaan khusus: laluan yang hilang, alamat yang beralih kepada jangka hayat usang atau tidak sah, dan prefiks yang berubah selepas perwakilan semula sementara konfigurasi VPN masih mengiklankan yang lama.
Jika alamat hilang tetapi prefiks tidak berubah, daemon yang menetapkannya berhenti menguruskan antara muka. Jika prefiks berubah tetapi alamat tidak, konfigurasi klien sudah usang. Kedua-dua kegagalan kelihatan sama dari pelayar dan tidak mempunyai apa-apa persamaan.
Tentukan sama ada dhcpcd patut menguruskan terowong
dhcpcd boleh menemui antara muka dan mewakilkan bahagian prefiks DHCPv6 kepada antara muka hiliran, dan konfigurasinya boleh menamakan sasaran perwakilan secara eksplisit. Tanpa sasaran eksplisit, tingkah laku terdokumentasinya boleh melibatkan antara muka lain, dan begitulah terowong berakhir dengan alamat yang tiada siapa merancang.
Dua syarat patut mendorong anda menyerahkan pengalamatan statik terowong kepada OpenVPN: pelayan menolak alamat tetap dalam konfigurasinya, dan nama terowong berubah semasa sambung semula. Jika kedua-duanya benar, kecualikan terowong daripada daemon perwakilan secara sengaja, dengan komen yang menyatakan sebabnya.
Jika sebaliknya perwakilan ke terowong itu disengajakan, laksanakan pengendalian perubahan prefiks. Itu bermakna bertindak balas apabila prefiks yang diwakilkan atau jangka hayatnya berubah, mengemas kini prefiks klien yang diiklankan pelayan, dan menambah laluan itu semula. Mengecualikan antara muka dalam reka bentuk itu menghapuskan satu-satunya komponen yang mengetahui prefiks baharu.
Memulakan semula dhcpcd mungkin kelihatan membaiki keadaan kerana ia mencipta semula keadaan, tetapi ia juga memperbaharui atau menarik balik konfigurasi untuk antara muka yang anda tidak fikirkan. Pemulihan itu tidak menjadikannya keperluan selepas setiap permulaan semula VPN. Ia juga menetapkan semula pembilang yang anda gunakan sebagai bukti. Utamakan muat semula bersasar bagi antara muka yang benar-benar anda ubah.
Sahkan IPv6 secara berasingan daripada NAT IPv4
Pastikan penghantaran ke hadapan diaktifkan dan laluan huluan menunjuk ke prefiks klien sebenar, kemudian buat sambungan IPv6 baharu yang dibenarkan. Semak juga jadual laluan IPv6 klien itu sendiri, kerana klien yang memaparkan alamat awam tidak membuktikan bahawa permintaannya menggunakan terowong.
Penyamaran IPv4 menyelesaikan masalah lain: laluan pulang untuk sumber peribadi. Ia tidak melakukan apa-apa untuk prefiks IPv6 yang ditarik balik, dan menambahnya tidak akan mengembalikan IPv6.
Tutup dengan rekod pemilikan: komponen mana yang mewakilkan prefiks, yang mana menetapkan alamat klien, yang mana memegang laluan pulang, dan apa yang berlaku kepada setiap satu semasa sambung semula. Empat baris dalam runbook menyelamatkan orang seterusnya daripada memulakan semula tiga daemon untuk mencari yang benar-benar penting.