Kvifor DNAT til 127.0.0.1 krev særleg varsemd
Forstå route_localnet når du omdirigerer ekstern trafikk til ein loopback-bunden proxykomponent.
Ein teneste lyttar på 127.0.0.1:1080. Ei DNAT-regel sender innkomande trafikk til den adressa, men tilkoplinga feilar likevel. Tenesta kan vera frisk, og NAT-regelen kan stemma: IPv4-loopbackadresser får særskild rutinghandsaming.
Linux sin route_localnet styrer om 127/8-adresser vert handsama som marsadresser under ruting. Standardverdien held på den vanlege loopback-grensa. Eit grensesnittspesifikt unntak kan vera relevant for eit medvite lokalt omdirigeringsdesign.
Det forklarar kvifor ei fungerande regel frå ein annan maskin kan avhenga av ein sysctl du ikkje kopierte. Det rettferdigjer ikkje å slå valet på overalt.
Tryggleiksforehavinga endrar seg med ruta
Loopback-binding vert ofte brukt fordi ein hjelpar ikkje har sjølvstendig klientautentisering. Viss trafikk frå eit anna grensesnitt kan rutast dit, skildrar ikkje bindingsadressa åleine lenger det publikumet som kan nåast. Avgrense inngangskjelder, mål og port i det faktiske regelsettet, òg trafikk som hevdar loopback-kjelde- eller mål-adresser der det er relevant.
Gå gjennom nettverksnamnerommet som inneheld tenesta. Loopbacken til ein container er ikkje verten sin loopback, og endring av ei vertsgrensesnitt-innstilling skapar ikkje automatisk ein lyttar i containeren.
rp_filter svarar på eit anna spørsmål om validering av kjeldevegen. Å slå det av globalt er ikkje ei generell erstatning for å forstå loopback-ruting. På same måte gjeld ip_nonlocal_bind binding av socketar til ikkje-lokale adresser, ikkje å gjera denne DNAT-vegen rett.
Til slutt må den omdirigerte protokollen passa til lyttaren. Å senda rå HTTP- eller TLS-trafikk til ein SOCKS-port krev framleis ein omsetjar; eit rutingunntak kan ikkje levera den manglande forhandlinga.