Cum face Intel AMT (Active Management Technology) să nu interfereze cu stiva gazdă TCP/IP? (Administrarea sistemului, Rețea, Tcp, Amt)

mpontillo a intrebat.

Kitul de dezvoltare Intel pe care l-am folosit include un funcție de gestionare la distanță (a se vedea și pagina de manual Ubuntu aici) care permite repornirea de la distanță în cazul în care sistemul de operare se blochează.

Aceasta are capacitatea de a asculta o mână de porturi (16992 și 16993, mai exact) pe o adresă IP pe care o împarte cu sistemul de operare. (fie prin snooping de cereri DHCP, fie prin emiterea propriilor cereri; nu sunt sigur, dar în orice caz folosește o adresă MAC partajată în acest mod).

Îl fac să ruleze pe o adresă IP separată, deoarece sunt îngrijorat de un potențial caz de utilizare: cum împiedică AMT ca stiva de rețea gazdă să intre în conflict cu ea?

Cu alte cuvinte, software-ul de gestionare Intel ascultă acum [cel puțin] două porturi TCP, în afara benzii și fără ca sistemul de operare să știe. Să presupunem că inițiez o conexiune TCP către o gazdă la distanță, iar stiva gazdă alege 16992 sau 16993 ca port local pe care să asculte [pentru pachetele care se întorc la cutie].

Pachetele care se întorc de la gazda de la distanță nu vor fi „blackholed” și nu vor ajunge niciodată la sistemul de operare? Sau există vreo măsură preventivă, cum ar fi un driver Intel în kernelul Linux care să știe că TCP ar trebui să evite portul 16992? (pare puțin probabil, deoarece aceasta este o caracteristică agnostică pentru sistemul de operare.) Sau poate că interfața de gestionare poate redirecționa traficul trimis la portul 16992 care nu aparține unei sesiuni de gestionare cunoscute înapoi la stiva gazdă?

Oricum ar fi, sunt reticent în a folosi acest lucru pentru sarcini de rețea intensivă până când nu înțeleg cum funcționează acest lucru. Am căutat în documentația Intel și nu am găsit nimic nici acolo.

Presupun că acest lucru ar putea fi testat prin inițierea a aproximativ 30.000 de conexiuni TCP și verificarea dacă conectivitatea funcționează chiar dacă portul se suprapune. Dar nu am avut ocazia să fac asta încă.

(Notă de subsol: îmi dau seama că această întrebare este similară cu „Cum menține un computer bazat pe Intel vPro conectivitatea IP?”, dar aceste întrebări se adresează conectivității în general, nu conectivității la porturile TCP specifice care se suprapun cu stiva gazdă).

Comentarii

  • Am observat că cineva a votat pentru a închide această întrebare ca fiind off-topic. În acest caz, aș dori să întreb: cum se face acest lucru nu este relevant pentru administratorii profesioniști de servere? Dacă aveți de gând să activați o tehnologie de gestionare out-of-band, nu ați vrea să știți dacă aceasta va avea un efect asupra comunicațiilor din rețea? –  > Por mpontillo.
  • Bănuiala mea ar fi că se uită la tot traficul de pe acele porturi și, dacă nu este ceva ce recunoaște, îl trece la sistemul de operare. Dar asta este o speculație în întregime. –  > Por Grant.
  • Bună întrebare. Mă gândesc că o implementare corectă a unei astfel de funcții ar trebui să folosească propriul stack IP pe o adresă MAC diferită pentru a evita complet posibilele conflicte. Nu aveți nevoie de 30000 de conexiuni TCP pentru a testa conflictele. În schimb, ați putea încerca ceva de genul nc -p 16992 example.com 22 și să vedeți ce se întâmplă. –  > Por kasperd.
  • @kasperd mulțumiri; nu știam că se poate face asta cu ușurință. Am mers mai departe și am făcut testul. Nu arată bine pentru AMT… –  > Por mpontillo.
5 răspunsuri
mpontillo

După ce am configurat AMT pentru a asculta pe o adresă IP partajată, am rulat testul menționat de kasperd în comentariile de mai sus. (împotriva propriei mele gazde de la distanță cu un server SSH, nu de fapt example.com, , bineînțeles) Iată rezultatul:

