Bagaimana Intel AMT (Teknologi Manajemen Aktif) tidak mengganggu tumpukan host TCP / IP?

Kit dev Intel yang telah saya gunakan menyertakan fitur manajemen jarak jauh (juga lihat halaman manual Ubuntu di sini ) yang memungkinkan reboot jarak jauh jika sistem operasi hang.

Ini memiliki kemampuan mendengarkan beberapa port (16992 dan 16993, untuk lebih spesifik) pada alamat IP yang dibagikan dengan sistem operasi. (baik dengan mengintip permintaan DHCP atau mengeluarkan sendiri; Saya tidak yakin, tapi bagaimanapun juga menggunakan alamat MAC bersama dalam mode ini)

Saya menjalankannya pada alamat IP yang terpisah, karena saya khawatir tentang satu kemungkinan penggunaan: bagaimana AMT mencegah tumpukan jaringan host dari konflik dengannya?

Dengan kata lain, perangkat lunak manajemen Intel sekarang mendengarkan [setidaknya] dua port TCP, out-of-band dan tanpa sepengetahuan sistem operasi. Katakanlah saya memulai koneksi TCP ke host jarak jauh, dan tumpukan host memilih 16992 atau 16993 sebagai port lokal untuk didengarkan [untuk paket yang kembali ke kotak].

Bukankah paket yang kembali dari host jarak jauh akan "dihitamkan" dan tidak pernah mencapai OS? Atau ada beberapa langkah pencegahan, seperti driver Intel di kernel Linux mengetahui bahwa TCP harus menghindari port 16992? (tampaknya tidak mungkin karena ini adalah fitur OS-agnostik.) Atau mungkin antarmuka manajemen dapat meneruskan lalu lintas yang dikirim ke port 16992 yang bukan milik sesi manajemen yang dikenal kembali ke tumpukan host?

Either way, saya enggan menggunakan ini untuk beban jaringan intensif sampai saya mengerti cara kerjanya. Saya mencari dokumentasi Intel dan tidak menemukan apa pun di sana.

Saya kira ini bisa diuji dengan memulai sekitar 30.000 koneksi TCP, dan memeriksa apakah konektivitas berfungsi bahkan jika port tumpang tindih. Tapi saya belum punya kesempatan untuk melakukan itu.

(Catatan kaki: Saya menyadari pertanyaan ini mirip dengan Bagaimana komputer berbasis Intel vPro mempertahankan konektivitas IP?, Tetapi pertanyaan itu membahas konektivitas secara umum, bukan konektivitas ke port TCP tertentu yang tumpang tindih dengan tumpukan host.)

Setelah mengkonfigurasi AMT untuk mendengarkan alamat IP yang dibagikan, saya menjalankan tes yang disebutkan oleh kasperd dalam komentar di atas. (Terhadap remote host saya sendiri dengan server SSH, tidak sebenarnya example.com, tentu saja) Berikut ini hasilnya:

Kasing uji positif (menggunakan port yang tidak digunakan oleh AMT):

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

Case uji negatif (menggunakan port yang digunakan oleh AMT):

$ nc -p 16992 example.com 22
$

(Setelah beberapa menit, test case negatif habis dan kembali ke prompt shell.)

Jadi seperti yang Anda lihat, paket yang kembali ke port 16992 dijatuhkan sebelum mereka mencapai TCP / IP stack host.

Rekomendasi: jika jaringan yang andal penting bagi Anda, jangan aktifkan AMT pada alamat IP yang sama dengan tumpukan TCP / IP host Anda!

Ada utas kontroversial di forum Intel Pemetaan antara Host IP dan Intel AMT Device IP dengan saran itu

seseorang harus mengkonfigurasi alamat IP yang berbeda untuk AMT dan host ketika beroperasi dengan IP statis.

dan penjelasan:

Saat Anda mengkonfigurasi mesin vPro dengan IP statis, AMT akan menggunakan alamat mac yang disebut manageability mac yang hanya dapat diputar dalam mode IP statis. Kemudahan mengelola alamat mac berbeda dari alamat mac yang disajikan oleh tuan rumah.

Saya mengkonfirmasi bahwa menggunakan DHCP dengan kedua AMT dan Host mengarah ke masalah routing. mis. ping menyesatkan:

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

Bukankah paket yang kembali dari host jarak jauh akan "dihitamkan" dan tidak pernah mencapai OS?

Semua paket dari host jarak jauh dengan "AMT-ports" tidak pernah mencapai OS apa pun. Mereka dicegat oleh Intel ME / AMT. Secara default mereka adalah port 16992-16995, 5900 (AMT ver. 6+), 623, 664.

Yang perlu dicatat adalah, bahwa AMT dimaksudkan sebagai teknologi klien OOBM bukan server satu. Karena itu ya, mungkin saja komputer Anda memutuskan untuk menggunakan port AMT, tetapi hanya jika Anda mengonfigurasikannya secara spesifik. Sebagian besar OS dilengkapi dengan porta pre-konfigurasi yang telah dikonfigurasikan pada kisaran 49152 hingga 65535 seperti yang disarankan oleh spesifikasi IANA, beberapa distro Linux dengan 32768 hingga 61000 dan Windows lama dengan 1025–5000.

Jadi dari sudut pandang saya menghemat menggunakan IP yang dibagikan untuk AMT karena port-portnya tidak dalam rentang sesaat (kecuali Anda tahu apa yang Anda lakukan, dan ubah pengaturan khusus ini) dan tidak boleh digunakan sebagai port mendengarkan oleh aplikasi apa pun.

Salah satu solusinya mungkin dengan mengatur port untuk tumpukan Windows TCP dengan menggunakan netsh.

Secara default, Windows menggunakan port 49152 >> 65636 (atau apa pun batas atasnya) Jadi Anda sangat aman menggunakan AMT. Anda dapat mengatur rentang port dengan netsh. Sebagai contoh, saya selalu menggunakan sekitar 1000 port untuk mesin perimeter.

Selain itu, Intel melepas perintah AMT dan meneruskan semua lalu lintas lainnya pada port tersebut (sebenarnya 16991-16995!) Ke OS (Jika ada OS). Jadi jika Anda memiliki aplikasi yang membuka port di kisaran AMT, lalu lintas masih akan melewati OS ke aplikasi, karena seperti yang saya katakan, Intel hanya strip perintah perintah manajemen AMT. Tidak mungkin aplikasi Anda mengirim perintah AMT.