동일한 Subnet에서 여러 IP 인터페이스로 내결함성을 향상시킬 수 있습니까?

동일한 서브넷에 모듈에 두 개의 인터페이스가 있으면 모듈 안팎에서 두 개의 인터페이스가 제공되지 않습니다. 모듈에 두 개의 인터페이스를 가져오지만 STCP는 모듈에서 패킷을 보낼 때 하나의 인터페이스만 사용합니다. 클라이언트가 연결된 인터페이스에 관계없이 이 작업을 수행합니다.

예를 들어 172.16.1.0/24 서브넷에서 이러한 두 인터페이스를 감안할 때

%phx_vos#sdlmux.m16.10.11-2 IP: 172.16.1.116 MAC: 00:00:a8:42:52:22

%phx_vos#sdlmux.m16.11.11-2 IP: 172.16.1.226 MAC: 00:00:a8:43:52:22

172.16.1.226으로 전송된 패킷이 00:00:a8:43:52:22의 대상 MAC 주소를 사용하지만 응답은 00:00:00:a8:42:52:22, 172.16.116에 대한 MAC 주소가 16.16에서 오는 16.16에서 16.16으로 나타났다.

그림 1 – 모듈연결 요청(클라이언트에서 가져온 추적)

모듈이 하나를 수신하는 대신 연결을 시작하면 항상 첫 번째 (116) 인터페이스를 사용합니다.

그림 2 – 모듈에서 다른 서버로의 연결 요청(서버에서 가져온 추적)

패킷을 보낼 때 두 번째 (226) IP 주소에 바인딩해도 첫 번째 (116) 인터페이스를 통해 남습니다.

그림 3 – 모듈에서 다른 서버로의 연결 요청(다른 서버에서 가져온 추적)

172.16.1.226 IP 인터페이스에 바인딩된 클라이언트 응용 프로그램

첫 번째 (116) 인터페이스가 다운되면 모듈이 두 번째 (226) 인터페이스를 사용하는 것으로 이동합니다. 두 번째(226) 인터페이스에 대한 연결이 유지되지만 첫 번째(116) 인터페이스에 대한 연결이 실패합니다.

인터페이스 172.16.1.116 실패 - 소스 MAC 주소의 변경 사항에 주의

그림 4 – 첫 번째 인터페이스가 실패할 때 MAC의 변경 사항(클라이언트에서 찍은 추적)

트래픽을 보내는 데 어떤 인터페이스를 사용할지 어떻게 알 수 있습니까?

여러 가지 방법이 있습니다.  첫 번째는 원격 호스트 또는 네트워크에서 packet_monitor 또는 다른 프로토콜 분석기를 사용하여 소스 Mac 주소를 평가하는 것입니다.

두 번째는 netstat를 사용하여 인터페이스를 보고, 일부 트래픽을 생성하고, netstat를 다시 실행하고 비교하는 것입니다. 하나의 인터페이스만 "전송된 프레임" 카운터를 증가시켜야 합니다.

그림 5 – netstat를 사용하여 전송된 프레임 카운터를 비교합니다.

세 번째 방법은 다른 시스템의 서비스에 연결하고 사용되는 로컬 소스 주소를 확인하는 것입니다. 다른 주소에 명시적으로 바인딩하지 않는 한 소스 IP 주소는 활성 인터페이스에 해당합니다.

그림 6 – 나가는 연결에 사용되는 인터페이스

같은 서브넷에 여러 인터페이스를 갖는 것은 단지 일을 혼동하고 일반적으로 혼란 가치가 없다는 것을 내 의견입니다. 어떤 이유로 동일한 서브넷에서 IP 주소를 IP해야 하는 경우 첫 번째 인터페이스에 별칭을 추가합니다.

ifconfig #sdlmux.m16.10.11-2 172.16.1.226 -추가 -별칭

인터페이스 %phx_vos #sdlmux.m16.10.11-2에 IP 주소 172.16.1.226 추가

그림 7 – 인터페이스에 별칭 추가