La migliore scelta di indirizzi privati per una "rete di area del dispositivo"

8

Sto costruendo un dispositivo composto da diversi dispositivi secondari collegati tramite Ethernet all'interno del dispositivo. L'appliance si connetterà alla rete del cliente. La rete del cliente può utilizzare indirizzi IP privati. Un conflitto di indirizzi con la rete interna sarebbe un problema (il sottosettore collegato a entrambe le reti sarebbe confuso). IPv6 non è un'opzione.

Devo acquistare gli indirizzi IPv4? O forse posso cavarmela usando TEST-NET-3 (203.0.113.0/24) o qualcosa del genere? Qual è la migliore pratica?

— proski
fonte

1

La rete del cliente dovrà accedere direttamente ai dispositivi secondari o si collegheranno all'appliance solo tramite una porta LAN di tipo "gestione" sull'appliance? Chiedo perché EMC e altri utilizzano comunicazioni IP private in fibra ottica sulle proprie SAN per i propri controller / ecc. Con una scheda di gestione dedicata dedicata alla rete del cliente. La scheda di rete mgmt ottiene un indirizzo DHCP dalla LAN del cliente o è staticamente assegnata per risiedere sulla rete del cliente.

— TheCleaner

1

È necessario utilizzare lo stack TCP / IP per la comunicazione tra i "sottodispositivi"? Se rimani al secondo livello non avrai problemi con i conflitti IP.

— jlehtinen,

La rete del cliente è solo il mezzo per connettersi al servizio cloud. Pertanto, il gateway predefinito del cliente non deve sovrapporsi alla rete interna, altrimenti il sottosettore che guarda verso l'esterno non indirizzerebbe correttamente i pacchetti. Uno dei dispositivi secondari è solo IPv4, nessun altro modo per controllarlo.

— proski,

3

"IPv6 non è un'opzione." Abbiamo 2014 ora. Dovrebbe essere un'opzione. "Devo comprare gli indirizzi IPv4?" Bene, se puoi - in Asia, sono esausti, anche in Europa, ...

— glglgl

1

Se i dispositivi non supportano IPv6, non voglio nemmeno prendere in considerazione l'acquisto di loro, perché avrei poi dovuto sostituirli ben prima che la durata prevista del dispositivo, con qualcosa che fa il supporto IPv6. (Beh, comunque per i clienti. Sulle mie reti, che sono già dual stack, un dispositivo che non supporta IPv6 è considerato non idoneo allo scopo.)

— Michael Hampton,

10

@yoonix ha inviato un collegamento che potrebbe avere una soluzione.

Link-local, noto anche come APIPA.

169.254.0.0/16 - Questo è il blocco "link local". Come descritto in RFC3927, è allocato per la comunicazione tra host su un singolo collegamento. Gli host ottengono questi indirizzi mediante la configurazione automatica, ad esempio quando non è possibile trovare un server DHCP.

Se fossi tuo cliente, sicuramente avrei la possibilità di configurarlo da solo e / o utilizzare DHCP (che è, non lo so, forse uno standard consolidato da tempo?), Ma in assenza di quelli, questo è esattamente ciò per cui APIPA dovrebbe essere usato.

Modifica: dato che ora dichiari che gli indirizzi IP devono essere statici per i singoli host nella tua soluzione perché corrisponderanno alle regole del firewall nel tuo dispositivo gateway, suppongo che ci vorrebbe un po 'di sforzo da parte tua per farlo funzionare con link indirizzamento IPv4 locale; sforzo che dici che non spenderai. Quindi, è essenzialmente necessario per rendere questo configurabile. È possibile spedirlo con un valore predefinito, uno che ha meno probabilità di essere utilizzato da un client, ma è necessario disporre di un meccanismo in base al quale può essere modificato in caso di conflitto. O dal cliente o da te come parte dell'implementazione / UAT.

— mfinni
fonte

