Bir "cihaz alanı ağı" için en iyi özel adres seçimi

8

Cihazın içine ethernet ile bağlı birkaç alt cihazdan oluşan bir cihaz yapıyorum. Cihaz müşteri ağına bağlanacaktır. Müşteri ağı özel IP adresleri kullanıyor olabilir. Dahili ağ ile olan bir adres çatışması bir problem olur (her iki ağa bağlı alt cihazların kafası karışır). IPv6 bir seçenek değildir.

IPv4 adreslerini satın almalı mıyım? Ya da belki TEST-NET-3 (203.0.113.0/24) veya bunun gibi bir şey kullanarak kurtulabilirim? En iyi uygulama nedir?

— proski
kaynak

1

Müşteri ağının alt cihazlara doğrudan erişmesi gerekecek mi yoksa cihaza yalnızca cihazdaki "yönetim" tipi bir LAN bağlantı noktası üzerinden mi bağlanacak? EMC ve diğerleri SAN'larında kontrolörleri / vb. İçin müşteri ağına bağlı özel bir NIC yönetimi ile özel fiber IP iletişimi kullandıklarını soruyorum. Mgmt NIC ya müşteri LAN'ından bir DHCP adresi alır ya da statik olarak müşteri ağına yerleştirilmek üzere atanır.

— TheCleaner

1

'Alt aygıtlarınız' arasındaki iletişim için TCP / IP yığını kullanmanız gerekiyor mu? İkinci katman üzerinde kalırsanız, IP çakışmaları ile ilgili herhangi bir sorun yaşamayacaksınız.

— jlehtinen

Müşteri ağı sadece bulut hizmetine bağlanmanın bir yoludur. Bu nedenle, müşterinin varsayılan ağ geçidi iç ağla örtüşmemelidir, aksi takdirde dışa bakan alt aygıtlar paketleri yanlış yönlendirir. Alt aygıtlardan biri yalnızca IPv4'tür, kontrol etmenin başka bir yolu yoktur.

— proski

3

"IPv6 bir seçenek değil." Şimdi 2014 var. Bir seçenek olmalı. "IPv4 adreslerini almalı mıyım?" Eh, eğer yapabilirseniz - Asya'da, onlar da, Avrupa'da da, - ...

— glglgl

1

