Чому DNAT на 127.0.0.1 потребує особливої обережності
Розберіться з route_localnet, коли перенаправляєте зовнішній трафік на проксі-компонент, прив'язаний до loopback.
Служба слухає 127.0.0.1:1080. Правило DNAT спрямовує вхідний трафік на цю адресу, але з'єднання не встановлюється. Служба може бути справною, а правило NAT — збігатися: адреси loopback IPv4 отримують особливу обробку під час маршрутизації.
Параметр route_localnet у Linux визначає, чи вважаються адреси 127/8 марсіанськими під час маршрутизації. Значення за замовчуванням зберігає звичайну межу loopback. Виняток для конкретного інтерфейсу може бути доречним для навмисного проєкту локального перенаправлення.
Це пояснює, чому робоче правило з іншої машини може залежати від sysctl, який ви не скопіювали. Але це не виправдовує вмикання параметра всюди.
Припущення щодо безпеки змінюється разом із маршрутом
Прив'язку до loopback часто використовують тому, що допоміжний компонент не має самостійної автентифікації клієнтів. Якщо трафік з іншого інтерфейсу можна спрямувати туди, сам лише адрес прив'язки вже не описує доступну аудиторію. Обмежте джерела входу, призначення та порт у фактичному наборі правил, зокрема трафік, що заявляє loopback-адреси джерела чи призначення, де це доречно.
Перегляньте мережевий простір імен, у якому є служба. Loopback контейнера — не loopback хоста, і зміна налаштування інтерфейсу хоста не створює автоматично слухача в контейнері.
rp_filter відповідає на інше питання — про перевірку шляху джерела. Його глобальне вимкнення не є загальною заміною розуміння маршрутизації loopback. Так само ip_nonlocal_bind стосується прив'язки сокетів до нелокальних адрес, а не виправності цього шляху DNAT.
Нарешті, перенаправлений протокол має відповідати слухачеві. Надсилання необробленого HTTP або TLS на порт SOCKS усе ще потребує транслятора; виняток у маршрутизації не може забезпечити відсутнє узгодження.