Різниця між DNAT та REDIRECT у IPTABLES


14

Гаразд, це може бути тому, що я щільний або, можливо, просто не знаходжу правильного джерела, але я не можу зрозуміти, чому одна з цих установок IPTABLES була б кращою за іншу.

Ось моя настройка:

У мене є ящик, який служить прозорим проксі-сервером і роутером або сортуванням. На ньому є два інтерфейси, ETH0 та ETH1, та наступна схема адрес:

ETH0 = DHCP ETH1 = 192.168.5.1/24, що обслуговує DHCP для мережі 192.168.5.0/24 клієнтам, що стоять за нею в локальній мережі

У мене встановлений privoxy і слухаю на порту 8080 як прозорий проксі. Що я досягаю цим налаштуванням, - це можливість перекинути це поле у ​​існуючу мережу з мінімальною конфігурацією та приєднати клієнтів до проксі.

Ось мій оригінальний файл IPTABLES

*nat
-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j REDIRECT --to-port 8080
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
*filter
COMMIT

Ця конфігурація працює нормально, і трафік без проблем тече назад і назад. Я отримую IP-адресу вихідних клієнтів у журналах privoxy, і життя хороше.

Моя плутанина виникає, коли я починаю дивитися на конфігурації інших людей і бачу, що вони використовують DNAT замість ПОНИЖЕНОГО, і я намагаюся зрозуміти реальну користь одного над іншим. Ось приклад конфігурації:

*nat
-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j DNAT --to 192.168.5.1:8080
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
*filter
COMMIT

Знову ж таки, ця конфігурація працює і дає мені все, що мені потрібно з точки зору ведення журналу ...

Що є правильним чи, можливо, БІЛЬШЕ правильним, ніж інше?

Дякуємо, що знайшли час для читання цього…

Відповіді:


14

REDIRECTзмінює IP-адресу призначення для надсилання на сам апарат. Іншими словами, локально згенеровані пакети відображаються на адресу 127.0.0.1. Це для переадресації локальних пакетів. Якщо ви хочете лише перенаправляти трафік між службами на локальній машині, це буде хорошим вибором.

DNATє фактичним перекладом мережевих адрес . Якщо ви хочете, щоб пакети, призначені за межами локальної системи, змінили призначення, це кращий вибір обох, оскільки REDIRECTце не вийде.


Гаразд, тому якщо у мене є клієнт, який сидить за проксі, скажімо, на 192.168.5.234, і я хочу "обробити" його HTTP-запити через проксі на 192.168.5.1, ви пропонуєте мені я повинен DNAT вихідний порт 80 трафіку до 192.168 .5.1: 8080 на проксі. Я можу це купити, але ЧОМУ ???? Це щось пов’язане з тим, як обробляється трафік, коли він залишає ETH0 проксі-сервера на виході через шлюз за замовчуванням до Інтернету? Мені потрібно пощипати це, інакше моя голова вибухне
QWade

2
DNAT змінює адресу, коли пакет проходить через брандмауер, так що він надходить на бажаний хост, а на звороті, схоже, що він надходить з брандмауера. DNAT майже ніколи не застосовується до вихідного трафіку, яким керується правило MASQUERADE. Якщо privproxy був на іншому хості, тоді DNAT було б доречним, за відповідним винятком для цього хоста.
BillThor

Білл, дякую. Саме там мій мозок рептилій збирався, але чи завжди це приємно мати перевірку. Отже, якщо я надішлю пакет, призначений для google.com, з 192.168.5.234, і його за замовчуванням gw встановлено як 192.168.5.1 (eth1 на проксі), я повинен "ВІДМОВИТИ" цей пакет до порту 8080 на проксі і дозволити privoxy робити решта. Причина цього полягає в тому, що privoxy живе на 192.168.5.1, а не на іншому хості. Я курю щось, чого не повинен?
QWade

9

REDIRECTчи змінює IP-адресу призначення для надсилання до машини, як відповів Warner @. Але я б сказав, що відповідь не є абсолютно правильною або трохи оманливою.

REDIRECTне лише для переадресації локальних пакетів. Дійсно, DNATв якій цільова IP-адреса, яку слід використовувати, неявна, 127.0.0.1, якщо це місцевий пакет або IP-адреса машинного інтерфейсу в іншому випадку, 192.168.5.1 у випадку ОП.

Тож у цьому питанні, незалежно від того, яке кінцеве призначення, пакети повинні спочатку дістатися до проксі, тому REDIRECTвін ідеально підходить.

Оскільки REDIRECTвам не потрібно вказувати IP-адресу, вона просто прийме правильну, вона має деякі переваги перед DNAT:

  • Якщо IP-адреса машини з будь-якої причини зміниться, вам не потрібно змінювати свої правила, і, зокрема DNAT, не працюватимуть для керованих DHCP інтерфейсів.

  • Ви можете писати і підтримувати однакові правила для декількох систем (наприклад, кілька екземплярів проксі), не зберігаючи різні незначні версії через певні IP-адреси.


якось подобається сніт / маскарад.
Jichao

@Hod, я чую, що REDIRECT - це особливий випадок DNAT, але я використовую REDIRECT, і TOR знає фактичне призначення пакету, тому я укладаю daddr і dport структури iphdr та tcphdr неушкодженими, і пакет щойно повернувся до REDIRECT місця призначення ядро. DNAT фактично модифікує структури. Я помиляюся?
гніт
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.