동일 서브넷에 모듈에 두 개의 인터페이스가 있다고 해서 모듈에 두 개의 입력 및 출력 인터페이스가 생기는 것은 아닙니다. 모듈에는 두 개의 인터페이스가 있지만, 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
그림 1에서 172.16.1.226으로 전송된 패킷은 목적지 MAC 주소 00:00:a8:43:52:22를 사용하지만, 응답은 00:00:a8:42:52:22에서 왔습니다. 이는 패킷 상에서는 응답이 172.16.1.226에서 온 것으로 표시되지만, 실제로는 172.16.1.116의 MAC 주소인 00:00:a8:42:52:22에서 온 응답임을 의미합니다.
11:04:57.117 Xmit Ether Dst 00:00:a8:43:52:22 Src 00:00:a8:42:3b:6e Type 0800+(IP)IP Ver/HL 45, ToS 0, Len 2c, ID 2045, Flg/Frg 0, TTL 3c, Prtl 6 Cksum 0363, Src ac100122, Dst ac1001e2TCP from 172.16.1.34.49183 to 172.16.1.226.telnet. . . 11:04:57.130 Rcvd Ether Dst 00:00:a8:42:3b:6e Src 00:00:a8:42:52:22 Type 0800+(IP)IP Ver/HL 45, ToS 0, Len 2c, ID 7c8, Flg/Frg 0, TTL 3c, Prtl 6 Cksum 1be0, Src ac1001e2, Dst ac100122TCP from 172.16.1.226.telnet to 172.16.1.34.49183. . . 그림 1 – 모듈에 대한 연결 요청 (클라이언트 측에서 추적된 내용)
모듈이 연결을 수신하는 대신 연결을 시작하는 경우, 항상 첫 번째(116) 인터페이스를 사용합니다.
13:01:36.479 Rcvd Ether Dst 00:00:a8:42:3b:6e Src 00:00:a8:42:52:22 Type 0800+(IP)IP Ver/HL 45, ToS 0, Len 2c, ID 4a33, Flg/Frg 0, TTL 3c, Prtl 6 Cksum d9e2, Src ac100174, Dst ac100122TCP from 172.16.1.116.49320 to 172.16.1.34.4680. . .그림 2 – 모듈에서 다른 서버로의 연결 요청 (서버에서 추적된 내용)
패킷을 전송할 때 두 번째(226) IP 주소에 바인딩하더라도, 패킷은 첫 번째(116) 인터페이스를 통해 나갑니다.
13:02:55.349 Rcvd Ether Dst 00:00:a8:42:3b:6e Src 00:00:a8:42:52:22 Type 0800+(IP)IP Ver/HL 45, ToS 0, Len 2c, ID 4b7a, Flg/Frg 0, TTL 3c, Prtl 6 Cksum d82d, Src ac1001e2, Dst ac100122TCP from 172.16.1.226.49321 to 172.16.1.34.4680. . . 그림 3 – 모듈에서 다른 서버로의 연결 요청 (다른 서버에서 캡처한 추적 기록)
172.16.1.226 IP 인터페이스에 바인딩된 클라이언트 애플리케이션
첫 번째(116) 인터페이스가 다운될 경우에만 모듈이 두 번째(226) 인터페이스로 전환됩니다. 두 번째(226) 인터페이스에 대한 연결은 유지되지만, 첫 번째(116) 인터페이스에 대한 연결은 실패합니다.
13:14:43.884 Xmit Ether Dst 00:00:a8:43:52:22 Src 00:00:a8:42:3b:6e Type 0800+(IP)IP Ver/HL 45, ToS 0, Len 28, ID 5072, Flg/Frg 0, TTL 3c, Prtl 6 Cksum d339, Src ac100122, Dst ac1001e2TCP from 172.16.1.34.49186 to 172.16.1.226.telnet. . . 13:14:43.885 Rcvd Ether Dst 00:00:a8:42:3b:6e Src 00:00:a8:42:52:22 Type 0800+(IP)IP Ver/HL 45, ToS 0, Len 28, ID 53ef, Flg/Frg 0, TTL 3c, Prtl 6 Cksum cfbc, Src ac1001e2, Dst ac100122TCP from 172.16.1.226.telnet to 172.16.1.34.49186. . . 인터페이스 172.16.1.116이 실패함 – 소스 MAC 주소 변경 사항에 유의하십시오
13:15:56.718 Xmit Ether Dst 00:00:a8:43:52:22 Src 00:00:a8:42:3b:6e Type 0800+(IP)IP Ver/HL 45, ToS 0, Len 29, ID 50e7, Flg/Frg 0, TTL 3c, Prtl 6 Cksum d2c3, Src ac100122, Dst ac1001e2TCP from 172.16.1.34.49186 to 172.16.1.226.telnet. . . 13:15:56.719 Rcvd Ether Dst 00:00:a8:42:3b:6e Src 00:00:a8:43:52:22 Type 0800+(IP)IP Ver/HL 45, ToS 0, Len 29, ID 5552, Flg/Frg 0, TTL 3c, Prtl 6 Cksum ce58, Src ac1001e2, Dst ac100122TCP from 172.16.1.226.telnet to 172.16.1.34.49186. . .그림 4 – 첫 번째 인터페이스 장애 시 MAC 변화 (클라이언트 측에서 추적)
어떤 인터페이스를 통해 트래픽이 전송될지 어떻게 알 수 있나요?
여러 방법이 있습니다. 첫 번째는 원격 호스트나 네트워크에서 packet_monitor 또는 다른 프로토콜 분석기를 사용하여 소스 MAC 주소를 평가하는 것입니다. 그림 1부터 4까지를 참조하십시오.
두 번째는 netstat을 사용해 인터페이스를 확인하고, 트래픽을 생성한 후 netstat을 다시 실행해 비교하는 것입니다. 단 하나의 인터페이스만 "전송된 프레임" 카운터가 증가해야 합니다.
netstat -interface #sdlmux.m16.10.11-2; netstat -interface #sdlmux.m16.11.11-2. . .MAC Statistics: Received frames : 1598960 Received multicast and broadcast frames : 1564503 Received octets : 258513766 Transmitted frames : 531 Transmitted octets : 50850. . . MAC Statistics: Received frames : 1603838 Received multicast and broadcast frames : 1569292 Received octets : 259291185 Transmitted frames : 15 Transmitted octets : 947. . . ready 13:29:48ping 172.16.1.34Pinging host 172.16.1.34 : 172.16.1.34ICMP Echo Reply:TTL 60 time = 0 msICMP Echo Reply:TTL 60 time = 0 msICMP Echo Reply:TTL 60 time = 0 msICMP Echo Reply:TTL 60 time = 0 msHost 172.16.1.34 replied to all 4 of the 4 pingsready 13:29:55 netstat -interface #sdlmux.m16.10.11-2; netstat -interface #sdlmux.m16.11.11-2. . .MAC Statistics: Received frames : 1603142 Received multicast and broadcast frames : 1568591 Received octets : 259187870 Transmitted frames : 535 Transmitted octets : 51274. . . MAC Statistics: Received frames : 1607492 Received multicast and broadcast frames : 1572869 Received octets : 259880655 Transmitted frames : 15 Transmitted octets : 947. . .그림 5 – netstat을 사용한 전송된 프레임 카운터 비교
세 번째 방법은 다른 시스템의 서비스에 연결하여 어떤 로컬 소스 주소가 사용되는지 확인하는 것입니다. 명시적으로 다른 주소에 바인딩하지 않는 한 소스 IP 주소는 활성 인터페이스에 대응합니다.
netstat -numericActive connectionsProto Recv-Q Send-Q Local Address Foreign Address (state). . .tcp 0 0 172.16.1.116:49369 172.16.1.34:23 ESTABLISHED. . .그림 6 – 아웃바운드 연결에 사용되는 인터페이스
동일한 서브넷에 여러 인터페이스를 두는 것은 혼란만 야기할 뿐이며, 그 혼란을 감수할 만한 가치가 없다고 생각합니다. 어떤 이유로든 동일한 서브넷에 IP 주소를 추가해야 한다면, 첫 번째 인터페이스에 별칭을 추가하십시오.
ifconfig #sdlmux.m16.10.11-2 172.16.1.226 -add -alias
인터페이스 %phx_vos#sdlmux.m16.10.11-2에 IP 주소 172.16.1.226 추가
%phx_vos#sdlmux.m16.10.11-2: <UP, BROADCAST, RUNNING, NOFORWARDBROADCAST, KEEPAL+IVE> 172.16.1.116 netmask 0xffffff00 broadcast 172.16.1.255 Number of additional address(es): 1 172.16.1.226그림 7 – 인터페이스에 별칭 추가