Varför DNAT till 127.0.0.1 kräver särskild försiktighet
Förstå route_localnet när du omdirigerar extern trafik till en loopback-bunden proxykomponent.
En tjänst lyssnar på 127.0.0.1:1080. En DNAT-regel skickar inkommande trafik till den adressen, men anslutningen misslyckas ändå. Tjänsten kan vara frisk och NAT-regeln kan stämma: IPv4-loopbackadresser får särskild routingbehandling.
Linux route_localnet styr om 127/8-adresser behandlas som marsadresser vid routning. Standardvärdet bevarar den vanliga loopback-gränsen. Ett gränssnittsspecifikt undantag kan vara relevant för en medveten lokal omdirigeringsdesign.
Det förklarar varför en fungerande regel från en annan maskin kan bero på en sysctl som du inte kopierade. Det rättfärdigar inte att slå på alternativet överallt.
Säkerhetsantagandet ändras med rutten
Loopback-bindning används ofta eftersom en hjälpare saknar oberoende klientautentisering. Om trafik från ett annat gränssnitt kan routas dit beskriver bindningsadressen ensam inte längre den nåbara publiken. Begränsa ingångskällor, destination och port i den faktiska regeluppsättningen, inklusive trafik som hävdar loopback-käll- eller måladdresser där det är relevant.
Granska nätverksnamnrymden som innehåller tjänsten. En containers loopback är inte värdens loopback, och att ändra en värdgränssnittsinställning skapar inte automatiskt en lyssnare i containern.
rp_filter svarar på en annan fråga om validering av källvägen. Att stänga av det globalt är ingen allmän ersättning för att förstå loopback-routning. På samma sätt gäller ip_nonlocal_bind bindning av sockets till icke-lokala adresser, inte att göra den här DNAT-vägen korrekt.
Slutligen måste det omdirigerade protokollet passa lyssnaren. Att skicka rå HTTP- eller TLS-trafik till en SOCKS-port kräver fortfarande en översättare; ett routingundantag kan inte leverera den saknade förhandlingen.