Cara mengkonfigurasi rute IPv6 secara otomatis

Saya mengkonfigurasi router sederhana yang harus menyediakan konektivitas IPv6 ke mesin yang ada di LAN di belakangnya. Router memiliki 2 antarmuka jaringan (eth0, eth1), mesin memiliki 1 (eth0).

Pada eth0 router adalah akses hanya ke jaringan lokal, pada eth1 adalah akses ke internet. Saya mengkonfigurasi semua parameter kernel, itu berfungsi ok.

IP dari router adalah fd00::1, saya menginstal dhcpd pada router dan range yang sudah dikonfigurasi fd00::100 - fd00::fffe.

Ketika saya memulai beberapa mesin di jaringan ini, ia mendapat IP dari dhcpd, misalnya fd00::fffa, tetapi tidak dapat mengakses internet karena alasan yang jelas - ia kehilangan rute.

Ketika saya menambahkan rute dengan tangan sudo route -6 add 2000::/3 gw fd00::1, mesin mulai memiliki akses ke internet sampai saya reboot.

Saya dapat menambahkan rute ini dengan tangan ke dalam skrip init dari setiap mesin, tetapi saya lebih suka memilikinya konfigurasi otomatis sehingga ketika saya memulai mesin di jaringan ini ia mendapatkan akses ke internet IPv6 tanpa perlu hal lain.

Berdasarkan beberapa saran saya menginstal juga radvd di router dan memasukkan opsi ini:

route 2000::/3 {};

Kemungkinan besar salah, tetapi saya tidak dapat menemukan dokumentasi atau contoh. Itu tidak bekerja. Menggunakan radvd bukannya dhcpd untuk menetapkan alamat IPv6 tidak berfungsi sama sekali, jika saya menonaktifkan mesin dhcpd secara otomatis mengkonfigurasi beberapa alamat IPv6 acak dan bahkan tidak melihat satu sama lain, mereka juga tidak dapat melakukan ping router.

Bagaimana cara saya mengatur LAN saya untuk mengkonfigurasi otomatis IPv6 untuk semua mesin di dalamnya?

Catatan: Saya tidak perlu dan saya ingin setiap mesin memiliki IPv6 publik, NAT baik-baik saja.

— Petr
sumber

Dengan komunikasi DHCPv4 / IPv4 (yang saya sadari bukan yang Anda tanyakan, tetapi kemungkinan serupa), informasi perutean (termasuk "gateway default") mungkin lebih opsional; arah mungkin tergantung pada perangkat lunak apa yang digunakan. Sepertinya router Anda memberikan alamat dengan DHCPv6. Mengapa Anda tidak berbagi dengan kami router yang Anda gunakan? Juga, sistem operasi apa yang Anda gunakan (mungkin Unix-ish, karena Anda menyebutkan sudo), dan apa klien DHCP (mis. DHCP dhclient ISC, atau dhcpcd?) Rincian ini mungkin diperlukan jika Anda menginginkan arahan spesifik dan berlaku.

— TOOGAM

Ini hanya sebuah kotak linux dengan 2 antarmuka, yang seharusnya cukup untuk sebuah router, saya kira :)

— Petr

Saya segera menemukan dua masalah dengan konfigurasi Anda. Alamat RFC 4193 tidak bisa dialihkan secara global. Itu berarti alamat-alamat itu tidak akan dapat berkomunikasi dengan dunia luar.

Tentu Anda dapat menggunakan NAT, tetapi NAT diketahui menyebabkan banyak masalah. NAT adalah solusi yang dimaksudkan untuk sementara waktu mengatasi kekurangan alamat IP. IPv6 memecahkan masalah itu. Semua masalah lain yang orang coba pecahkan dengan menggunakan NAT memiliki solusi yang lebih baik yang tidak melibatkan NAT.

Selain itu, awalan Anda jelas tidak dihasilkan sesuai dengan spesifikasi di RFC 4193. Kutipan yang relevan:

Global ID yang ditugaskan secara lokal HARUS dibuat dengan algoritma pseudo-acak

Apakah kedua masalah ini dalam konfigurasi jaringan mencegah klien berkomunikasi secara eksternal, Anda hanya akan mengetahuinya dengan mengujinya. Ada perangkat lunak, yang mencoba mendeteksi konfigurasi IPv6 suboptimal dan sepenuhnya menghindari penggunaan IPv6 jika ada yang terdeteksi. Sangat masuk akal bahwa beberapa perangkat lunak klien akan menolak untuk menggunakan koneksi IPv6 dalam pengaturan Anda.

