Wêrom't DNAT nei 127.0.0.1 spesjale soarch freget
Begryp route_localnet by it trochstjoeren fan eksterne ferkear nei in loopback-bûn proxy-ûnderdiel.
In tsjinst harket op 127.0.0.1:1080. In DNAT-regel stjoert ynkommend ferkear nei dat adres, mar de ferbining mislearret. De tsjinst kin sûn wêze en de NAT-regel kin oerienkomme: IPv4-loopbackadressen krije in spesjale routingbehanneling.
De route_localnet fan Linux bepaalt oft adressen 127/8 by it rûtsjen as marsadressen behannele wurde. De standertwearde behâldt de gewoane loopbackgrins. In útsûndering foar in beskaat ynterface kin relevant wêze foar in bewust pleatslik trochstjoerûntwerp.
Dat ferklearret wêrom't in wurkjende regel fan in oare masine ôfhingje kin fan in sysctl dy't jo net kopiearre hawwe. It rjochtfeardiget net om de opsje oeral oan te setten.
De feiligensoanname feroaret mei de rûte
In loopbackbining wurdt faak brûkt om't in helper gjin selsstannige kliïntautentikaasje hat. As ferkear fan in oar ynterface dêr hinne rûtsje kin, beskriuwt it bindadres allinnich net mear it berikbere publyk. Behein de ynkommende boarnen, bestimming en poarte yn 'e eigentlike regelset, ynklusyf ferkear dat loopback-boarne- of bestimmingsadressen beweart wêr't dat relevant is.
Besjoch de netwurknammeromte dy't de tsjinst befettet. De loopback fan in container is net dy fan de host, en it feroarjen fan in host-ynterface-ynstelling makket net automatysk in harker yn 'e container.
rp_filter beantwurdet in oare fraach oer falidaasje fan it boarnepaar. It globaal útsette is gjin algemien ferfanging foar it begripen fan loopbackrouting. Likegoed giet ip_nonlocal_bind oer it binen fan sockets oan net-lokale adressen, net oer it korrekt meitsjen fan dit DNAT-paar.
Ta beslút moat it trochstjoerde protokol by de harker passe. It stjoeren fan rau HTTP- of TLS-ferkear nei in SOCKS-poarte freget noch altyd in oersetter; in routingútsûndering kin de ûntbrekkende ûnderhanneling net leverje.