L'appliance utilizza DHCP sulla rete interna per uno dei dispositivi secondari (è molto difficile da configurare senza DHCP). Non mi sento a mio agio nel fare in modo che il server DHCP distribuisca gli indirizzi IP nell'intervallo locale di collegamento, poiché è esplicitamente vietato: tools.ietf.org/html/rfc3927#section-1.6 Se non avessimo dovuto utilizzare DHCP internamente, sarebbe stata la mia prima scelta.

— proski,

No no no, come ho esplicitamente citato, gli indirizzi APIPA (link-local) sono ciò che i dispositivi assegneranno a se stessi se non è possibile trovare un server DHCP. Non ho suggerito di utilizzare DHCP per assegnare gli indirizzi APIPA.

— mfinni,

I dispositivi secondari hanno ruoli specifici e il router deve configurare iptables in base a tali ruoli. Non voglio che il router scopra gli indirizzi e cambi di conseguenza iptables. Inoltre, l'assegnazione di indirizzi IP casuali significa che ci saranno conflitti di indirizzi e non sono sicuro che l'hardware sia abbastanza intelligente da risolverli.

— proski,

Leggi questo: tools.ietf.org/html/rfc3927 - tutto ciò che utilizza il collegamento locale deve implementare il rilevamento dei conflitti.

— mfinni,

Lo so. Non è possibile implementarlo nel prodotto. I dispositivi secondari hanno i loro ruoli e ci sono configurazioni iptables specifiche per loro.

— proski,

5

Renderlo configurabile.

Devo acquistare gli indirizzi IPv4?

Si. PROVA QUESTO. In primo luogo, non li acquisti, li "noleggi" per appartenenza. In secondo luogo ciò richiede un AS e 2 uplink. Terzo, questo richiede un motivo e "non vogliamo supporre una corretta infrastruttura di rete" è un motivo che provoca risate (e un rifiuto), non si ottengono indirizzi IP assegnati.

O forse posso cavarmela usando TEST-NET-3 (203.0.113.0/24)

Possibilmente. Fino al giorno in cui qualcuno chiede a Oyu il costo di sistemare le cose a causa di grave negligenza.

Qual è la migliore pratica?

Renderlo configurabile. Oppure usa IPV6 - lì puoi scappare con alcune prenotazioni.

— TomTom
fonte

Ottenere indirizzi IPv4 per uso interno (quindi non instradarli a Internet) è un caso d'uso perfettamente valido. Sfortunatamente nelle regioni APNIC e RIPE non ci sono più indirizzi IPv4, quindi passare a IPv6 è davvero l'unica soluzione a prova di futuro ... Gli indirizzi ULA sembrano una buona opzione lì.

— Sander Steffann,

3

Non è un caso d'uso valido. Non con spazio di indirizzi IPv4 limitato. Ecco a cosa servono gli indirizzi privati. E non lo sprecheranno per le aziende "non in grado o disposte a seguire le procedure di conservazione stabilite".

— TomTom,

Non è certamente un caso d'uso valido oggi, non so se lo sia mai stato. Hai qualche documentazione a sostegno della tua affermazione, @SanderSteffann?

— mfinni,

3

@proski ah, no. Vedi - Gli indirizzi TEST-NET-3 sono per i test. Un cliente che li utilizza per i test ha un caso valido. Alcune apparecchiature di spedizione ignorano o ignorano intenzionalmente le politiche relative a questi indirizzi, il che è grave abbandono. In entrambi i casi.

— TomTom,

1

@SanderSteffann Non conosco APNIC, ma RIPE ha certamente indirizzi IPv4 - circa 14 milioni di loro (0,85 di a / 8) secondo l'ultimo aggiornamento di stato sul loro sito web.

— Jules,

5

Da Wikipedia: Assigned as "TEST-NET-3" in RFC 5737 for use solely in documentation and example source code and should not be used publicly.- Questo mi dice che non dovresti usare TEST-NET-3.
Una cosa che sembra trascurare: come pensi che sarai in grado di comunicare con il dispositivo o che il dispositivo sarà in grado di comunicare con altri dispositivi e viceversa se non configuri l'indirizzo IP del dispositivo PER la rete client? Se assegni un indirizzo IP in una rete che non è in uso nella rete client (tu: 192.168.1.0/24 - Loro: 10.0.0.0/8), come pensi che funzionerà la comunicazione di rete? Questo è il motivo per cui è necessario configurare il dispositivo in modo che utilizzi DHCP immediatamente e consentire successivamente al client di configurarlo staticamente.