Yang mengatakan itu bukan tidak mungkin untuk mendapatkan klien untuk berkomunikasi secara eksternal menggunakan alamat RFC 4193. Ini adalah radvd.conffile, yang saya gunakan secara singkat di masa lalu. Dengan konfigurasi ini, beberapa klien berupaya berkomunikasi secara eksternal menggunakan alamat RFC 4193 yang ditetapkan.

interface wlan0 { 
        AdvSendAdvert on;
        MinRtrAdvInterval 3; 
        MaxRtrAdvInterval 10;
        prefix fdbd:5df9:dca3::/64 { 
                AdvOnLink on;
                AdvAutonomous on; 
                AdvRouterAddr on; 
        };
};

Namun konfigurasi ini tidak berfungsi dengan semua klien. Saya mengujinya lagi dengan klien yang menjalankan Android. Telepon memang mendapatkan alamat IPv6 yang dikonfigurasi, tetapi tidak mencoba menggunakan IPv6 untuk komunikasi eksternal.

Saya kemudian mengubah awalan menjadi 2001:db8:dca3::/64, pada titik mana telepon mulai mengirim paket IPv6 ke gateway. Jadi Android adalah salah satu contoh platform yang menolak menggunakan alamat RFC 4193 dengan cara ini.

— kasperd
sumber

Saya tidak melihat bagaimana ini bukan rentang yang valid, bahkan pseudo random generator secara teori dapat menghasilkan awalan yang hanya terdiri dari nol, jadi jika beberapa perangkat lunak memiliki hardcoded bahwa alamat tersebut tidak valid itu adalah bug dalam perangkat lunak itu. Selain itu seperti yang saya katakan mesin dapat terhubung ke internet menggunakan alamat ini, tetapi hanya jika saya menambahkan rute, yang sangat masuk akal. Saya hanya bertanya-tanya apakah mungkin untuk mengumumkan rute ini entah bagaimana sehingga setiap mesin mengkonfigurasi secara otomatis.

— Petr

@Petr Tentu saja generator nomor acak dapat menghasilkan kisaran itu. Tetapi saya tahu bahwa beberapa orang melanggar RFC dan memilih dari subset yang jauh lebih kecil dari awalan yang valid. Dari informasi ini saya sampai pada kesimpulan, bahwa lebih mungkin untuk fd00::/48muncul karena pelanggaran RFC, daripada karena kesempatan acak dalam implementasi yang sesuai dengan RFC. Itu tidak berarti bahwa masuk akal bagi perangkat lunak klien untuk mencoba mendeteksi awalan non-acak dan menolak untuk menggunakannya karena itu.

— kasperd

@Petr Alasan awalan non-acak dapat menyebabkan masalah adalah karena risiko tabrakan yang jauh lebih tinggi. Ini benar-benar valid untuk jaringan untuk memiliki beberapa buah perangkat lunak yang dengan awalan acak yang dihasilkan sendiri untuk digunakan untuk beberapa tujuan. Mereka akan sangat tidak mungkin bertabrakan. Tapi hanya butuh dua awalan yang salah pilih untuk menghasilkan tabrakan dengan probabilitas tinggi. Jadi setiap kali saya melihat awalan RFC 4193 yang tidak terlihat acak, saya tahu ini berarti tabrakan lebih mungkin terjadi, dan karenanya merupakan salah satu sumber masalah yang mungkin untuk diselidiki.

— kasperd

@Petr Apa yang masuk akal bagi klien untuk ditolak adalah penggunaan awalan RFC 4193 secara umum. Karena itu dimaksudkan hanya untuk penggunaan lokal, tidak ada jaminan, bahwa mereka akan bekerja secara eksternal. Dalam keadaan itu, vendor perangkat lunak mungkin berharap menggunakan IPv4-saja menjadi lebih andal jika satu-satunya alamat IPv6 adalah alamat RFC 4193. Saya tidak tahu ada contoh spesifik perangkat lunak yang menolak alamat RFC 4193, namun saya tahu bahwa Chromium menolak alamat Teredo karena alasan yang sama persis.

— kasperd

@Petr Saya tidak tahu pasti apakah perangkat lunak konfigurasi otomatis akan menerima alamat RFC 4193 tetapi menolak untuk mengkonfigurasi otomatis gateway default dalam kasus itu. Mengingat bahwa alamat RFC 4193 tidak seharusnya digunakan secara global, itu adalah ide yang saya dapat dengan mudah membayangkan pengembang datang dengan. Pengembang terkadang menerapkan batasan seperti itu tanpa memikirkan implikasinya, tetapi OTOH juga mungkin ada yang melakukannya setelah mengidentifikasi setidaknya satu alasan bagus untuk melakukannya. Jika ada yang melakukan ini, maka secara manual menambahkan rute akan mengatasi masalah ini.

— kasperd