Pilihan terbaik untuk alamat pribadi untuk "jaringan area perangkat"

8

Saya sedang membangun sebuah alat yang terdiri dari beberapa perangkat yang terhubung dengan ethernet di dalam alat. Alat akan terhubung ke jaringan pelanggan. Jaringan pelanggan dapat menggunakan alamat IP pribadi. Konflik alamat dengan jaringan internal akan menjadi masalah (subdevice yang terhubung ke kedua jaringan akan bingung). IPv6 bukan opsi.

Haruskah saya membeli alamat IPv4? Atau mungkin saya bisa menggunakan TEST-NET-3 (203.0.113.0/24) atau sesuatu seperti itu? Apa praktik terbaik?

— proski
sumber

1

Apakah jaringan pelanggan memerlukan akses ke sub-layanan secara langsung atau mereka akan terhubung ke alat hanya melalui port LAN tipe "manajemen" pada alat? Saya bertanya karena EMC dan lainnya menggunakan komunikasi IP fiber pribadi pada SAN mereka untuk pengontrol mereka / dll dengan NIC manajemen khusus yang terhubung ke jaringan pelanggan. NIC mgmt mendapatkan alamat DHCP dari LAN pelanggan atau secara statis ditugaskan untuk berada di jaringan pelanggan.

— TheCleaner

1

Apakah Anda harus menggunakan TCP / IP stack untuk komunikasi antara 'subdevices' Anda? Jika Anda tetap di lapisan dua Anda tidak akan memiliki masalah dengan konflik IP.

— jlehtinen

Jaringan pelanggan hanyalah sarana untuk menghubungkan ke layanan cloud. Dengan demikian gateway default pelanggan tidak boleh tumpang tindih dengan jaringan internal, atau subdevice yang tampak keluar akan menyalahgunakan paket. Salah satu sub-layanan hanya IPv4, tidak ada cara lain untuk mengendalikannya.

— proski

3

"IPv6 bukan opsi." Kami memiliki 2014 sekarang. Itu harus menjadi pilihan. "Haruskah saya membeli alamat IPv4?" Nah, jika Anda bisa - di Asia, mereka kelelahan, di Eropa juga, ...

— glglgl

1

Jika perangkat tidak mendukung IPv6, aku bahkan tidak akan mempertimbangkan membeli mereka, karena saya kemudian akan harus mengganti mereka dengan baik sebelum masa diharapkan dari perangkat, dengan sesuatu yang tidak mendukung IPv6. (Yah, bagi pelanggan. Di jaringan saya, yang sudah memiliki tumpukan ganda, perangkat yang tidak mendukung IPv6 dianggap tidak sesuai untuk tujuan.)

— Michael Hampton

10

@yoonix telah mengirim tautan yang mungkin punya solusi.

Tautan-lokal, juga dikenal sebagai APIPA.

169.254.0.0/16 - Ini adalah blok "tautan lokal". Seperti yang dijelaskan dalam RFC3927, dialokasikan untuk komunikasi antara host pada satu tautan. Host memperoleh alamat ini dengan konfigurasi otomatis, seperti ketika server DHCP tidak dapat ditemukan.

Jika saya adalah pelanggan Anda, saya pasti ingin memiliki opsi untuk mengkonfigurasi ini sendiri dan / atau menggunakan DHCP (yang, saya tidak tahu, mungkin standar lama?), Tetapi tanpa adanya mereka, inilah tepatnya yang seharusnya digunakan APIPA.

Sunting - Mengingat bahwa Anda sekarang menyatakan bahwa alamat IP harus statis untuk masing-masing host di solusi Anda karena itu akan sesuai dengan aturan firewall di perangkat gateway Anda, saya kira itu akan mengambil sedikit usaha di pihak Anda untuk membuatnya bekerja dengan tautan pengalamatan IPv4 lokal; upaya Anda mengatakan Anda tidak akan menghabiskan. Jadi, Anda pada dasarnya harus membuat ini dapat dikonfigurasi. Anda bisa mengirimkannya dengan default, yang lebih kecil kemungkinannya digunakan oleh klien, tetapi Anda harus memiliki mekanisme yang dapat diubah jika terjadi konflik. Baik oleh klien, atau oleh Anda sebagai bagian dari implementasi / UAT.

— mfinni
sumber

