In che modo Intel AMT (Active Management Technology) non interferisce con lo stack host TCP / IP?

Il kit di sviluppo Intel che sto usando include una funzione di gestione remota (vedi anche la pagina man di Ubuntu qui ) che consente il riavvio remoto nel caso in cui il sistema operativo si blocchi.

Ha la capacità di ascoltare una manciata di porte (16992 e 16993, per essere precisi) su un indirizzo IP che condivide con il sistema operativo. (o ficcando le richieste DHCP o emettendo le proprie; non ne sono sicuro, ma in entrambi i casi utilizza un indirizzo MAC condiviso in questa modalità)

L'ho eseguito su un indirizzo IP separato, perché sono preoccupato per un potenziale caso d'uso: in che modo AMT impedisce allo stack della rete host di entrare in conflitto con esso?

In altre parole, il software di gestione Intel sta ora ascoltando [almeno] due porte TCP, fuori banda e all'insaputa del sistema operativo. Diciamo che inizio una connessione TCP a un host remoto e lo stack host sceglie 16992 o 16993 come porta locale su cui ascoltare [per i pacchetti che ritornano nella scatola].

I pacchetti che tornano dall'host remoto non vengono "oscurati" e non raggiungono mai il sistema operativo? O c'è qualche misura preventiva, come un driver Intel nel kernel Linux, sapendo che TCP dovrebbe evitare la porta 16992? (sembra improbabile dal momento che si tratta di una funzionalità indipendente dal sistema operativo.) O forse l'interfaccia di gestione può inoltrare il traffico inviato alla porta 16992 che non appartiene a una sessione di gestione nota allo stack host?

Ad ogni modo, sono riluttante a usarlo per i carichi ad alta intensità di rete fino a quando non capisco come funziona. Ho cercato la documentazione di Intel e non ho trovato nulla.

Suppongo che questo potrebbe essere testato avviando circa 30.000 connessioni TCP e verificando se la connettività funziona anche se la porta si sovrappone. Ma non ho ancora avuto la possibilità di farlo.

(Nota a piè di pagina: mi rendo conto che questa domanda è simile a Come fa un computer basato su Intel vPro a mantenere la connettività IP?, Ma che le domande riguardano la connettività in generale, non la connettività alle porte TCP specifiche che si sovrappongono allo stack host.)

Dopo aver configurato AMT per l'ascolto su un indirizzo IP condiviso, ho eseguito il test citato da kasperd nei commenti sopra. (contro il mio host remoto con un server SSH, non in realtà example.com, ovviamente) Ecco il risultato:

Caso di test positivo (utilizzando una porta non utilizzata da AMT):

$ nc -p 16991 example.com 22
SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.4
^C
$

Caso di test negativo (utilizzando una porta utilizzata da AMT):

$ nc -p 16992 example.com 22
$

(Dopo alcuni minuti, il test case negativo è scaduto e è tornato al prompt della shell.)

Come puoi vedere, i pacchetti che ritornano alla porta 16992 sono stati eliminati prima di raggiungere lo stack TCP / IP dell'host.

Raccomandazione: se per te è importante una rete affidabile, non abilitare AMT sullo stesso indirizzo IP dello stack TCP / IP host!

Esiste un thread controverso nel forum Intel Mapping tra l'IP host e Intel AMT Device IP con il suggerimento che

è necessario configurare indirizzi IP diversi per AMT e host quando si opera con IP statici.

e una spiegazione:

Quando si configura la macchina vPro con IP statici, AMT utilizzerà l'indirizzo mac chiamato gestibilità mac che viene riprodotto solo in modalità IP statico. L'indirizzo mac di gestibilità è diverso dall'indirizzo mac presentato dall'host.

Confermo che l'utilizzo di DHCP con AMT e Host comporta problemi di routing. es. ping fuorviante:

64 bytes from 192.168.1.11: icmp_seq=18 ttl=64 time=0.559 ms
64 bytes from 192.168.1.11: icmp_seq=18 ttl=255 time=0.614 ms (DUP!)
64 bytes from 192.168.1.11: icmp_seq=19 ttl=64 time=0.579 ms
64 bytes from 192.168.1.11: icmp_seq=19 ttl=255 time=0.630 ms (DUP!)
64 bytes from 192.168.1.11: icmp_seq=20 ttl=64 time=0.553 ms
64 bytes from 192.168.1.11: icmp_seq=20 ttl=255 time=0.602 ms (DUP!)

I pacchetti che tornano dall'host remoto non vengono "oscurati" e non raggiungono mai il sistema operativo?

Tutti i pacchetti dall'host remoto con "porte AMT" non raggiungono mai alcun sistema operativo. Sono intercettati da Intel ME / AMT. Di default sono le porte 16992-16995, 5900 (AMT ver. 6+), 623, 664.

Ciò che va notato è che AMT è inteso come tecnologia OOBM client non come server uno. Pertanto sì, può accadere che il tuo computer decida di utilizzare le porte AMT, ma solo nel caso in cui lo hai configurato specificamente per farlo. La maggior parte dei sistemi operativi sono dotati di porte effimere preconfigurate nell'intervallo da 49152 a 65535 come suggerito dalla specifica IANA, alcune distro Linux con 32768-61000 e vecchie finestre con 1025-5000.

Quindi, dal mio punto di vista, è salvabile usare l'IP condiviso per AMT poiché le sue porte non sono nell'intervallo effimero (a meno che tu non sappia cosa fai e cambi questa particolare impostazione) e non dovrebbe essere usato come porta di ascolto da nessuna applicazione.

Una soluzione potrebbe essere quella di impostare le porte per lo stack TCP di Windows utilizzando netsh.

Per impostazione predefinita, Windows utilizza la porta 49152 >> 65636 (o qualunque sia il limite superiore). Quindi sei sicuro di usare AMT. È possibile impostare l'intervallo di porte con netsh. Ad esempio, utilizzo sempre circa 1000 porte per macchine perimetrali.

Inoltre, Intel elimina i comandi AMT e trasferisce tutto il traffico su quelle porte (16991-16995 in realtà!) Al sistema operativo (se è presente un sistema operativo). Quindi, se avessi un'applicazione che aprisse una porta nell'intervallo AMT, il traffico passerebbe comunque attraverso il sistema operativo all'applicazione, perché, come ho detto, Intel elimina solo i comandi di gestione AMT. È improbabile che l'applicazione stia inviando comandi AMT.