De ce DNAT către 127.0.0.1 necesită grijă specială
Înțelegeți route_localnet când redirecționați trafic extern către o componentă proxy legată de loopback.
Un serviciu ascultă pe 127.0.0.1:1080. O regulă DNAT direcționează traficul de intrare către acea adresă, însă conexiunea eșuează. Serviciul poate fi sănătos, iar regula NAT se poate potrivi: adresele de loopback IPv4 primesc un tratament special de rutare.
route_localnet din Linux controlează dacă adresele 127/8 sunt tratate ca adrese marțiene în timpul rutării. Valoarea implicită păstrează limita obișnuită a loopback-ului. O excepție specifică unei interfețe poate fi relevantă pentru un proiect deliberat de redirecționare locală.
Aceasta explică de ce o regulă funcțională de pe altă mașină poate depinde de un sysctl pe care nu l-ați copiat. Însă nu justifică activarea opțiunii peste tot.
Ipoteza de securitate se schimbă odată cu ruta
Legarea la loopback este folosită adesea pentru că un auxiliar nu are autentificare independentă a clienților. Dacă traficul provenit de pe altă interfață poate fi rutat acolo, adresa de legare singură nu mai descrie publicul accesibil. Restrângeți sursele de intrare, destinația și portul în setul real de reguli, inclusiv traficul care pretinde adrese de sursă sau destinație loopback acolo unde este relevant.
Examinați spațiul de nume de rețea care conține serviciul. Loopback-ul unui container nu este cel al gazdei, iar schimbarea unei setări de interfață a gazdei nu creează automat un ascultător în container.
rp_filter răspunde unei alte întrebări despre validarea căii sursei. Dezactivarea lui global nu este un substitut general pentru înțelegerea rutării loopback. La fel, ip_nonlocal_bind privește legarea socket-urilor la adrese ne-locale, nu corectitudinea acestei căi DNAT.
În final, protocolul redirecționat trebuie să se potrivească cu ascultătorul. Trimiterea de trafic HTTP sau TLS brut către un port SOCKS necesită în continuare un traducător; o excepție de rutare nu poate furniza negocierea lipsă.