Se non è possibile utilizzare DHCP, utilizzare APIPA.

— joeqwerty
fonte

Non ci sarà alcun uso pubblico . Gli indirizzi interni non sarebbero mai esposti all'esterno. La comunicazione utilizza NAT. Ma non riesco a fare NAT quando entrambe le reti usano indirizzi sovrapposti.

— proski,

1

OK, ma la mia risposta non riguarda NAT. In che modo il dispositivo comunicherà con altri dispositivi sulla stessa rete interna se utilizza un indirizzo IP che non si trova nella stessa sottorete della rete interna?

— joeqwerty,

Ovviamente, l'appliance include un router con indirizzi su entrambe le reti. Il router fa NAT. Il cliente parla all'appliance solo attraverso un servizio cloud.

— proski,

Non sto cercando di essere snarky, ma come è ovvio? Sappiamo solo quanto ci dici nella tua domanda e non hai mai menzionato questo fatto.

— joeqwerty,

1

Forse sono io. Sicuramente non intendo alcuna offesa e forse questo diventerà maleducato, ma in che modo la frase "il sottosettore collegato a entrambe le reti sarebbe confusa" implica che il dispositivo ha un router incorporato o ha funzionalità di routing? Il mio computer ha due interfacce di rete, ognuna collegata a una rete diversa, ma il mio computer non è un router. Forse sono solo stupido. Non leggo nulla nella tua domanda che mi induca a credere che il tuo dispositivo abbia un router integrato o abbia funzionalità di routing. In ogni caso, questo sfogo non serve ad aiutarti, quindi lo lascerò a questo punto.

— joeqwerty,

4

In teoria, qualsiasi intervallo IP privato potrebbe essere utilizzato da qualsiasi rete privata, quindi dubito che troverai una best practice o qualsiasi cosa che sarà universalmente applicabile se stai codificando l'indirizzo. La migliore pratica sarebbe quella di renderlo configurabile e consentire alla rete client di assegnare al dispositivo un indirizzo privato (tramite DHCP, ad esempio).

Se questa non è un'opzione, trovo che quasi nessuno usa la metà superiore di 172.16.0.0/12, quindi è quello che uso. (Penso che sto correndo 172.25.0.0/16, per essere precisi.) Devo ancora avere una collisione di indirizzi su di esso, e ho VPN in molte reti private.

Se devi usare un indirizzo privato IPv4, penso che sia il migliore che sarai in grado di fare, con il 10.0.0.0/8blocco ampiamente utilizzato e il 192.168.0.0/16blocco predefinito per quasi tutto, l'unico rimasto sarebbe 172.16.0.0/12. Naturalmente, questo blocco viene spesso utilizzato per le VPN, per evitare collisioni di indirizzi, a causa dell'uso diffuso degli altri blocchi di rete privata, quindi utilizzare gli indirizzi superiori, poiché (nella mia esperienza) sono le sottoreti meno utilizzate in quel blocco .

— HopelessN00b
fonte

1

Se scegli un casuale / 24 nell'intervallo 10.0.0.0/8 e supponendo un uso ragionevole degli indirizzi da parte dei dispositivi esistenti (cioè al massimo una manciata di / 24 sottoreti sono in uso - Tendo a pensare alla mia configurazione di rete come abbastanza complesso, dato che ha 4 sottoreti di questo tipo [3 posizioni diverse e una VPN per instradarle tra loro]), le probabilità di un conflitto sono <0,01%. In genere sarei disposto a correre questo rischio nella maggior parte dei casi.

— Jules,

1

@Jules ad eccezione di quelle (purtroppo comuni) reti che utilizzano l'intera sottorete / 8 solo perché è l'impostazione predefinita.

