나는 실험하고있다. ping 명령에 Windows 7.
의 도움에 따르면 ping 명령.
-j host-list 호스트 목록 (IPv4 전용)을 따라 느슨한 소스 경로.
내 컴퓨터는 가정용 LAN에 있습니다. 기본 게이트웨이는 다음과 같습니다. 192.168.199.1. 나는 다음의 2 ping 명령을 시도했다.
첫 번째는 외부 호스트에 직접 핑입니다.
ping 114.80.143.158
그것은 작동합니다.
그 다음에 나는 loose source routing이 명령은 다음과 같습니다.
ping -j 192.168.199.1 114.80.143.158
그러나 그것은 나에게 준다. Request timed out.
내 모든 요청은 default gateway, 그래서 loose source routing ping 작동해야합니다. 하지만 왜 핑을 통과하지 못하는 걸까요?
답변:
ping -j 작업? 루즈 소스 라우팅. ping -j, tracert -j 또는 pathping -g는 목적지로 진행하기 전에 패킷이 통과해야하는 시스템을 지정하는 데 사용할 수 있습니다.
그러나 소스 라우팅은 악용 가능성이 매우 높으므로 (나중에 설명) 따라서 대부분의 네트워크 관리자는 경계 라우터에서 모든 소스 라우팅 패킷을 차단합니다. .
따라서 실제로는 Loose Source Routes가 작동하지 않습니다.
Reverse Route (소스 라우팅을 사용하여 수행 할 수 있음) 기능을 사용하면 매우 유용 할 수 있으므로 이는 불행한 일입니다. tracert 과 pathping 네트워크 문제를 진단합니다.
역 경로 자체는 일반적인 Traceroute 출력에서 완전히 보이지 않습니다.
흥미로운 기사가 있습니다. 소스 라우팅의 위험 느슨한 소스 라우팅이 활성화 될 때 위험을 설명합니다.
소스 라우팅은 패킷의 발신자가 패킷이 네트워크를 통해 전송해야하는 경로를 지정하십시오.
패킷이 네트워크를 통해 이동함에 따라 각 라우터 "대상 IP 주소"를 검사하고 다음 홉을 선택합니다. 패킷을에 전달하십시오. 소스 라우팅에서 "소스"(즉, 발신자)는 이러한 결정 중 일부 또는 전부를 수행합니다.
엄격한 소스 라우팅에서 보낸 사람은 정확한 경로를 지정합니다. 패킷을 가져와야합니다. 이것은 거의 사용되지 않습니다.
보다 일반적인 형태는 느슨한 소스 레코드 경로 (LSRR)입니다. 보낸 사람이 패킷을 통과해야하는 하나 이상의 홉을 보낸다.
LSRR은 해킹을 목적으로 여러 가지 방법으로 사용될 수 있습니다. . 때때로 컴퓨터는 인터넷에 연결되지만 연결할 수는 없습니다. (그것은 10.0.0.1과 같은 개인 주소 사용). 그러나 패킷을 전달하는 양측에 도달 할 수있는 다른 기계. 그런 다음 누군가가 인터넷을 통해 해당 개인용 컴퓨터에 연결할 수 있습니다. 그 중간 기계를 통한 소스 라우팅.
출처 원본 라우팅
시스코 라우터는 일반적으로 소스 경로를 받아 처리합니다. 하지 않으면 네트워크가 그것에 의존하고 소스 라우팅을 사용하지 않아야합니다. .
소스 라우팅은 패킷의 발신자가 패킷이 네트워크를 통해 전송해야하는 경로를 지정하십시오. 마찬가지로 패킷이 네트워크를 통해 이동하면 각 라우터는 목적지 IP 주소를 선택하고 패킷을 전달할 다음 홉을 선택하십시오 에. 소스 라우팅에서 "소스"(즉, 발신자)는 일부 또는 이러한 모든 결정.
공격자는 소스 라우팅을 사용하여 패킷을 네트워크의 특정 부분으로 강제 전송함으로써 네트워크를 검사 할 수 있습니다. 소스 라우팅을 사용하면 공격자는 네트워크의 토폴로지 또는 기타 정보를 수집 할 수 있습니다. 공격 수행에 유용한 정보. 동안 공격자는 소스 라우팅을 사용하여 패킷을 기존 보안 제한 사항을 무시하십시오.
출처 라우터에 대해 IP 소스 라우팅이 활성화되었습니다 (CiscoIpsourceRoutingEnabled).
인터넷을 통한 모든 연결은 실제로 두 경로에 따라 달라집니다. 시스템에서 서버로의 경로 및 해당 서버에서의 경로 다시 시스템으로. 이 경로는 완전히 (그리고 종종) 있습니다. 다른 (비대칭). 서로 다르면 연결에 문제가 있습니다. 서버에 대한 경로 또는 서버에서 다시 라우트하십시오. traceroute 출력에 반영된 문제점 실제로 추적에서 명백한 시스템과 함께 거짓말을하지 않을 수 있습니다. 그것은 오히려 반대 방향의 다른 시스템과 함께 시스템은 추적에서 문제의 원인을 찾는 시스템입니다.
따라서 여러분의 서버에 대한 traceroute는 여러분에게 그림. 나머지 절반은 귀환 경로 또는 역방향 경로입니다. 그래서 방법 그 길을 볼 수 있니?
옛날에는 traceroute가있는 소스 라우팅을 사용할 수있었습니다. 호스트에서 역 추적을 참조하십시오. 아이디어는 느슨한 소스 경로라고하는, 시스템을 지정하는 패킷은 대상으로 진행하기 전에 통과해야합니다.
역방향 경로를보기 위해 느슨한 소스 라우팅을 사용할 수있는 능력 꽤 편리합니다. 불행히도 소스 라우팅은 큰 잠재력을 가지고 있습니다. 남용 때문에 대부분의 네트워크 관리자가 모든 것을 차단합니다. 국경 라우터에서 소스 라우팅 패킷. 그래서, 실제로, 느슨한 소스 경로가 작동하지 않습니다.
요즘, 당신은 아마 그 반대의 실행 희망 traceroute는 추적하고자하는 시스템이 traceroute를 가지고 있는지 여부입니다. 시설에 자신의 웹 사이트. 많은 시스템 및 유즈넷 제공 업체 특히 웹 페이지에서 traceroute을 실행할 수 있습니다. 시스템을 다시 귀하의 것으로 변경하십시오. 그들의 시스템에 대한 당신의 흔적과 함께, 이것은 당신에게 그림의 나머지 절반을 줄 수 있습니다. 나는 목록을 가지고있다. 유즈넷 공급자 추적 루트 페이지 이리 .
출처 Tracert 사용
요즘, IP 소스 경로는 도입되는 다양한 보안 문제로 인해 거의 모든 곳에서 무시됩니다. 보안을 위해 IP 라우팅에 의존하는 것은 좋지 않지만 소스 라우팅을 사용하면 불필요하게 방화벽을 우회하는 것은 물론, 너의 IP 주소를 속여 라. , 실제로 좋은 용도는 없습니다.
다시 말해 소스 경로가있는 패킷은 보안 정책에 의해 삭제됩니다. 따라서 평상시와 동일한 경로를 지정해도 회신을받지 못합니다.
Linux 기반 라우터에서는 여전히 sysctl을 설정하여이 기능을 활성화 할 수 있습니다.
sysctl -w net.ipv4.conf. & lt; 인터페이스 & gt; .accept_source_route = 1
FreeBSD (pfSense)에는 sysctls가 있습니다. net.inet.ip.sourceroute 과 net.inet.ip.accept_sourceroute.