Cihazlar ise yok IPv6 desteği, hatta alışkanlık düşünün Sonra bir şeyle, cihazın beklenen ömrü çok önce bunların yerine gerekir, çünkü onları satın gelmez IPv6 desteği. (Eh, zaten müşteriler için. Zaten çift yığın olan ağlarımda, IPv6'yı desteklemeyen bir aygıtın amaç için uygun olmadığı düşünülüyor.)

— Michael Hampton

10

@yoonix bir çözümü olabilecek bir link gönderdi.

Yerel bağlantı, APIPA olarak da bilinir.

169.254.0.0/16 - Bu "yerel bağlantı" bloğu. RFC3927'de açıklandığı gibi, tek bir link üzerinde ana bilgisayarlar arasında iletişim için ayrılmıştır. Toplantı sahipleri bu adresleri, bir DHCP sunucusunun bulunamadığı gibi otomatik yapılandırma ile alır.

Müşterin olsaydım, cehennem olarak bunu kendim yapılandırma ve / veya DHCP kullanma seçeneğine sahip olmak isterdim (ki, bilmiyorum, belki de köklü bir standart mı?), Ancak Bunlar, bu tam olarak APIPA'nın kullanılması gereken şey.

Düzenleme - Şimdi, IP adreslerinin çözümünüzdeki ayrı ana bilgisayarlar için statik olması gerektiğini belirttiğinizden, bunlar ağ geçidi cihazınızdaki güvenlik duvarı kurallarına karşılık geleceğinden, bu bağlantıyı yapmak için biraz çaba harcayacağınızı düşünüyorum. yerel IPv4 adresleme; çaba harcamayacağınızı söyleyin. Yani, aslında var bu yapılandırılabilir yapmak. Bir müşteri tarafından kullanılma olasılığı daha düşük olan, varsayılan olarak gönderebilirsiniz, ancak bir çatışma durumunda değiştirilebilecek bir mekanizmanız olmalıdır. Müşteri tarafından veya sizin tarafınızdan uygulama / UAT'nin bir parçası olarak.

— mfinni
kaynak

Cihaz, alt şebekelerden biri için dahili ağda DHCP kullanıyor (DHCP olmadan yapılandırılması çok zor). DHCP sunucusunun yerel ağdaki IP adreslerini açıkça yasakladığından dolayı rahat hissetmiyorum : tools.ietf.org/html/rfc3927#section-1.6 DHCP'yi dahili olarak kullanmak zorunda kalmazsak , benim ilk tercihim olurdu.

— proski

Hayır hayır hayır, açıkça alıntı yaptığım gibi, bir DHCP sunucusu bulunamazsa APIPA (yerel bağlantı) adresleri aygıtların kendilerine atayacakları adreslerdir . APIPA adreslerini atamak için DHCP kullanmanızı önermedim.

— mfinni

Alt aygıtların belirli rolleri vardır ve yönlendiricinin bu rollere göre iptables yapılandırması gerekir. Yönelticinin adresleri bulmasını ve iptables'ı buna göre değiştirmesini istemiyorum. Ayrıca, rasgele IP adresleri atamak, adres çakışmaları olacağı anlamına gelir ve donanımın bunları çözecek kadar akıllı olduğundan emin değilim.

— proski

Bunu okuyun: tools.ietf.org/html/rfc3927 - çatışma tespitini uygulamak için yerel bağlantıları kullanan herhangi bir şey.

— mfinni

Bunu biliyorum. Bunun üründe uygulanmasına imkân yok. Alt aygıtların rolleri vardır ve bunlar için belirli iptables yapılandırmaları vardır.

— proski

5

Yapılandırılabilir hale getirin.

IPv4 adreslerini satın almalı mıyım?

Evet. BUNU DENE. İlk önce, onları satın almazsınız, üyeliğe göre “kiralarsınız”. İkincisi, bu bir AS ve 2 bağlantı gerektirir. Üçüncüsü, bunun bir nedeni var ve "uygun bir ağ altyapısını varsaymak istemiyoruz", IP adresleri tahsis edilmek yerine, kahkaha (ve reddetme) ile sonuçlanan bir neden.

Veya belki de TEST-NET-3 (203.0.113.0/24) kullanarak kurtulabilirim.

Muhtemelen. Güne kadar biri, ihmal nedeniyle işleri tamir etmenin bedelini oyu ister.

En iyi uygulama nedir?

Yapılandırılabilir hale getirin. Veya IPV6'yı kullanın - orada bazı çekinceler ile kurtulabilirsiniz.

— TomTom
kaynak

Dahili kullanım için IPv4 adreslerini almak (bu yüzden onları internete yönlendirmek değil) mükemmel bir kullanım şeklidir. Maalesef, APNIC ve RIPE bölgelerinde artık IPv4 adresi kalmadı, bu yüzden IPv6'ya geçiş gerçekten geleceğe dönük tek çözüm ... ULA, iyi bir seçenek gibi ses çıkarıyor.

— Sander Steffann

3

Geçerli bir kullanım durumu değil. IPv4 adres alanı sınırlı değil. Özel adresler bunun için var. Ve “yerleşik koruma prosedürlerini izleyemeyen veya izlemeye istekli olmayan” şirketlere harcamazlar.

— TomTom

Bugün kesinlikle geçerli bir kullanım durumu değil, hiç olup olmadığını bilmiyorum. @SanderSteffann iddiasını yedeklemek için herhangi bir dokümantasyon var mı?

— mfinni

3

@proski ah, hayır. Bakınız - TEST-NET-3 adresleri test içindir. Test için bunları kullanan bir müşterinin geçerli bir vakası vardır. Bazı nakliye cihazları ya cahildir ya da bu adreslerin etrafındaki politikaları görmezden gelirler, ki bu çok büyük bir ihmaldir. Her iki durumda da.

— TomTom

1

@SanderSteffann APNIC hakkında bir şey bilmiyorum, ancak RIPE'nin web sitelerinde en son durum güncellemesine göre kesinlikle IPv4 adresleri var - yaklaşık 14 milyon tanesi (a / 8'den 0.85).

— Jules

5