Alat ini menggunakan DHCP pada jaringan internal untuk salah satu sub-layanan ( sangat sulit untuk mengkonfigurasi tanpa DHCP). Saya merasa tidak nyaman untuk memiliki server DHCP membagikan alamat IP dalam jangkauan lokal tautan, karena dilarang secara eksplisit: tools.ietf.org/html/rfc3927#section-1.6 Jika kami tidak harus menggunakan DHCP secara internal, itu akan menjadi pilihan pertama saya.

— proski

Tidak, tidak, tidak, seperti yang saya kutip secara eksplisit, alamat APIPA (tautan-lokal) adalah perangkat yang akan ditetapkan untuk diri mereka sendiri jika server DHCP tidak dapat ditemukan. Saya tidak menyarankan Anda menggunakan DHCP untuk menetapkan alamat APIPA.

— mfinni

Subdevice memiliki peran khusus dan router harus mengkonfigurasi iptables sesuai peran tersebut. Saya tidak ingin router menemukan alamat dan mengubah iptables yang sesuai. Juga, menetapkan alamat IP acak berarti akan ada konflik alamat, dan saya tidak yakin perangkat kerasnya cukup pintar untuk menyelesaikannya.

— proski

Baca ini: tools.ietf.org/html/rfc3927 - apa pun yang menggunakan tautan kebutuhan lokal untuk mengimplementasikan deteksi konflik.

— mfinni

Saya tahu itu. Tidak ada cara ini akan diterapkan dalam produk. Subdevice memiliki peran mereka dan ada konfigurasi iptables khusus untuk mereka.

— proski

5

Buat itu bisa dikonfigurasi.

Haruskah saya membeli alamat IPv4?

Ya. COBA ITU. Pertama, Anda tidak membelinya, Anda "menyewanya" dengan keanggotaan. Kedua ini membutuhkan AS dan 2 uplink. Ketiga, ini membutuhkan alasan dan "kami tidak ingin menganggap infrastruktur jaringan yang tepat" adalah alasan yang menghasilkan tawa (dan penolakan), bukan Anda mendapatkan alokasi alamat IP.

Atau mungkin saya bisa menggunakan TEST-NET-3 (203.0.113.0/24)

Mungkin. Sampai suatu hari seseorang meminta oyu untuk biaya memperbaiki barang-barang karena kelalaiannya.

Apa praktik terbaik?

Buat itu bisa dikonfigurasi. Atau gunakan IPV6 - di sana Anda dapat melakukan reservasi.

— TomTom
sumber

Mendapatkan alamat IPv4 untuk penggunaan internal (jadi tidak merutekannya ke internet) adalah kasus penggunaan yang sangat valid. Sayangnya di wilayah APNIC dan RIPE tidak ada lagi alamat IPv4 yang tersisa, jadi pindah ke IPv6 adalah satu-satunya solusi yang terbukti di masa depan ... Alamat ULA terdengar seperti pilihan yang baik di sana.

— Sander Steffann

3

Ini bukan kasus penggunaan yang valid. Tidak dengan ruang alamat IPv4 terbatas. Ini untuk apa alamat pribadi. Dan mereka tidak akan menyia-nyiakannya pada perusahaan "tidak mampu atau tidak mau mengikuti prosedur konservasi yang ditetapkan".

— TomTom

Ini jelas bukan kasus penggunaan yang valid hari ini, saya tidak tahu apakah itu pernah terjadi. Apakah Anda memiliki dokumentasi untuk mendukung pernyataan Anda, @SanderSteffann?

— mfinni

3

@proski ah, tidak. Lihat - addres TEST-NET-3 untuk pengujian. Pelanggan yang menggunakannya untuk pengujian memiliki kasus yang valid. Peralatan pengiriman SOmeone tidak mengetahui atau sengaja mengabaikan kebijakan di sekitar alamat ini, yang merupakan pengabaian besar. Dalam kedua kasus tersebut.

— TomTom

1

@SanderSteffann Saya tidak tahu tentang APNIC, tetapi RIPE tentu saja memiliki alamat IPv4 - sekitar 14 juta di antaranya (0,85 dari a / 8) menurut pembaruan status terbaru di situs web mereka.

— Jules

5

Dari Wikipedia: Assigned as "TEST-NET-3" in RFC 5737 for use solely in documentation and example source code and should not be used publicly.- Ini memberitahu saya bahwa Anda sebaiknya tidak menggunakan TEST-NET-3.
Satu hal yang tampaknya Anda abaikan: Bagaimana Anda mengira bahwa Anda akan dapat berkomunikasi dengan perangkat atau bahwa perangkat akan dapat berkomunikasi dengan perangkat lain dan sebaliknya jika Anda tidak mengkonfigurasi alamat ip perangkat tersebut UNTUK jaringan klien? Jika Anda menetapkan alamat ip dalam jaringan yang tidak digunakan dalam jaringan klien (Anda: 192.168.1.0/24 - Mereka: 10.0.0.0/8) lalu bagaimana menurut Anda bahwa komunikasi jaringan akan berfungsi? Inilah sebabnya mengapa Anda harus mengkonfigurasi perangkat untuk menggunakan DHCP di luar kotak dan memungkinkan klien untuk mengkonfigurasi secara statis sesudahnya.