— Concedi il

Il percorso verso una rete più piccola ha la priorità, dovrebbe funzionare. Potrei effettivamente avere / 29 internamente per ridurre ulteriormente il rischio. Ma non eliminare quel rischio, non importa quanto piccolo, sarebbe male. L'assistenza clienti dovrebbe conoscerlo e verificare la configurazione di rete del cliente.

— proski,

2

Stiamo progettando la stessa identica cosa e abbiamo deciso di utilizzare gli indirizzi locali del sito IPv6 con un prefisso casuale fc00: nnnn.

— Michael
fonte

1

Cattivo. Ottieni un blocco ULA.

— TomTom,

1

Supponendo che nessuno di questi dispositivi secondari necessiti di connettività diretta all'esterno dell'appliance, è necessario utilizzare la rete di loopback per questo (127.0.0.0/8).

RFC 5735 / Sezione 3

Loopback su Wikipedia

— yoonix
fonte

3

Come potrebbe funzionare? I suoi "sottodispositivi" sono singoli host. Il loopback è per un host di comunicare con se stesso.

— mfinni,

1

Bene, giuro che l'ho visto usato così prima d'ora ... ma non ricordo dove. Rimuoverò la mia risposta a breve.

— Yoonix,

Ma quel documento ha un altro suggerimento che mi piace!

— mfinni,

In realtà, sto pensando di utilizzare 127.0.1.0/255 per la rete interna. Non sono sicuro se sarebbe meglio che TEST-NET-3.

— proski,

1

QUELLO CHE HA VINTO "FUNZIONA. Questo è loopback. Un host che comunica con un indirizzo di loopback STA SOLO PARLANDO CON SE STESSO. L'indirizzo di loopback sembra avere le dimensioni di un'intera sottorete; è ancora solo host-local.

— mfinni

1

Il tuo "controller principale" può eseguire un server DHCP / fornire lease DHCP sulla sua interfaccia "interna"?

In passato ho fatto qualcosa per uno dei prodotti commerciali della nostra azienda che potrebbe essere utile. Il dispositivo aveva due porte Ethernet, una delle quali era pensata per la connettività "diretta" da un PC. Il problema era simile; volevamo evitare conflitti di indirizzi IP con la LAN interna di un cliente (possibilmente su una rete IP privata) e con il mondo in generale.

La logica su questo dispositivo era quella di configurare dinamicamente un server DHCP ("udhcpc", tramite le opzioni della riga di comando) sulla porta LAN "diretta" (eth1) in base alla propria configurazione IP sulla sua porta LAN "pubblica" (eth0). Sia che il dispositivo abbia ottenuto il proprio indirizzo IP tramite DHCP o tramite un'impostazione statica, il modulo che ha applicato l'impostazione cambierebbe anche la configurazione del server DHCP per evitare conflitti.

Ad esempio, se il dispositivo avesse ottenuto l'indirizzo 192.168.0.100/netmask 255.255.255.0 (su eth0), avrebbe configurato il proprio server DHCP (su eth1) per la successiva rete disponibile 192.168.1.0/255.255.255.0.

Sceglierebbe da una di queste reti (in ordine di priorità): 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

Spero che sia di aiuto.

— user1722483
fonte

Cosa succede se sto usando 192.168.0.0/16come prefisso del mio sito, ma sei connesso solo alla VLAN 192.168.0.0/24? Ti sei appena ciao, 192.168.1.0/24anche se lo sto usando su un'altra VLAN nello stesso sito.

— fukawi2,

Questa è una buona idea in teoria. In pratica, uno dei dispositivi secondari utilizza un indirizzo IP statico e un altro utilizza un client DHCP. Nessuno dei due è configurabile in un prodotto spedito. Pertanto, gli indirizzi devono essere preconfigurati, ma gli indirizzi link-local non funzioneranno.

— proski,

La migliore scelta di indirizzi privati ​​per una "rete di area del dispositivo"

La migliore scelta di indirizzi privati per una "rete di area del dispositivo"