다주홈 시스템은 여러 IP 인터페이스가 있는 시스템입니다. 이러한 인터페이스는 동일하거나 다른 서브넷에 있을 수 있습니다. 오늘 저는 FTP 및 NDMP와 같은 프로토콜을 고려하고 싶습니다. 두 프로토콜 모두에서 서버는 클라이언트의 연결을 수락한 다음 클라이언트에 새 연결을 다시 연결합니다. 다주홈 시스템에서는 모든 문제를 일으키는 이 새로운 연결입니다.
두 프로토콜 모두에서 원본 IP 주소는 클라이언트가 원래 연결한 IP 주소를 기반으로 하지 않습니다. 대신 클라이언트로 돌아가는 데 사용되는 게이트웨이와 연결된 인터페이스를 기반으로 합니다.
예를 들어 다음 인터페이스 및 라우팅 테이블이 지정됩니다.
ifconfig -all
Number of interface(s) under IP: 5
%phx_vos#loop.m16: <UP, LOOPBACK, RUNNING> 127.0.0.1 netmask 0xff000000
%phx_vos#enetA: <UP, BROADCAST, RUNNING, NOFORWARDBROADCAST, KEEPALIVE> 172.16.1.50 netmask 0xffffff00 broadcast 172.16.1.255
%phx_vos#enetZ: <UP, BROADCAST, RUNNING, NOFORWARDBROADCAST, KEEPALIVE> 192.168.77.50 netmask 0xffffff00 broadcast 164.152.77.255
ready 15:33:51
route print
Default Gateway: 192.168.77.1ready 15:33:57IP 주소가 10.1.1.1인 클라이언트가 172.16.1.50에 연결하여 이 연결을 "A"라고 부릅니다. 패킷을 10.1.1.1로 보내려면 모듈은 192.168.77.0/24 네트워크에 있는 기본 게이트웨이를 사용해야 하므로 192.168.77.50 인터페이스를 사용해야 합니다. 연결 "A"에 대해 모든 트래픽에 대해 이 인터페이스를 10.1.1.1로 사용합니다. 그러나 TCP 헤더의 IP 주소는 172.16.1.50이 되는데, 이는 클라이언트가 A와 연결되어 있는 IP 주소이기 때문입니다. 그러나 모듈이 10.1.1.1에 새 연결을 만들 때 연결 "B"를 만들면 STCP는 기본적으로 192.168.77.50을 소스 IP 주소로 선택합니다. 게이트웨이가 연결된 인터페이스이기 때문에 이 작업을 수행합니다. 응용 프로그램은 이것을 재정의할 수 있지만 FTP나 NDMP도 재정의할 수 없습니다.
주요 고려 사항은 라우터의 방화벽 및 액세스 목록의 구성입니다. 클라이언트 방화벽 또는 라우터 ACL이 172.16.1.50의 연결만 허용하도록 구성된 경우 192.168.1.50의 연결이 실패합니다. 해결책은 172.16.1.0/24 서브넷의 라우터를 사용하여 10.1.1.1로 가는 경로를 만드는 것입니다(물론 선택한 라우터는 10.1.1.1에 도달할 수 있어야 합니다) 또는 방화벽 및 라우터 액세스 목록에 도달할 수 있지만 192.168.1.50을 허용하도록 재구성됩니다.
다음 스크립트로 테스트할 수 있습니다.
stcp_callssocketconnect -name 10.1.1.1 -port Nsocketbind -name 172.16.1.50 -port 0connect -name 10.1.1.1 -port N물론 클라이언트의 실제 IP 주소로 10.1.1.1을, 클라이언트가 연결하는 IP 주소로 172.16.1.50을 교체해야 합니다. 포트 N은 클라이언트에서 열려 있고 방화벽 및 라우터 ACL에서 허용하는 일부 포트여야 합니다.
첫 번째 연결은 기본 IP 주소를 사용하며 두 번째 연결은 172.16.1.50을 사용합니다. 첫 번째 연결 시간 (1 분 정도 소요됩니다) 또는 연결 거부 오류와 함께 즉시 반환하지만 두 번째 연결 작동 (당신이 볼 수있는 모든 "stcp:"프롬프트입니다) 당신은 해결해야 할 방화벽 이나 라우터 ACL 문제가 있음을 확신 할 수 있습니다.