Оскільки це було піднято як канонічне питання щодо шпильки NAT , я подумав, що він, мабуть, повинен відповісти, що є більш загальним, ніж прийнятий на даний момент, який (хоча і відмінно) стосується конкретно FreeBSD.
Це питання стосується сервісів, що надаються серверами в мережах IPv4, адресованих RFC1918, які надаються зовнішнім користувачам шляхом введення NAT (DNAT) на шлюзі. Потім внутрішні користувачі намагаються отримати доступ до цих служб за допомогою зовнішньої адреси. Їх пакет виходить з клієнта на пристрій шлюзу, який переписує адресу призначення та негайно вводить його назад у внутрішню мережу. Саме цей різкий зворотний поворот пакета робить на шлюзі і породжує назву шпильки NAT , за аналогією з поворотом шпильки .
Проблема виникає, коли пристрій шлюзу переписує адресу призначення, але не адресу джерела. Потім сервер отримує пакет із внутрішньою адресою призначення (власною) та внутрішньою адресою джерела (клієнтською); він знає, що може відповісти безпосередньо на таку адресу, тому робить це. Оскільки ця відповідь є прямою, вона не проходить через шлюз, що, отже, ніколи не отримує шансу врівноважити ефект вхідного пункту призначення на початковий пакет, переписавши адресу джерела зворотного пакету.
Таким чином, клієнт відправляє пакет на зовнішню IP-адресу, але отримує відповідь з внутрішньої IP-адреси. Поняття не має, що два пакети є частиною однієї розмови, тому жодної розмови не відбувається.
Рішення полягає в тому, що для пакетів, які потребують такого NAT, і які дістаються до шлюзу з внутрішньої мережі , також виконувати джерело NAT (SNAT) у вхідному пакеті, зазвичай, переписавши адресу джерела на адресу шлюзу. Потім сервер вважає, що клієнт є самим шлюзом, і відповідає безпосередньо на нього. Це, в свою чергу, дає шлюзу можливість збалансувати ефекти і DNAT, і SNAT на вхідний пакет, переписавши обидва джерела та адреси призначення на зворотний пакет.
Клієнт думає, що він спілкується із зовнішнім сервером. Сервер думає, що він спілкується з пристроєм шлюзу. Всі вечірки раді. На даний момент може бути корисна діаграма:
Деякі пристрої споживчих шлюзів достатньо яскраві для того, щоб розпізнати ті пакети, для яких необхідний другий крок NAT, і вони, ймовірно, працюватимуть нестандартно у сценарії NAT-стрижка. Інших немає, і так не буде, і навряд чи їх можна змусити працювати. Обговорення про те, які саме пристрої для споживачів, що не стосується серверних помилок.
Правильні мережеві пристрої, як правило, можна сказати, що вони працюють, але - оскільки вони не займаються вгадуванням своїх адміністраторів, - їм це потрібно сказати. Linux використовує iptablesдля DNAT таким чином:
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 192.168.3.11
що дозволить простий DNAT для порту HTTP, для внутрішнього сервера на 192.168.3.11. Але для включення шпильки NAT також потрібно таке правило, як:
iptables -t nat -A POSTROUTING -d 192.168.3.11 -p tcp --dport 80 -j MASQUERADE
Зауважте, що для правильної роботи такі правила повинні знаходитись у потрібному місці у відповідних ланцюжках, і залежно від налаштувань filterланцюга можуть знадобитися додаткові правила, щоб дозволити потоку NATED трафік. Всі такі дискусії виходять за рамки цієї відповіді.
Але, як говорили інші, належна підтримка шпильки NAT - це не найкращий спосіб вирішити цю проблему. Найкращим є DNS з розділеним горизонтом , де ваша організація подає різні відповіді на оригінальний пошук залежно від того, де знаходиться запитуючий клієнт, або за допомогою різних фізичних серверів для внутрішніх проти зовнішніх користувачів, або за допомогою налаштування сервера DNS, щоб відповідати по-різному відповідно до адреса запитуючого клієнта.