Jika Anda tidak dapat menggunakan DHCP maka gunakan APIPA.

— joeqwerty
sumber

Tidak akan ada penggunaan publik . Alamat internal tidak akan pernah terbuka ke luar. Komunikasi menggunakan NAT. Tapi saya tidak bisa melakukan NAT ketika kedua jaringan menggunakan alamat yang tumpang tindih.

— Proski

1

OK, tapi jawaban saya bukan tentang NAT. Bagaimana perangkat Anda berkomunikasi dengan perangkat lain di jaringan internal yang sama jika menggunakan alamat ip yang tidak berada dalam subnet yang sama dengan jaringan internal?

— joeqwerty

Jelas, alat ini termasuk router yang memiliki alamat di kedua jaringan. Router melakukan NAT. Pelanggan hanya berbicara ke alat melalui layanan cloud.

— proski

Saya tidak berusaha bersikap angkuh, tetapi bagaimana itu jelas? Kami hanya tahu sebanyak yang Anda katakan kepada kami dalam pertanyaan Anda dan Anda tidak pernah menyebutkan fakta itu.

— joeqwerty

1

Mungkin itu aku. Saya tentu saja tidak bermaksud menyinggung dan mungkin ini akan dianggap tidak sopan tetapi bagaimana pernyataan "subdevice yang terhubung ke kedua jaringan akan bingung" menyiratkan bahwa perangkat memiliki router bawaan atau memiliki fungsi routing? Komputer saya memiliki dua antarmuka jaringan, masing-masing terhubung ke jaringan yang berbeda, tetapi komputer saya bukan router. Mungkin saya bodoh. Saya tidak membaca apa pun dalam pertanyaan Anda yang membuat saya percaya bahwa perangkat Anda memiliki router bawaan atau memiliki kemampuan perutean. Bagaimanapun, kata-kata kasar ini tidak berfungsi untuk membantu Anda jadi saya akan menjatuhkannya pada saat ini.

— joeqwerty

4

Secara teori, rentang IP pribadi apa pun dapat digunakan oleh jaringan pribadi apa pun, jadi saya ragu Anda akan menemukan praktik terbaik, atau apa pun yang akan dapat diterapkan secara universal jika Anda menyandikan alamatnya dengan keras. Praktik terbaik adalah membuatnya dapat dikonfigurasi dan memungkinkan jaringan klien untuk menetapkan perangkat alamat pribadi (melalui DHCP, misalnya).

Jika itu bukan pilihan, saya menemukan bahwa hampir tidak ada orang yang menggunakan bagian atas 172.16.0.0/12, jadi itulah yang saya gunakan. (Saya pikir saya sedang menjalankan 172.25.0.0/16, tepatnya.) Saya belum memiliki tabrakan alamat di atasnya, dan saya VPN ke banyak jaringan pribadi.

Jika Anda harus menggunakan alamat pribadi IPv4, saya pikir itu yang terbaik yang dapat Anda lakukan, dengan 10.0.0.0/8blok yang banyak digunakan dan 192.168.0.0/16blok menjadi default untuk hampir semua, satu-satunya yang tersisa adalah 172.16.0.0/12. Tentu saja, blok ini sering digunakan untuk VPN, untuk menghindari tabrakan alamat, karena meluasnya penggunaan blok jaringan pribadi lainnya, jadi gunakan alamat atas, karena (menurut pengalaman saya) mereka adalah subnet yang paling jarang digunakan dalam blok itu. .

— HopelessN00b
sumber

1

Jika Anda memilih acak / 24 dalam kisaran 10.0.0.0/8, dan mengasumsikan penggunaan alamat oleh perangkat yang ada (yaitu paling banyak segelintir / 24 subnet digunakan - saya cenderung menganggap pengaturan jaringan saya sebagai cukup kompleks, mengingat bahwa ia memiliki 4 subnet [3 lokasi berbeda, dan vpn untuk rute di antara mereka]), kemungkinan konflik adalah <0,01%. Saya biasanya bersedia mengambil risiko ini di sebagian besar keadaan.

