Чаму DNAT на 127.0.0.1 патрабуе асаблівай увагі
Разумейце route_localnet пры перанакіраванні знешняга трафіку на proxy-кампанент, прывязаны да loopback.
Сэрвіс слухае 127.0.0.1:1080. Правіла DNAT накіроўвае ўваходны трафік на гэты адрас, але злучэнне не ўстанаўліваецца. Сэрвіс можа быць здаровым, а правіла NAT — супадаць: адрасы loopback у IPv4 атрымліваюць асаблівую апрацоўку пры маршрутызацыі.
route_localnet у Linux вызначае, ці лічацца адрасы 127/8 марсіянскімі падчас маршрутызацыі. Значэнне па змаўчанні захоўвае звычайную мяжу loopback. Выключэнне для канкрэтнага інтэрфейса можа быць мэтазгодным для наўмыснай схемы лакальнага перанакіравання.
Гэта тлумачыць, чаму працоўнае правіла з іншай машыны можа залежаць ад sysctl, які вы не скапіявалі. Але гэта не апраўдвае ўключэнне опцыі паўсюдна.
Дапушчэнне бяспекі змяняецца разам з маршрутам
Прывязка да loopback часта выкарыстоўваецца таму, што дапаможны кампанент не мае самастойнай аўтэнтыфікацыі кліентаў. Калі трафік з іншага інтэрфейса можа быць накіраваны туды, адзін толькі адрас прывязкі ўжо не апісвае дасяжную аўдыторыю. Абмяжуйце крыніцы ўваходу, прызначэнне і порт у фактычным наборы правілаў, у тым ліку трафік, які заяўляе адрасы крыніцы або прызначэння loopback, дзе гэта датычыцца.
Праверце сеткавае прастору імёнаў, якая змяшчае сэрвіс. Loopback кантэйнера — не loopback хоста, і змяненне налады інтэрфейса хоста не стварае аўтаматычна слухача ў кантэйнеры.
rp_filter адказвае на іншае пытанне — пра праверку шляху крыніцы. Поўнае адключэнне не з'яўляецца агульнай заменай разумення маршрутызацыі loopback. Гэтак жа ip_nonlocal_bind датычыцца прывязкі сокетаў да нелакальных адрасоў, а не таго, каб зрабіць гэты шлях DNAT правільным.
Нарэшце, перанакіраваны пратакол павінен адпавядаць слухачу. Адпраўка сырога HTTP або TLS трафіку на порт SOCKS па-ранейшаму патрабуе перакладчыка; выключэнне маршрутызацыі не можа даць адсутную ўзгодненасць.