Wikipedia'dan: Assigned as "TEST-NET-3" in RFC 5737 for use solely in documentation and example source code and should not be used publicly.- Bu bana TEST-NET-3 kullanmaman gerektiğini söylüyor.
Gözden geçmiş gibi göründüğünüz bir şey: Cihazın ip adresini yapılandırmadıysanız, cihazla iletişim kurabileceğinizi veya cihazın diğer cihazlarla iletişim kurabileceğini ve bunun tersi olacağını nasıl düşünüyorsunuz? İstemci ağı İÇİN? İstemci ağında kullanılmayan bir ağa bir ip adresi atarsanız (Siz: 192.168.1.0/24 - Bunlar: 10.0.0.0/8) o zaman ağ iletişiminin işe yarayacağını nasıl düşünüyorsunuz? Bu nedenle, cihazı DHCP'yi kutudan kullanacak şekilde yapılandırmanız ve müşterinin daha sonra bunu statik olarak yapılandırmasına izin vermeniz gerekir.

DHCP kullanamıyorsanız, APIPA kullanın.

— joeqwerty
kaynak

Halka açık kullanım olmayacak . Dahili adresler asla dışarıya maruz kalmaz. İletişim NAT kullanır. Ancak, her iki ağ da birbiriyle çakışan adresleri kullandığında NAT yapamıyorum.

— proski

1

Tamam, ama cevabım NAT ile ilgili değil. Dahili ağ ile aynı alt ağda olmayan bir ip adresi kullanıyorsa, cihazınız aynı dahili ağdaki diğer cihazlarla nasıl iletişim kuracak?

— joeqwerty

Açıkçası, cihaz her iki ağda da adresleri olan bir yönlendirici içeriyor. Yönlendirici NAT yapar. Müşteri, cihazla yalnızca bir bulut servisi aracılığıyla görüşür.

— proski

Snarky olmaya çalışmıyorum, ama bu nasıl belli oluyor? Sadece sorunuzda bize söylediğiniz kadarını biliyoruz ve bu durumdan hiç bahsetmediniz.

— joeqwerty

1

Belki benim. Kesinlikle herhangi bir suç anlamına gelmez ve belki de bu kabaca ortaya çıkar, ancak “her iki ağa bağlı alt aygıtın kafası karışır” ifadesi, cihazın yerleşik bir yönlendiriciye sahip olduğu veya yönlendirme işlevine sahip olduğu anlamına gelir? Bilgisayarım, her biri farklı bir ağa bağlı iki ağ arabirimine sahip, ancak bilgisayarım yönlendirici değil. Belki de sadece aptalım. Sorunuzda, cihazınızın yerleşik bir yönlendirici olduğuna veya yönlendirme özelliğine sahip olduğuna inanmamı sağlayan hiçbir şey okumam. Her halükarda, bu rant size yardımcı olmaya hizmet etmiyor, bu yüzden onu bu noktaya bırakacağım.

— joeqwerty

4

Teoride, herhangi bir özel IP aralığı herhangi bir özel ağ tarafından kullanılıyor olabilir, bu yüzden adresi zor kodluyorsanız en iyi uygulamayı veya evrensel olarak uygulanabilecek herhangi bir şeyi bulacağınızdan şüpheliyim. En iyi uygulama yapılandırılabilir hale getirmek ve istemci ağının cihaza özel bir adres atamasını sağlamak (örneğin DHCP aracılığıyla) olacaktır.

Eğer bu bir seçenek değilse, kimsenin üst yarısını kullandığını pek görmüyorum 172.16.0.0/12, bu yüzden kullandığım şey bu. (Açıkçası, 172.25.0.0/16kesin olarak çalıştığımı düşünüyorum .) Üzerinde henüz bir adres çarpışması olmadı ve birçok özel ağda VPN kullandım.

Bir IPv4 özel adresi kullanmak zorundaysanız, bence en 10.0.0.0/8yaygın şekilde kullanılan ve 192.168.0.0/16hemen hemen her şey için varsayılan olan blok olacak şekilde yapabileceğiniz en iyi seçenek budur 172.16.0.0/12. Tabii ki, bu blok genellikle diğer özel ağ bloklarının yaygın kullanımı nedeniyle adres çarpışmalarını önlemek için VPN'ler için kullanılır, bu yüzden (benim deneyimime göre) bu blokta en az kullanılan alt ağlar olduklarından üst adresleri kullanın. .

— HopelessN00b
kaynak

1

10.0.0.0/8 aralığında bir rastgele / 24 seçtiyseniz ve adresleri varolan cihazlar tarafından makul bir şekilde kullandığınızı varsayarsak (yani en fazla / 24 alt ağ kullanımdaysa) - ağ kurulumumu şu şekilde düşünüyorum: Oldukça karmaşık, bu tür 4 ağa [3 farklı konum ve bunlar arasında yönlendirme yapmak için bir vpn] olduğu göz önüne alındığında, bir çatışma olasılığı <% 0.01'dir. Genelde çoğu zaman bu riski almak isterdim.

