CentOS에서 재귀 경로 조회가 가능한지 알고 싶습니다. 시나리오는 다음과 같습니다.
내 컴퓨터에는 2개의 네트워크 카드가 있습니다. NIC1에는 기본 게이트웨이가 있습니다. NIC2는 2개의 IP 서브넷(173.144.4.x 및 172.45.5.x)을 통해서만 외부 세계와 통신하면 됩니다. 그리고 NIC2는 프록시(192.168.1.1)를 통과해야 합니다. 트래픽에 영향을 주기 위해 두 번째 네트워크 카드에 이 구성을 추가하는 방법은 다음과 같습니다.
Destination Next-Hop
173.144.4.0/24 172.20.25.1
172.45.5.0/24 172.20.25.1
172.20.25.1 192.168.1.1
위에서 처음 2개는 액세스해야 하는 외부 서브넷입니다. 172.20.25.1 --> 프록시 서버 IP. 192.168.1.1 --> NIC2가 위치한 서브넷의 기본 게이트웨이 주소입니다.
[EDIT2] 이것은 상위 수준 토폴로지입니다.
프록시는 투명 프록시가 아닙니다. CentOS에서는 2개의 서로 다른 게이트웨이가 있는 2개의 NIC를 가질 수 없기 때문에 NIC1에만 기본 게이트웨이가 구성되어 있습니다. NIC2는 처음 2개의 경로가 추가된 인터넷을 통해 2개의 서브넷과 통신해야 합니다. 그리고 이 다음 홉(이 서브넷의 게이트웨이)을 사용하여 프록시 서버에 도달할지 여부를 나타내는 프록시 서버에 대한 다른 경로를 추가합니다.
이론적으로 머신이 외부 서브넷에 액세스하려고 하면 라우팅 테이블을 확인하고 다음 홉을 프록시 IP로 보고 라우팅 테이블을 다시 확인하여 프록시 IP에 대한 다음 홉이 기본 게이트웨이임을 찾습니다.
이것이 Linux에서 작동합니까? Linux는 위에서 언급한 것처럼 재귀 경로 조회를 수행합니까?
미리 감사드립니다.
답변1
정책 라우팅에 더 복잡한 설정을 사용할 수 있지만 (사용 중인 것으로 보이는) 기본 변형은 한 수준 결정입니다.
운영 체제는 패킷의 대상 주소를 보고 일치하는 경로를 찾은 다음 해당 경로의 다음 홉으로 패킷을 보냅니다.
그게 다야.
로컬 서브넷에 대한 경로가 자동으로 추가됩니다.
이것의 한 가지 결과는모두경로의 노드에는 올바른 다음 홉 결정을 내리기 위해 충분한 라우팅 정보가 필요합니다. 이는 다음을 수행해야 함을 의미합니다.모두노드는 원래 노드뿐만 아니라 초보자들이 흔히 저지르는 실수입니다.
그래서 당신이 무엇을 하려고 하든(제가 완전히 이해하지는 못하지만) 아마도 효과가 없을 것입니다.
또한 두 서브넷이 모두 인터넷에 연결되어 있는 경우(프록시 또는 기타 수단을 통해) 일반적으로 두 서브넷을 동시에 사용하여 인터넷에 액세스할 수 없습니다.
답변2
이에 적합한 두 가지 유형의 프록시가 있습니다.
- 일반(명시적) 프록시
- 투명 프록시(강제 프록시)
문제는 시스템이 게이트웨이에 패킷을 전달하면 더 이상 패킷이 라우팅되는 방식을 결정할 수 없다는 것입니다. 게이트웨이는 일반적으로 대상 IP 주소만을 기반으로 자체 라우팅 결정을 내립니다. 라우팅 테이블.
라는 메커니즘이 있었습니다.소스 라우팅이를 통해 패킷이 취해야 할 경로를 지정할 수 있지만 이를 사용해야 할 타당한 이유가 거의 없으며 많은 사악한 행위에 유용한 것으로 입증되었으므로 보안상의 이유로 거의 모든 최신 라우터 및 게이트웨이는 모든 소스 라우팅 옵션을 사용합니다. 모든 패킷에 존재하는 것은 무시됩니다. 보안을 위해 라우터/게이트웨이를 감사하는 경우 소스 라우팅을 활성화하면 라우터가 감사에 실패할 가능성이 높습니다.
일반 프록시 사용
프록시를 사용하여 무언가에 연결해야 한다면 TCP/IP 라우팅 측면에서 연결해야 합니다.도착하다연기. 그런 다음 상위 프로토콜 계층에서 클라이언트 애플리케이션이상담원에게 물어보세요실제 목적지까지 다음 연결을 하십시오.
173.144.4.0/24 및 172.45.5.0/24 네트워크에 액세스하기 위해 프록시가 필요한 경우 첫 번째 단계는 이러한 네트워크에 연결하려면 프록시가 필요함을 클라이언트 애플리케이션에 알리는 것입니다. 라우팅 테이블만으로는 이 작업을 수행할 수 없습니다. 특정 네트워크에 대해 프록시를 사용하도록 모든 애플리케이션을 구성하는 통일된 방법은 없습니다. 각 애플리케이션은 자체 구성 체계를 가질 수 있습니다.
클라이언트 애플리케이션이 웹 서버인 경우 다음을 사용할 수 있습니다.에이전트 자동 구성 파일, 종종 wpad.dat또는 이라고 합니다 proxy.pac.
자세한 내용은 다음을 참조하세요.https://en.wikipedia.org/wiki/Web_Proxy_Auto-Discovery_Protocol
투명 프록시 사용
와투명 프록시, 그러면 상황이 달라집니다. 클라이언트는 대상에 직접 연결되어 있다고 "생각"하지만(필요한 경우 평소와 같이 게이트웨이를 사용하여) 일부 라우터, 방화벽 또는 기타 네트워크 장치가 연결을 프록시로 리디렉션합니다. 프록시는 실제 대상인 척해야 합니다. 이는 TLS 연결, 인증서 고정 및 기타 추가 보안 조치의 편재성으로 인해 점점 더 어려워지고 있습니다.
프록시가 투명 프록시인 경우 최종 호스트의 라우팅 테이블은 173.144.4.0/24 및 172.45.5.0/24 네트워크로 이동하는 모든 트래픽을 기본 게이트웨이로 전달하도록 구성되어야 합니다.이 트래픽이 투명 프록시로 이동하도록 기본 게이트웨이를 구성해야 합니다.. 투명 프록시가 클라이언트와 동일한 네트워크 세그먼트에 있는 경우 일부 ARP 트릭을 사용하여 트래픽을 투명 프록시로 강제할 수 있지만, 귀하의 경우 프록시가 게이트웨이 뒤에 있으므로 리디렉션을 수행하도록 게이트웨이를 구성해야 합니다.
두 경우 모두 두 번째 단계는 다음을 구성하는 것입니다.대리인대상이 173.144.4.0/24 및 172.45.5.0/24 네트워크에 있는 경우에만 최종 호스트의 요청을 수락하고 최종 호스트의 다른 요청은 거부합니다.