Cazul de test pozitiv (utilizând un port nu utilizat de AMT):

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

Caz de test negativ (utilizând un port utilizat de AMT):

$ nc -p 16992 example.com 22
$

(După câteva minute, cazul de testare negativ a expirat și a revenit la promptul shell-ului).

Deci, după cum puteți vedea, pachetele care se întorceau la portul 16992 au fost eliminate înainte de a ajunge la stiva TCP/IP a gazdei.

Recomandare: dacă pentru dumneavoastră este importantă o rețea fiabilă, nu activați AMT pe aceeași adresă IP ca și stiva TCP/IP a gazdei!

BBQ

Există o discuție controversată pe forumul Intel Maparea între IP-ul gazdei și IP-ul dispozitivului Intel AMTcu sugestia că

trebuie să se configureze adrese IP diferite pentru AMT și gazdă atunci când se operează cu IP-uri statice.

și o explicație:

Atunci când configurați mașina vPro cu IP-uri statice, AMT va utiliza adresa mac numită manageability mac care intră în joc doar în modul IP static. Adresa mac de gestionabilitate este diferită de adresa mac prezentată de gazdă.

Confirm că utilizarea DHCP atât cu AMT, cât și cu Host duce la probleme de rutare. de exemplu, ping induce în eroare:

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!)

Roman Sevko

Pachetele care se întorc de la gazda la distanță nu vor fi „blackholed” și nu vor ajunge niciodată la sistemul de operare?

Toate pachetele de la gazda la distanță cu „AMT-ports” nu ajung niciodată la niciun sistem de operare. Ele sunt interceptate de Intel ME/AMT. În mod implicit, acestea sunt porturile 16992-16995, 5900 (AMT ver. 6+), 623, 664.

Lukáš Kučera

Trebuie remarcat faptul că AMT este conceput ca o tehnologie OOBM client și nu ca o tehnologie server. Prin urmare, da, se poate întâmpla ca computerul dvs. să decidă să utilizeze porturile AMT, dar numai în cazul în care l-ați configurat în mod special pentru a face acest lucru. Majoritatea sistemelor de operare vin cu porturi efemere preconfigurate în intervalul 49152-65535, așa cum sugerează specificația IANA, unele distribuții Linux cu 32768-61000 și vechiul Windows cu 1025-5000.

Prin urmare, din punctul meu de vedere, nu este necesar să se utilizeze un IP partajat pentru AMT, deoarece porturile sale nu se află în intervalul efemer (cu excepția cazului în care știți ce faceți și modificați această setare specială) și nu ar trebui să fie utilizate ca port de ascultare de către nicio aplicație.

Mark

O soluție ar putea fi să setați porturile pentru stiva TCP din Windows utilizând netsh.

În mod implicit, Windows utilizează portul 49152 >> 65636 (sau oricare ar fi limita superioară) Deci, sunteți foarte sigur să utilizați AMT. Puteți seta intervalul de porturi cu netsh. De exemplu, eu folosesc întotdeauna aproximativ 1000 de porturi pentru mașinile din perimetru.

În plus, Intel elimină comenzile AMT și transmite tot restul traficului pe aceste porturi (16991-16995, de fapt!) către sistemul de operare (dacă există un sistem de operare). Deci, dacă ați avea o aplicație care a deschis un port în intervalul AMT, traficul va trece în continuare prin sistemul de operare către aplicație, deoarece, așa cum am spus, Intel elimină doar comenzile de gestionare AMT. Este puțin probabil ca aplicația dvs. să trimită comenzi AMT.

Comentarii

  • Acest răspuns presupune că (1) folosiți Windows și (2) nu folosiți niciun software care ar putea încerca să folosească porturile care se suprapun AMT din alte motive. (este posibil să aveți, de exemplu, o aplicație VoIP care utilizează porturi UDP aleatorii) De asemenea, face o afirmație despre modul în care Intel „elimină” comenzile AMT, care a fost clar demonstrată ca fiind falsă în răspunsul meu. Puteți furniza o referință pentru a vă susține afirmația? Nu aș fi surprins dacă Intel ar considera acest lucru un bug și l-ar rezolva într-o zi, dar la momentul în care am postat răspunsul meu, este clar că nu o făcuseră. –  > Por mpontillo.

Tags:, ,