Kial DNAT al 127.0.0.1 postulas specialan zorgon
Komprenu route_localnet kiam vi alidirektas eksteran trafikon al loopback-ligita prokura komponanto.
Servo aŭskultas sur 127.0.0.1:1080. Regulo DNAT direktas envenantan trafikon al tiu adreso, tamen la konekto malsukcesas. La servo povas esti sana kaj la NAT-regulo povas kongrui: IPv4-loopback-adresoj ricevas specialan traktadon ĉe enkursigo.
La route_localnet de Linukso regas ĉu adresoj 127/8 estas traktataj kiel marsaj adresoj dum enkursigado. Ĝia implicita valoro konservas la kutiman loopback-limon. Escepto specifa al interfaco povas esti grava por intenca loka alidirektada dezajno.
Tio klarigas kial funkcianta regulo de alia maŝino povas dependi de sysctl, kiun vi ne kopiis. Ĝi ne pravigas ŝalti la opcion ĉie.
La sekureca supozo ŝanĝiĝas kun la vojo
Loopback-ligado ofte estas uzata ĉar helpilo ne havas sendependan klientan aŭtentikigon. Se trafiko alvenanta de alia interfaco povas esti enkursigita tien, la liga adreso sola jam ne priskribas la atingeblan publikon. Limigu la enirajn fontojn, celon kaj pordon en la reala regulkompleto, inkluzive trafikon kiu asertas loopback-fontajn aŭ celadresojn kie tio gravas.
Reviziu la retan nomspacon enhavantan la servon. La loopback de ujo ne estas la loopback de la gastiganto, kaj ŝanĝi agordon de gastiganta interfaco ne aŭtomate kreas aŭskultanton en la ujo.
rp_filter respondas al alia demando pri validigo de fonta vojo. Malŝalti ĝin tutmonde ne estas ĝenerala anstataŭaĵo por kompreni loopback-enkursigadon. Same, ip_nonlocal_bind koncernas ligadon de ingoj al nelokaj adresoj, ne la ĝustigon de ĉi tiu DNAT-vojo.
Fine, la alidirektita protokolo devas konveni al la aŭskultanto. Sendi krudan HTTP- aŭ TLS-trafikon al SOCKS-pordo ankoraŭ bezonas tradukilon; enkursiga escepto ne povas provizi la mankan intertraktadon.