Hvorfor DNAT til 127.0.0.1 kræver særlig omhu
Forstå route_localnet, når ekstern trafik omdirigeres til en loopback-bundet proxy-komponent.
En tjeneste lytter på 127.0.0.1:1080. En DNAT-regel sender indgående trafik til den adresse, men forbindelsen fejler. Tjenesten kan være sund, og NAT-reglen kan matche: IPv4-loopbackadresser får særlig routingbehandling.
Linux' route_localnet styrer, om 127/8-adresser behandles som marsadresser under routing. Standardværdien bevarer den sædvanlige loopback-grænse. En grænsefladespecifik undtagelse kan være relevant for et bevidst lokalt omdirigeringsdesign.
Det forklarer, hvorfor en fungerende regel fra en anden maskine kan afhænge af en sysctl, du ikke kopierede. Det retfærdiggør ikke at slå valgmuligheden til overalt.
Sikkerhedsantagelsen ændrer sig med ruten
En loopback-binding bruges ofte, fordi en hjælper ikke har selvstændig klientgodkendelse. Hvis trafik fra en anden grænseflade kan routes dertil, beskriver bindingsadressen alene ikke længere det opnåelige publikum. Begræns indgangskilder, destination og port i det faktiske regelsæt, inklusive trafik, der hævder loopback-kilde- eller -destinationsadresser, hvor det er relevant.
Gennemgå det netværksnavnerum, der indeholder tjenesten. En containers loopback er ikke værtens loopback, og ændring af en værtgrænsefladeindstilling opretter ikke automatisk en lytter i containeren.
rp_filter besvarer et andet spørgsmål om validering af kildevejen. At slå det fra globalt er ikke en generel erstatning for at forstå loopback-routing. Ligeledes handler ip_nonlocal_bind om at binde sockets til ikke-lokale adresser, ikke om at gøre denne DNAT-vej korrekt.
Endelig skal den omdirigerede protokol passe til lytteren. At sende rå HTTP- eller TLS-trafik til en SOCKS-port kræver stadig en oversætter; en routingundtagelse kan ikke levere den manglende forhandling.