Intel AMT (Active Management Technology)는 TCP / IP 호스트 스택을 어떻게 방해하지 않습니까?

필자가 사용한 인텔 개발 키트에는 운영 체제가 중단되는 경우 원격 재부팅을 허용 하는 원격 관리 기능 ( 여기서는 Ubuntu 매뉴얼 페이지 참조 )이 포함되어 있습니다.

운영 체제와 공유하는 IP 주소에서 소수의 포트 (구체적으로 16992 및 16993)를 수신 할 수 있습니다. (DHCP 요청을 스누핑하거나 자체 요청을 수행하여 확실하지 않지만이 모드에서 공유 MAC 주소를 사용하는 방식)

하나의 잠재적 유스 케이스가 걱정되기 때문에 별도의 IP 주소에서 실행 중입니다. AMT는 호스트 네트워크 스택이 호스트 네트워크 스택과 충돌하는 것을 어떻게 방지합니까?

다시 말해, 인텔 관리 소프트웨어는 현재 대역 외에서 운영 체제에 대한 지식없이 최소한 두 개의 TCP 포트를 수신하고 있습니다. 원격 호스트에 대한 TCP 연결을 시작하고 호스트 스택이 16992 또는 16993을 로컬 포트로 선택하여 [상자로 돌아 오는 패킷의 경우]를 가정합니다.

원격 호스트에서 반환되는 패킷이 "블랙홀"되지 않고 OS에 도달하지 않습니까? 아니면 TCP가 포트 16992를 피해야한다는 것을 아는 Linux 커널의 인텔 드라이버와 같은 예방 조치가 있습니까? (OS에 구애받지 않는 기능이기 때문에 보이지 않습니다.) 또는 관리 인터페이스가 알려진 관리 세션에 속하지 않은 포트 16992로 전송 된 트래픽을 호스트 스택으로 다시 전달할 수 있습니까?

어느 쪽이든, 나는 이것이 어떻게 작동하는지 이해할 때까지 네트워크 집약적 인로드에 이것을 사용하는 것을 꺼려합니다. 인텔 설명서를 검색했는데 아무것도 찾을 수 없습니다.

약 30,000 개의 TCP 연결을 시작하고 포트가 겹치는 경우에도 연결이 작동하는지 확인하여 이것이 테스트 될 수 있다고 생각합니다. 그러나 아직 그렇게 할 기회가 없었습니다.

(각주 :이 질문은 인텔 v 프로 기반 컴퓨터가 IP 연결을 유지하는 방법 과 비슷 하지만 질문은 일반적으로 호스트 스택과 겹치는 특정 TCP 포트에 대한 연결이 아니라 연결 문제를 해결합니다.)

공유 IP 주소를 수신하도록 AMT를 구성한 후 위 주석에서 kasperd 가 언급 한 테스트를 실행했습니다 . ( example.com물론 실제로 는 아니지만 SSH 서버가있는 자체 원격 호스트와 비교할 때) 결과는 다음과 같습니다.

긍정적 인 테스트 사례 ( AMT에서 사용 하지 않는 포트 사용) :

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

부정적인 테스트 사례 (AMT에서 사용하는 포트 사용) :

$ nc -p 16992 example.com 22
$

(몇 분 후, 부정적인 테스트 사례가 시간 초과되어 쉘 프롬프트로 돌아 왔습니다.)

보시다시피 포트 16992로 돌아 오는 패킷은 호스트의 TCP / IP 스택에 도달하기 전에 삭제되었습니다.

권장 사항 : 안정적인 네트워킹이 중요한 경우 호스트 TCP / IP 스택과 동일한 IP 주소에서 AMT를 활성화하지 마십시오!

인텔 포럼 에는 호스트 IP와 인텔 AMT 장치 IP 간의 매핑에 대한 논란 이 있습니다.

고정 IP로 작동 할 때 AMT 및 호스트에 대해 다른 IP 주소를 구성해야합니다.

그리고 설명 :

고정 IP로 vPro 시스템을 구성 할 때 AMT는 고정 IP 모드에서만 재생되는 관리 성 mac이라는 mac 주소를 사용합니다. 관리 효율성 mac 주소는 호스트가 제공 한 mac 주소와 다릅니다.

AMT 및 호스트에서 DHCP를 사용하면 라우팅 문제가 발생 함을 확인합니다. 예를 들어 핑 오도 :

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

원격 호스트에서 반환되는 패킷이 "블랙홀"되지 않고 OS에 도달하지 않습니까?

"AMT 포트"가있는 원격 호스트의 모든 패킷은 어떤 OS에도 도달하지 않습니다. 인텔 ME / AMT에 의해 차단됩니다. 기본적으로 포트는 16992-16995, 5900 (AMT 버전 6 이상), 623, 664입니다.

주목해야 할 것은 AMT는 서버가 아닌 클라이언트 OOBM 기술로 의도 된 것입니다. 따라서, 컴퓨터가 AMT 포트를 사용하기로 결정했을 수도 있지만, 그렇게 특별히 구성한 경우에만 가능합니다. 대부분의 OS에는 IANA 사양에서 제안한대로 49152 ~ 65535 범위의 미리 구성된 임시 포트, 32768 ~ 61000의 Linux 배포판 및 1025–5000의 이전 Windows가 제공됩니다.

내 관점에서 볼 때 포트가 임시 범위에 있지 않기 때문에 AMT에 공유 IP를 사용하는 것이 절약됩니다 (당신이하는 일을 알고이 특정 설정을 변경하지 않는 한) 응용 프로그램에서 청취 포트로 사용해서는 안됩니다.

한 가지 해결책은을 사용하여 Windows TCP 스택의 포트를 설정하는 것 netsh입니다.

기본적으로 Windows는 포트 49152 >> 65636 (또는 상한이 무엇이든)을 사용하므로 AMT를 사용하는 것이 안전합니다. 로 포트 범위를 설정할 수 있습니다 netsh. 예를 들어, 나는 항상 주변 머신에 약 1000 개의 포트를 사용합니다.

또한 인텔은 AMT 명령을 제거하고 해당 포트 (실제로는 16991-16995!)의 다른 모든 트래픽을 OS (OS가있는 경우)로 전달합니다. 따라서 AMT 범위에서 포트를 연 응용 프로그램을 사용하는 경우 인텔은 AMT 관리 명령을 제거하기 때문에 트래픽이 여전히 OS를 통해 응용 프로그램으로 전달됩니다. 응용 프로그램이 AMT 명령을 보내는 것 같지 않습니다.