— Jules

1

@Jule, yalnızca varsayılan olduğundan, tüm / 8 alt ağını kullanan ağlar dışında (ne yazık ki yaygın).

— Hibe

Daha küçük bir ağa giden rota önceliklidir, çalışması gerekir. Riski daha da azaltmak için içten / 29’u alabilirdim. Ancak bu riski ortadan kaldırmak, ne kadar küçük olursa olsun, kötü olur. Müşteri desteğinin bunu bilmesi ve müşterinin ağ yapılandırmasını kontrol etmesi gerekir.

— proski

2

Aynı şeyi tasarlıyoruz ve rastgele bir fc00: nnnn öneki ile IPv6 sitesi yerel adreslerine gitmeye karar verdik.

— Michael
kaynak

1

Kötü. Bir ULA bloğu alın.

— TomTom

1

Bu alt cihazlardan hiçbirinin cihazın dışında doğrudan bağlantıya ihtiyaç duymadığını varsayalım, bunun için geridöngü ağını kullanmalısınız (127.0.0.0/8).

RFC 5735 / Bölüm 3

Wikipedia'da Loopback

— yoonix
kaynak

3

Bu nasıl işe yarayabilir? Onun "alt cihazları" bireysel konaklardır. Geridöngü, bir sunucunun kendisiyle iletişim kurması içindir.

— mfinni

1

Güzel, yemin ederim daha önce böyle kullanıldığını gördüm .. ama nerede olduğunu hatırlayamıyorum. Cevabımı kısa sürede kaldıracağım.

— yoonix

Ancak, bu belgenin sevdiğim başka bir önerisi var!

— mfinni

Aslında, iç ağ için 127.0.1.0/255 kullanmayı düşünüyorum. TEST-NET-3'ün daha iyi olacağından emin değilim.

— proski

1

. BU WON "T İŞ O geri döngü var bir döngü adresine iletişim bir konak SADECE KENDİ sözünü edeceğimiz geri döngü adresi bir bütün alt boyutu olur; yine yalnızca ana-yerli...

— mfinni

1

"Ana kontrol cihazınız" bir DHCP sunucusu çalıştırabilir / "iç" arayüzünde DHCP kiralaması sağlayabilir mi?

Geçmişte şirketimizin ticari ürünlerinden biri için yararlı olabilecek bir şey yaptım. Cihaz, biri PC'den "doğrudan" bağlantı için kullanılan iki ethernet portuna sahipti. Sorun benzerdi; IP adresinin bir müşterinin dahili LAN'ında (muhtemelen özel bir IP ağında) olduğu kadar dünyadaki tüm dünyayla da çatışmasından kaçınmak istedik.

Bu cihazdaki mantık, "genel" LAN portunda (eth0) kendi IP yapılandırmasına dayanarak "doğrudan" LAN portunda (eth1) bir DHCP sunucusunu ("udhcpc", komut satırı seçenekleri aracılığıyla) dinamik olarak yapılandırmaktı. Aygıtın kendi IP adresini DHCP üzerinden veya statik ayar yoluyla alması durumunda, ayarı uygulayan modül, çakışmayı önlemek için DHCP sunucusu yapılandırmasını da değiştirir.

Örneğin, aygıt 192.168.0.100/netmask 255.255.255.0 adresini aldıysa (eth0'da), bir sonraki kullanılabilir ağ 192.168.1.0/255.255.255.0 için kendi DHCP sunucusunu (eth1'de) yapılandıracaktı.

Bu ağlardan birinden seçecektir (öncelik sırasına göre): 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

Bu yardımcı olur umarım.

— user1722483
kaynak

192.168.0.0/16Site ön ekim olarak kullanıyorum , ancak yalnızca kullanarak VLAN'a bağlıysanız 192.168.0.0/24? 192.168.1.0/24Aynı sitedeki başka bir VLAN'da kullanmama rağmen hi-jacked .

— fukawi2

Teoride bu iyi bir fikir. Uygulamada, alt cihazlardan biri statik IP adresi, diğeri ise DHCP istemcisi kullanmaktadır. Gönderilen bir üründe hiçbiri yapılandırılamaz. Bu nedenle adresler önceden yapılandırılmalıdır, ancak yerel bağlantı adresleri çalışmayacaktır.

— proski