dig myip.opendns.com @resolver1.opendns.com이 sshuttle의 프록시를 사용하지 않는 이유는 무엇입니까?

dig myip.opendns.com @resolver1.opendns.com이 sshuttle의 프록시를 사용하지 않는 이유는 무엇입니까?

나는 훌륭한 기술을 사용하고 있습니다.쉘 스크립트에서 외부 IP 주소를 어떻게 얻나요?내 공개 IP 주소 찾기:

dig +short myip.opendns.com @resolver1.opendns.com

또한 SSH 터널의 프록시로 sshuttle을 사용합니다. 다음 명령을 사용하여 모든 포트 및 IP에서 트래픽 전달(DNS 요청 포함)을 시작합니다.

sshuttle --dns -vr usr@sshserver 0/0

에이전트가 시작된 후 방문합니다.https://canihazip.com/s내 외부 IP가 변경되었는지 확인하세요. 그렇습니다. 하지만 dig 명령을 다시 실행하면 에이전트가 시작되기 전에 보고한 것과 동일한 외부 IP가 보고됩니다.

자세한 출력에서 ​​sshuttle은 다른 dig 명령을 전달하고 확인하는 것 같습니다.https://dnsleaktest.com예상대로 프록시 반대편의 IP만 표시됩니다. 내가 알 수 있는 한 sshuttle이 작동하는 것 같습니다.

dig 명령이 프록시보다 먼저 내 외부 IP를 보고하는 이유를 설명할 수 있는 사람이 있습니까? 내 목표는 opendns 서버가 요청이 내 SSH 서버에서 발생한 것으로 생각하도록 만드는 것입니다.

이건 상상을 조금 벗어난 일이지만 Wireshark를 잠깐 살펴보니 DNS 트래픽을 필터링할 때 Wireshark에서는 위의 DIG 명령 외에는 어떤 DNS 요청도 보이지 않습니다. 명령이 프록시를 우회하고 있습니다.

외부 IP를 찾기 위해 다른(덜 우아한) 방법을 사용하는 것은 좋지만 이로 인해 다음과 같은 질문이 생깁니다. sshuttle을 우회하기 위해 할 수 있는 다른 방법이 있습니까?

답변1

이제 Shuttle 명령을 실행할 때 디버그 메시지를 표시하는 옵션을 사용했으므로 -v셔틀이 일부 iptables 규칙을 생성한 것을 확인할 수 있습니다. 규칙 중 하나는 다음과 같습니다.

iptables -t nat -A sshuttle-12300 -j REDIRECT --dest <nameserver>/32 -p udp --dport 53 --to-ports 12299

위의 규칙은 Shuttle 프록시 포트 로 전송된 <nameserver>DNS 요청을 리디렉션합니다 . Shuttle은 파일 <nameserver>에서 이를 찾아 이를 기반으로 iptables 규칙을 자동으로 생성합니다./etc/resolv.conf

따라서 dig 명령이 /etc/resolv.conf파일에 정의된 이름 서버를 사용하여 DNS 쿼리를 수행하면 sshuttle로 프록시되지만 그렇지 않은 경우에는 프록시되지 않습니다.

resolver1.opendns.com귀하의 경우 해당 주소는 208.67.222.222귀하의 주소에 정의되어 있지 않으므로 /etc/resolv.confsshuttle에 의해 프록시되지 않습니다.

답변2

게이트웨이에는 두 개의 외부 IP 주소가 있습니다. 게이트웨이에서 실행되는 NAT는 일종의 로드 밸런싱을 사용합니다. 이는 대상 IP 또는 프로토콜 유형을 기반으로 할 수 있습니다. 이 경우 DNS 쿼리와 HTTP 패킷의 소스 IP 주소가 달라집니다.

관련 정보