Hvorfor DNAT til 127.0.0.1 krever særlig varsomhet
Forstå route_localnet når du omdirigerer ekstern trafikk til en loopback-bundet proxy-komponent.
En tjeneste lytter på 127.0.0.1:1080. En DNAT-regel sender innkommende trafikk til den adressen, men tilkoblingen feiler likevel. Tjenesten kan være sunn, og NAT-regelen kan stemme: IPv4-loopbackadresser får spesiell rutingbehandling.
Linux' route_localnet styrer om 127/8-adresser behandles som marsadresser under ruting. Standardverdien bevarer den vanlige loopback-grensen. Et grensesnittspesifikt unntak kan være relevant for et bevisst lokalt omdirigeringsdesign.
Det forklarer hvorfor en fungerende regel fra en annen maskin kan avhenge av en sysctl du ikke kopierte. Det rettferdiggjør ikke å slå valget på overalt.
Sikkerhetsforutsetningen endres med ruten
Loopback-binding brukes ofte fordi en hjelper ikke har uavhengig klientautentisering. Hvis trafikk fra et annet grensesnitt kan rutes dit, beskriver ikke bindingsadressen alene lenger det oppnåelige publikummet. Begrens inngangskilder, destinasjon og port i det faktiske regelsettet, inkludert trafikk som hevder loopback-kilde- eller -destinasjonsadresser der det er relevant.
Gå gjennom nettverksnavnerommet som inneholder tjenesten. En containers loopback er ikke vertens loopback, og endring av en vertsgrensesnittinnstilling oppretter ikke automatisk en lytter i containeren.
rp_filter svarer på et annet spørsmål om validering av kildeveien. Å slå det av globalt er ikke en generell erstatning for å forstå loopback-ruting. På samme måte gjelder ip_nonlocal_bind binding av sockets til ikke-lokale adresser, ikke å gjøre denne DNAT-veien riktig.
Til slutt må den omdirigerte protokollen passe til lytteren. Å sende rå HTTP- eller TLS-trafikk til en SOCKS-port krever fortsatt en oversetter; et rutingunntak kan ikke levere den manglende forhandlingen.