Program działający pod proxychains rozwiązuje zwykłą nazwę hosta na nieznany zakres adresów. Ten adres może być wewnętrzną wartością księgową otoczki, a nie odpowiedzią DNS z internetu.

W trybie proxy-DNS proxychains-ng może zapamiętać nazwę hosta, zwrócić aplikacji syntetyczny adres, a później przetłumaczyć tę wartość z powrotem na nazwę hosta, gdy przechwycone połączenie zostanie otwarte przez proxy.

Symbol zastępczy nie jest adresem wyjściowym IP

Przykładowa konfiguracja dokumentuje proxy_dns i remote_dns_subnet. Zarezerwowany zakres mapowania jest konfigurowalny. To nie jest adres, którego należy oczekiwać do pingowania ani do publikowania jako publiczne źródło proxy.

Zależy to od tego, czy odpowiednie wywołania wyszukiwania nazwy i połączenia są przechwytywane w zamierzonym procesie. Program, który wykonuje własny DNS innym mechanizmem, przechowuje symbol zastępczy do późniejszego niepowiązanego użycia lub omija ścieżkę podpiętego gniazda, może zachowywać się inaczej.

To ograniczenie wyjaśnia, dlaczego syntetyczny adres w logu sam w sobie nie jest dowodem, że cała aplikacja prawidłowo korzysta ze zdalnego DNS. Podobnie osobne narzędzie DNS poza otoczoną procesem aplikacją nie testuje zmapowanego połączenia aplikacji.

Odróżnij symbol zastępczy aplikacji, rzeczywisty adres docelowy wybrany po stronie proxy i publiczne wyjście widziane przez witrynę. Pełnią różne funkcje i nie muszą się zgadzać.

Podczas debugowania trzymaj nazwę hosta w notatkach i zidentyfikuj dokładny otoczony proces oraz konfigurację. Ręczne zastąpienie podejrzanego symbolu zastępczego może utracić mapowanie potrzebne otoczce do odzyskania tej nazwy hosta, zamieniając zrozumiałe pośrednictwo w połączenie z niewłaściwym celem.

Powiązane artykuły