— Jules

1

@Jules kecuali untuk jaringan (sayangnya umum) yang menggunakan seluruh / 8 subnet hanya karena itu adalah default.

— Berikan

Rute ke jaringan yang lebih kecil memiliki prioritas, untuk itu harus berfungsi. Saya sebenarnya bisa memiliki / 29 secara internal untuk mengurangi risiko lebih jauh. Tetapi tidak menghilangkan risiko itu, sekecil apa pun, akan menjadi buruk. Dukungan pelanggan perlu tahu tentang hal itu dan memeriksa konfigurasi jaringan pelanggan.

— proski

2

Kami sedang merancang hal yang persis sama dan telah memutuskan untuk pergi dengan alamat lokal situs IPv6 dengan awalan fc00: nnnn acak.

— Michael
sumber

1

Buruk. Dapatkan blok ULA.

— TomTom

1

Dengan asumsi tidak ada sub-layanan ini memerlukan konektivitas langsung di luar alat, Anda harus menggunakan jaringan loopback untuk ini (127.0.0.0/8).

RFC 5735 / Bagian 3

Loopback di Wikipedia

— Yoonix
sumber

3

Bagaimana ini bisa berhasil? "Subdevice" -nya adalah host individual. Loopback adalah untuk tuan rumah untuk berkomunikasi dengan dirinya sendiri.

— mfinni

1

Poin baiknya, aku bersumpah aku pernah melihatnya dulu seperti ini .. tapi aku tidak ingat di mana. Saya akan segera menghapus jawaban saya.

— yoonix

Tapi, dokumen itu punya saran lain yang saya suka!

— mfinni

Sebenarnya, saya sedang berpikir untuk menggunakan 127.0.1.0/255 untuk jaringan internal. Tidak yakin apakah akan lebih baik dari TEST-NET-3.

— Proski

1

BAHWA TIDAK AKAN BEKERJA. Itu loopback. Tuan rumah yang berkomunikasi dengan alamat loopback HANYA AKAN BICARA DENGANNYA. Alamat loopback kebetulan merupakan ukuran dari keseluruhan subnet; masih hanya host-lokal.

— mfinni

1

Dapatkah "pengontrol utama" Anda menjalankan server DHCP / menyediakan penyewaan DHCP pada antarmuka "internalnya"?

Saya telah melakukan sesuatu di masa lalu untuk salah satu produk komersial perusahaan kami yang mungkin berguna. Perangkat ini memiliki dua port ethernet, salah satunya dimaksudkan untuk konektivitas "langsung" dari PC. Masalahnya serupa; kami ingin menghindari konflik alamat IP dengan LAN internal pelanggan (mungkin pada jaringan IP pribadi) serta dengan dunia pada umumnya.

Logika pada perangkat ini adalah mengonfigurasi server DHCP secara dinamis ("udhcpc", melalui opsi baris perintah) pada port LAN "langsung" (eth1) berdasarkan konfigurasi IP sendiri pada port LAN "publik" (eth0). Apakah perangkat memperoleh alamat IP sendiri melalui DHCP atau melalui pengaturan statis, modul yang menerapkan pengaturan juga akan mengubah konfigurasi server DHCP untuk menghindari konflik.

Misalnya, jika perangkat memperoleh alamat 192.168.0.100/netmask 255.255.255.0 (pada eth0), itu akan mengkonfigurasi server DHCP sendiri (pada eth1) untuk jaringan 192.168.1.0/255.255.255.0 yang tersedia berikutnya.

Itu akan memilih dari salah satu jaringan ini (dalam urutan prioritas): 192.168.0.0/24 ... 192.168.254.0/24 172.16.0.0/16 ... 172.31.0.0/16 10.0.0.0/8

Semoga ini membantu.

— pengguna1722483
sumber

Bagaimana jika saya menggunakan 192.168.0.0/16awalan situs saya, tetapi Anda hanya terhubung ke VLAN 192.168.0.0/24? Anda baru saja hi-jacked 192.168.1.0/24meskipun saya menggunakannya di VLAN lain di situs yang sama.

— fukawi2

Itu ide yang bagus dalam teori. Dalam praktiknya, salah satu sub-layanan menggunakan alamat IP statis dan yang lain menggunakan klien DHCP. Tidak dapat dikonfigurasi dalam produk yang dikirim. Dengan demikian alamat harus dikonfigurasikan sebelumnya, tetapi alamat tautan-lokal tidak akan berfungsi.

— proski