Proč DNAT na 127.0.0.1 vyžaduje zvláštní péči
Pochopte route_localnet při přesměrování externího provozu na proxy komponentu vázanou na loopback.
Služba naslouchá na 127.0.0.1:1080. Pravidlo DNAT směruje příchozí provoz na tuto adresu, ale spojení přesto selže. Služba může být v pořádku a pravidlo NAT může odpovídat: adresy loopback v IPv4 mají zvláštní zacházení při směrování.
route_localnet v Linuxu určuje, zda se adresy 127/8 při směrování považují za marsovské adresy. Výchozí hodnota zachovává obvyklou hranici loopback. Výjimka pro konkrétní rozhraní může být relevantní pro záměrný návrh místního přesměrování.
To vysvětluje, proč funkční pravidlo z jiného stroje může záviset na sysctl, který jste nezkopírovali. Neospravedlňuje to však zapnutí volby všude.
Bezpečnostní předpoklad se mění s trasou
Vazba na loopback se často používá proto, že pomocný komponent nemá nezávislé ověřování klientů. Pokud lze na něj směrovat provoz z jiného rozhraní, samotná adresa vazby už nepopisuje dosažitelné publikum. Omezte zdroje vstupu, cíl a port ve skutečném souboru pravidel, včetně provozu, který tvrdí zdrojové nebo cílové adresy loopback, pokud je to relevantní.
Zkontrolujte síťový jmenný prostor obsahující službu. Loopback kontejneru není loopback hostitele a změna nastavení rozhraní hostitele automaticky nevytvoří naslouchající proces v kontejneru.
rp_filter odpovídá na jinou otázku týkající se ověřování zdrojové cesty. Jeho globální vypnutí není obecnou náhradou za pochopení směrování loopback. Stejně tak ip_nonlocal_bind se týká vazby socketů na nelokální adresy, nikoli toho, aby tato cesta DNAT byla správná.
Nakonec musí přesměrovaný protokol odpovídat naslouchajícímu procesu. Odesílání surového HTTP nebo TLS provozu na port SOCKS stále vyžaduje překladač; výjimka ve směrování nemůže dodat chybějící vyjednávání.