Come modificare il comportamento dell'indirizzo di trasmissione globale (255.255.255.255) su Windows?

Comportamento desiderato

Quando un'applicazione invia un pacchetto all'indirizzo IP di trasmissione globale 255.255.255.255, vorrei che il pacchetto fosse inviato all'indirizzo di trasmissione globale Ethernet ( ff:ff:ff:ff:ff:ff), su tutte le interfacce.

Su Linux e probabilmente anche su altri sistemi operativi questo sembra funzionare. Windows XP e Windows 7 presentano comportamenti diversi a questo proposito, e nessuno dei due comportamenti è desiderabile per la mia situazione.

Comportamento di Windows XP

Il pacchetto verrà inviato correttamente alla prima interfaccia di rete (l'ordine delle interfacce è specificato in "Connessioni di rete / Impostazioni avanzate / avanzate"). Verrà inoltre inviato alle altre interfacce.

Finora è tutto a posto. Il problema è che, quando si invia ad altre interfacce, l'indirizzo di origine del pacchetto di trasmissione è l'indirizzo IP della prima interfaccia. Ad esempio, immagina questa configurazione di rete (l'ordine è importante):

Adattatore 1: indirizzo IP 192.168.0.1
Adattatore 2: indirizzo IP 10.0.0.1
Adattatore 3: indirizzo IP 172.17.0.1

Ora, se invio un pacchetto di trasmissione, verranno inviati i seguenti pacchetti (con indirizzi IP di origine e destinazione):

Sull'adattatore 1: 192.168.0.1=>255.255.255.255
Sull'adattatore 2: 192.168.0.1=>255.255.255.255
Sull'adattatore 3: 192.168.0.1=>255.255.255.255

In pratica, le applicazioni che utilizzano i pacchetti di trasmissione non funzionano su interfacce diverse dall'adattatore 1. A mio avviso, si tratta di un bug palese nello stack TCP / IP di Windows XP.

Comportamento di Windows 7

La modifica dell'ordine dell'interfaccia di rete non sembra avere alcun effetto su Windows 7. Al contrario, la trasmissione sembra essere controllata dalla tabella di instradamento IP.

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0   10.202.254.254       10.202.1.2    286
          0.0.0.0          0.0.0.0      192.168.0.1      192.168.0.3     10
       10.202.0.0      255.255.0.0         On-link        10.202.1.2    286
       10.202.1.2  255.255.255.255         On-link        10.202.1.2    286
   10.202.255.255  255.255.255.255         On-link        10.202.1.2    286
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
      192.168.0.0    255.255.255.0         On-link       192.168.0.3    266
      192.168.0.3  255.255.255.255         On-link       192.168.0.3    266
    192.168.0.255  255.255.255.255         On-link       192.168.0.3    266
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link       192.168.0.3    266
        224.0.0.0        240.0.0.0         On-link        10.202.1.2    286
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link       192.168.0.3    266
  255.255.255.255  255.255.255.255         On-link        10.202.1.2    286
===========================================================================

Vedi i 255.255.255.255percorsi? Sì, controllano i pacchetti di trasmissione. In questa situazione, i pacchetti di trasmissione verranno inviati tramite il 192.168.0.3perché ha la metrica inferiore ... ma non alle altre interfacce.

È possibile modificare l'interfaccia attraverso la quale i pacchetti di trasmissione globali verranno inviati molto facilmente (basta aggiungere una 255.255.255.255route persistente con una metrica bassa). Ma non importa quanto ci provi, i pacchetti di trasmissione verranno inviati su una sola interfaccia, non tutti come mi piacerebbe che facesse.

Conclusione

Windows 7 invia solo pacchetti di trasmissione a un'unica interfaccia. Puoi scegliere quale, ma non è questo il punto.
Windows XP invia pacchetti di trasmissione a tutte le interfacce, ma li invia come previsto a un'unica interfaccia, che in pratica equivale al comportamento di Windows 7.

L'obiettivo. il gol

Voglio cambiare questo supporto di trasmissione IP globale in Windows (preferibilmente Windows 7) una volta per tutte. Naturalmente il modo migliore sarebbe avere una sorta di modifica della configurazione supportata (hack del registro o simili), ma sono aperto a tutti i suggerimenti.

Qualche idea?

— Etienne Dechamps
fonte

Cosa stai usando per generare queste trasmissioni. Non riesco a fare in modo che il mio stack XP faccia altro che trasmissioni dirette. cioè 10.202.255.255 nel tuo caso.

— Scott Lundberg,

Puoi fare riferimento a un RFC o ad altro documento che indica il comportamento corretto che descrivi? Anche se concordo sul comportamento desiderato, chiamarlo comportamento corretto dovrebbe fare riferimento a una specifica che definisce ciò che è corretto. Potrebbe essere che l'implementazione specifica del routing sia lasciata al provider (in questo caso Microsoft)?

— Jason R. Coombs,

Scott Lundberg: molte applicazioni (in particolare i giochi) invieranno una trasmissione globale. Puoi generarne alcuni usando netcat: "nc -v -u 255.255.255.255 5000" per esempio.

— Etienne Dechamps,

Jason R. Coombs: davvero, forse avevo una scarsa scelta di parole. Avrei dovuto usare il "comportamento desiderabile". Non penso che ci sia un RFC per questo, ma potrei sbagliarmi.

— Etienne Dechamps,

Stai inviando un pacchetto TCP o UDP? Secondo questo, ciò che conta social.msdn.microsoft.com/Forums/en/peertopeer/thread/… .

— Nissan Fan,

Risposte:

Non che mi occupi della difesa di Microsoft, ma dopo aver letto le seguenti RFC che tentano di definire il funzionamento delle trasmissioni, non penso che Microsoft stia necessariamente violando le RFC. IMO il problema dovrebbe essere risolto a livello di applicazione (ovvero trasmissioni dirette, non globali) che colpirà le rotte appropriate nella tabella di routing e verrà inviato solo dall'interfaccia corretta per quella rete IP.

Entrambi affermano che non esiste uno standard definito per le trasmissioni. Nel 919 menziona anche che una specifica interfaccia fisica dovrebbe essere selezionata per la trasmissione. Nel caso di una macchina multi-homed, multi-NIC che genera la trasmissione, non credo che sia chiaramente affermato cosa dovrebbe accadere. Le trasmissioni non dovrebbero mai essere trasmesse dai router da un'interfaccia all'altra, quindi la macchina Windows è un router o no in questo caso?
Se funge da router, qualsiasi host che risponda alla trasmissione con l'indirizzo IP errato per quella rete (adattatori 2 e 3 nell'esempio) dovrebbe inviare il pacchetto all'indirizzo Ethernet degli adattatori 2 e 3 in risposta all'adattatore L'indirizzo IP di 1 e l'host Windows devono indirizzarlo all'interfaccia corretta.
Sembra confuso ... ma non riesco a pensare a un modo migliore per esprimerlo

E infine, RFC 919 dice specificamente From RFC 919

Poiché supponiamo che il problema sia già stato risolto a livello di collegamento dati, un host IP che desidera
inviare una trasmissione locale o una trasmissione diretta deve solo
specificare l'indirizzo di destinazione appropriato e inviare il datagramma come al
solito. Qualsiasi algoritmo sofisticato deve risiedere solo nei gateway.

La lettura suggerisce che l'indirizzo IP di origine è irrilevante per una trasmissione.

Dal momento che ogni applicazione sembra gestire le trasmissioni in modo diverso, penso che sia qui che risiede la responsabilità. Per esempio. nbtstatinvia trasmissioni dirette su macchine multi-NIC, mentre i giochi potrebbero utilizzare trasmissioni globali.
In breve, l'applicazione dovrebbe essere corretta, non il sistema operativo in questo caso ...

EDIT: ecco un link per le stesse circostanze, ma su Linux. Il kernel Linux lo gestisce inviando un solo pacchetto all'interfaccia predefinita (NIC A in questo esempio). Raccomandano che l'applicazione enumeri le NIC e invii una trasmissione diretta a ciascuna NIC. collegamento

— Scott Lundberg
fonte

In non capisco la relazione tra il paragrafo che stai citando da RFC 919 e l'indirizzo di origine. Mi sembra ovvio che sia sempre sbagliato inviare un pacchetto IP su un'interfaccia con l'indirizzo sorgente di un'altra interfaccia, indipendentemente dalla natura di trasmissione / unicast del pacchetto. Voglio dire, non si può ragionevolmente dire "l'indirizzo IP di origine è irrilevante per una trasmissione", certo che lo è! In che altro modo le applicazioni dovrebbero sapere chi ha inviato la trasmissione?

— Etienne Dechamps,

"Si menziona anche nel 919 che una specifica interfaccia fisica dovrebbe essere selezionata per la trasmissione." Dove? "L'indirizzo 255.255.255.255 indica una trasmissione su una rete hardware locale" (RFC919 7.)? In tal caso, non sono rispettosamente d'accordo. Stiamo discutendo su cosa fare con le trasmissioni a livello di host, non a livello di rete. Inoltre, si dice appena sotto che un host può "trasmettere a tutti i suoi vicini immediati usando 255.255.255.255". Tutti i suoi vicini immediati. Non "tutti i vicini su una specifica interfaccia di rete".

— Etienne Dechamps,

"Alle applicazioni non importa quale interfaccia abbia inviato la trasmissione. Devono solo rispondere ad essa." Eh ... hanno anche bisogno di inviare trasmissioni, non solo di rispondere a loro. Si consideri il caso di un browser gameserver LAN. Invia pacchetti di trasmissione per scoprire i server di gioco sulla rete. Se i pacchetti di trasmissione non vengono inviati a tutte le interfacce, il browser gameserver non mostrerà i server di gioco raggiungibili attraverso queste interfacce. In altre parole, il fallimento epico.

— Etienne Dechamps,

"Non sono sicuro, ma penso che il sistema operativo stia vedendo la richiesta 255.255.255.255 e dicendo che deve inviarlo su tutte le interfacce (per trovare tutti i vicini immediati), ma è stato richiesto da un'applicazione specifica, associato a un IP specifico (potrebbe essere predefinito in base alla metrica). " Sono d'accordo. Ciò non significa che sia la cosa giusta da fare. A mio avviso, viola completamente il principio della minima sorpresa dal punto di vista dello sviluppatore dell'applicazione, che si aspetta solo che il pacchetto venga inviato a tutti su tutte le interfacce.

— Etienne Dechamps,

Non sono sicuro di cosa intendi per duplicato. Le RFC proibiscono espressamente l'inoltro dei pacchetti di trasmissione. Dovrebbe essere inviato un solo pacchetto, che penso sia il nocciolo della nostra discussione. Se il sistema operativo dovesse fare come dici tu, in realtà dovrebbe generare 9 pacchetti totali (3 per ogni interfaccia) perché il livello IP dovrebbe generare tre pacchetti con IP di origine separati (uno per ogni scheda di interfaccia di rete al livello 3) e quindi ogni scheda di rete dovrebbe inviare quelle su Ethernet (livello 2). Se c'erano percorsi tra le reti, allora ricevi 3 risposte! Qual è giusto?

— Scott Lundberg,

Alla fine l'ho risolto programmaticamente. Ho scritto un software molto piccolo chiamato WinIPBroadcast che si occupa di inoltrare i frame di trasmissione a tutte le interfacce.

Funziona utilizzando un fatto interessante: è possibile ricevere pacchetti di trasmissione globale generati localmente durante l'ascolto sull'indirizzo di loopback (127.0.0.1). WinIPBroadcast ascolta l'indirizzo locale per tutte le trasmissioni utilizzando socket RAW, quindi per ogni pacchetto di trasmissione, lo inoltra a tutte le interfacce tranne quella preferita.

— Etienne Dechamps
fonte

Poiché lo stack di Windows è un fork dello stack BSD, sono curioso di sapere se BSD presenta lo stesso comportamento.

— x0n

Il tuo software non funziona. The program can't start becuase api-ms-win-core-rtlsupport-l1-2-0.dll is missing from your computer.. Buona fortuna a trovarlo .dllsu Google.

— Alex G,

@AlexG: è strano, pensavo di aver risolto il problema tramite github.com/dechamps/WinIPBroadcast/commit/… . Sei sicuro di eseguire l'ultima versione (1.6)? Sentiti libero di presentare un bug su github.com/dechamps/WinIPBroadcast/issues e darò un'occhiata.

— Etienne Dechamps,