Redsocks слухае на лакальнай пятлі, але трафік VPN не даходзіць

Тунэль узнімаецца, кліент можа пінгаваць шлюз, але кожны вэб-запыт праз шлях проксі памірае. Працэс redsocks запушчаны і яго порт слухае, таму паслуга выглядае здаровай з самога шлюза. Няўдалым з'яўляецца этап дастаўкі: пакет, перанакіраваны з тунэля, не трапляе на сокет, які вы запусцілі. Адрас прывязкі і мэта перанакіравання павінны супадаць, і звычайна правяраецца толькі адзін з іх.

Куды насамрэч трапляе перанакіраваны пакет

Празрыстае проксі на шлюзе выкарыстоўвае REDIRECT у табліцы nat у PREROUTING, каб перапісаць прызначэнне ўваходнага злучэння на лакальны порт. Перапісанае прызначэнне — гэта лакальны адрас так, як яго бачыць інтэрфейс, на які прыйшоў пакет, а не адрас лакальнай пятлі працэсу, які стартаваў дзесьці іншым. Слухач, прывязаны толькі да 127.0.0.1, прымае злучэнні, якія ўжо былі лакальнымі на хасце, і гэта менавіта той выпадак, які працягвае працаваць, пакуль трафік тунэля падае. Уласная лакальная пятля кліента — гэта трэці адрас, і яна ніколі не з'яўляецца мэтай правіла шлюза.

Таму, перш чым чапаць уліковыя даныя верхняга ўзроўню, усталюйце два факты: на які лакальны адрас правіла перапісвае і да якога адраса прывязаны сокет проксі.

Чытайце слухач і правіла перанакіравання разам

Друкуйце табліцу сокетаў і правілы nat за адзін праход, бо правіла, якое паказвае на порт, якім ніхто не валодае, выглядае гэтак жа, як правіла, якое паказвае на няправільны адрас. sudo ss -ltnp | grep redsocks паказвае адрас прывязкі і працэс-уладальнік. sudo iptables -t nat -S PREROUTING паказвае мэту REDIRECT, а sudo iptables -t nat -L PREROUTING -v -n паказвае, ці нешта ёй адпавядала.

Пераход да карыстацкага ланцуга з назвай REDSOCKS нічога не дае, калі гэты ланцуг не існуе і не нясе патрэбныя выключэнні і дзеянне REDIRECT. Чытайце ланцуг, у які ён пераходзіць, з дапамогай sudo iptables -t nat -S REDSOCKS, а не дапускайце, што назва робіць працу.

Затым параўнайце два значэнні. Калі правіла перанакіроўвае на адрас шлюза на порце 12345, а слухач паведамляе 127.0.0.1:12345, неадпаведнасць тлумачыць збой без любой дадатковай дыягностыкі.

Прывязвайце вузка, затым абмяжуйце, што можа дасягнуць

Прыкладная канфігурацыя верхняга ўзроўню па змаўчанні ставіць слухач на лакальную пятлю з добрай прычыны: празрыстае проксі прымае злучэнні ад імя любога, хто можа да яго дасягнуць. Змена прывязкі на 0.0.0.0 выпраўляе дастаўку і адначасова адкрывае порт на ўсіх інтэрфейсах, што з'яўляецца зменай бяспекі, а не нейтральным рамонтам. Аддавайце перавагу прывязцы да пэўнага лакальнага адраса, на які нацэлена перанакіраванне, і трымайце порт закрытым на недавераных інтэрфейсах. Калі шырэйшая прывязка непазбежная, дадайце правіла міжсеткавага экрана хоста, якое дазваляе толькі дыяпазон крыніцы тунэля і ўласны лакальны трафік шлюза.

Адкрыццё порта на публічным інтэрфейсе ніколі не патрабуецца для перанакіраванага трафіку VPN, бо злучэнне завяршаецца лакальна пасля перапісвання. Не выкрывайце проксі інтэрнэту, каб прымусіць працаваць лакальнае перанакіраванне.

Давядзіце гэта новым злучэннем з кліента

Тэстуйце з рэальнага VPN-кліента свежым TCP-злучэннем, а не з абалонкі на шлюзе. curl -sS -o /dev/null -w '%{http_code}\n' http://example.com на кліенце правярае перанакіраваны шлях ад пачатку да канца.

Затым пацвердзіце, што прамое злучэнне да слухача з недаверанай сеткі ўсё яшчэ адхіляецца, і што ўласнае зыходнае злучэнне проксі не захопліваецца зноў тым жа правілам. Рэкурсіўнае захопліванне выглядае як проксі, які злучаецца сам з сабой і ніколі не завяршае запыт. Дадайце прызначэнне проксі ў набор выключэнняў або пазначце яго зыходныя пакеты, каб ланцуг іх прапускаў.

Нарэшце, памятайце, што гэты шлях не пакрывае. Звычайнае перанакіраванне TCP у redsocks не ператварае UDP, QUIC ці DNS у трафік SOCKS, а прыватныя прызначэнні звычайна патрабуюць яўных выключэнняў. Паспяховы лакальны тэст даказвае толькі шлях лакальнай пятлі, які ніколі не быў праблемай.