Чаму змена DNS не можа наладзіць проксі SOCKS
Тлумачыць, чаму накіраванне імені хоста сайта на сервер SOCKS не прымушае неналаджаны браўзер выкарыстоўваць проксі.
Змена адказу DNS мяняе толькі адрас, да якога падключаецца браўзер. Яна не мяняе пратакол, на якім браўзер гаворыць пасля падключэння.
Пры адкрыцці звычайнага адраса HTTP браўзер адпраўляе HTTP. Пры адкрыцці адраса HTTPS ён запускае TLS для гэтага сайта. Сервер SOCKS5 чакае спачатку сваіх уласных перамоваў: выбару метаду, любой аўтэнтыфікацыі і запыту з назвай пункта прызначэння. Неналаджаны браўзер нічога з гэтага не адпраўляе.
Гэта тлумачыць, чаму дасяжны слухач Dante можа адразу зачыніць злучэнне пасля змены DNS. Сэрвіс можа быць здаровы; уваходныя байты належаць няправільнаму пратаколу. Перанос слухача на порт 80 або 443 не пераўтварае гэтыя байты ў SOCKS.
Наладзьце інтэрфейс SOCKS браўзера, напрыклад налады SOCKS у Firefox, або наладу проксі для канкрэтнай праграмы, каб ён выконваў рукапацісканне і прасіў проксі злучыцца далей. Файл PAC можа выбраць падтрыманы маршрут проксі для праграм, якія яго выкарыстоўваюць. Гэта ўсё яшчэ асобная налада проксі, а не ўласцівасць запісу A або AAAA.
HTTPS дадае яшчэ адну перашкоду для ідэі толькі з DNS. Браўзер працягвае чакаць ідэнтычнасць сайта з адраса. Сертыфікат для хоста проксі не можа задаволіць гэтае чаканне проста таму, што DNS накіраваў злучэнне туды.
Празрыстае ўмяшанне ў сетку — гэта іншая схема, якая ўключае маршрутызацыю і сумяшчальнае праграмнае забеспячэнне для перахопу. Яго нельга атрымаць, вяртаючы адрас сервера SOCKS з DNS.