Чому більшість організацій не використовують NAT «всередині-всередині» NAT або подібні рішення, щоб дозволити NAT шпильки?

Внутрішня всередині NAT ака петля NAT вирішує проблеми зі шпильками NAT під час доступу до веб-сервера на зовнішньому інтерфейсі ASA або подібного пристрою з комп'ютерів у внутрішньому інтерфейсі. Це заважає адміністраторам DNS не підтримувати дублюючу внутрішню зону DNS, яка має відповідні адреси RFC1918 для своїх серверів, які NATET для загальнодоступних адрес. Я не мережевий інженер, тому, можливо, мені щось не вистачає, але це, здається, не налаштовує на налаштування та реалізацію. Асиметрична маршрутизація може бути проблемою, але її легко пом’якшити.

На мій досвід, мережеві адміністратори / інженери віддають перевагу, що люди з системи просто запускають спліт-dns, а не конфігурують свої брандмауери для належної обробки шпильок NAT. Чому це?

Є кілька причин, чому я цього не роблю:

• Навіщо надто напружувати маршрутизатори та брандмауер DMZ, якщо цього не потрібно? Більшість наших внутрішніх сервісів знаходяться не в DMZ, а в загальній корпоративній зоні, а в ДМЗ - проміжні послуги для епізодичного віддаленого доступу. Виконання нат всередині-всередині додає більше навантаження на DMZ, що в нашому випадку було б суттєвим.
• Якщо ви не зробите DNAT + SNAT, ви отримаєте асиметричну маршрутизацію, що, як відомо, складно отримати правильно. Таким чином, ви SNAT і втрачаєте інформацію про вихідну IP-адресу. Однак, корисно пов'язувати вихідні IP-адреси з людьми для усунення несправностей. Або періодично з метою глупоти у випадках глупоти. "Привіт, цей IP робить щось химерке на неавторизованому сервісі X" "О, давайте подивимось у журнал сервера Imap, хто це".

Очевидно, на це не може бути однозначної відповіді , але я можу подумати з кількох причин:

1. Елегантність: NAT не дуже елегантний для початку, але необхідність з обмеженим адресним простором IPv4. Якщо я зможу уникнути NAT, я зроблю. З IPv6 проблема усувається в будь-якому випадку.
2. Складність: особливо у випадку, коли у вас немає лише одного "основного" маршрутизатора, який створює всі ваші межі безпеки, конфігурації фільтрів можуть стати досить складними. Або це, або вам доведеться поширювати та підтримувати правила NAT майже на всіх ваших пристроях маршрутизаторів.
3. Довідка: де адміністратори брандмауера не відрізняються від решти команди адміністратора сервера, до них може бути важко дістатися. Для того, щоб зміни не затягувались через відставання адміністратора брандмауера (або відпустки), обирається можливість зберігати відповідальність в одній команді.
4. Переносимість та поширена практика: Використання поглядів DNS - це "лише те, що всі знають, робиться" для вирішення цієї проблеми. Не кожен прикордонний маршрутизатор прямо підтримує циклічний NAT, менше людей, ймовірно, знає, як правильно його налаштувати у вашому конкретному середовищі. Під час вирішення проблем із мережею, екіпажу необхідно знати про конфігурацію шпильки NAT та всі її наслідки - навіть коли вони переслідують, мабуть, незв'язану проблему.

Відмова - це відповідь полум'я.

Поширена причина, на яку я думаю, уникають таких рішень, - це ірраціональний страх / ненависть до NAT з боку мережевих інженерів . Якщо ви хочете побачити кілька прикладів обговорення цього питання, перегляньте такі:

• http://packetpushers.net/show-86-connect-to-the-ipv6-internet-for-free-using-tunnelbroker-net/
• http://networkingnerd.net/2012/04/02/ipv6-nat-and-the-sme-a-response/ (блог Тома, здається, продовжує залучати досить бурхливу дискусію щодо NAT / IPv6)
• http://libertysys.com.au/blog/nat-is-evil-but-not-bad (мій блог)

З того, що я можу сказати, багато цього страху випливає з поганої реалізації NAT Cisco (так що в цьому сенсі це може не бути ірраціональним), але на мій погляд, "класичний" інженер з мереж настільки добре навчається в "NAT є поганий "світогляд, що він чи вона не бачать очевидних прикладів, таких як цей, де це має ідеальний сенс і фактично спрощує рішення.

Там ви йдете - знижуйте зміст свого серця! :-)

Я здогадуюсь:

1. Спліт DNS легше зрозуміти.
2. NAT Hairpin використовує ресурси на маршрутизаторі, тоді як спліт-dns цього не робить.
3. Маршрутизатори можуть мати обмеження пропускної здатності, яких ви не отримуєте через налаштування розділеного dns.
4. Split-dns завжди буде ефективнішим, оскільки ви уникаєте кроків маршрутизації / NAT.

З плюсу для шпильки NAT,

• Після налаштування це просто працює.
• Немає проблем з кешами DNS для ноутбуків, переміщених між робочою мережею та загальнодоступним Інтернетом.
• DNS для сервера керується лише в одному місці.

Для невеликої мережі з низькими вимогами до трафіку до внутрішнього сервера я б пішов із шпилькою NAT. Для більшої мережі, що має багато підключень до сервера, і де важлива пропускна здатність та затримка, перейдіть з розділеними dns.

З моєї точки зору, це трохи змінилося між переходом Cisco Pix до ASA. Втратив aliasкоманду. І взагалі, доступ до зовнішньої адреси з внутрішнього інтерфейсу на брандмауері Cisco вимагає певної хитрості. Див. Як я можу отримати доступ до свого внутрішнього сервера на зовнішній IP-адресі?

Нам не завжди потрібно підтримувати повторювану внутрішню зону DNS. Cisco ASA може перенаправляти запити DNS для зовнішніх адрес на внутрішні адреси, якщо вони налаштовані на оператор NAT. Але я вважаю за краще зберігати внутрішню зону для загальнодоступної зони DNS, щоб мати цю деталізацію та мати можливість керувати цим в одному місці, а не крокувати до брандмауера.

Як правило, є лише кілька серверів, які можуть зажадати цього в середовищі (пошта, Інтернет, кілька публічних служб), тому це не було величезною проблемою.

Я можу придумати кілька причин:

1. Багато організацій розділили DNS вже через те, що вони не бажають публікувати всю свою внутрішню інформацію про DNS у світі, тому це не великі додаткові зусилля для обробки кількох серверів, які також піддаються відкритому IP-адресу.
2. Оскільки організація та її мережа зростають, вони часто відокремлюють системи, що обслуговують внутрішніх людей, від серверів, що обслуговують зовнішні, тому маршрутизація до зовнішніх для внутрішнього використання може бути набагато довшим мережевим шляхом.
3. Чим менше модифікацій, які вносять посередницькі пристрої в пакети, тим краще це стосується затримки, часу відгуку, завантаження пристрою та усунення несправностей.
4. (дуже незначно, правда, є) Існують протоколи, що NAT все-таки зламається, якщо пристрій NATing не вийде за межі заголовків пакету та змінить дані в ньому за допомогою нових IP-адрес. Навіть якщо це лише випадок інституційної пам’яті, це все ще є поважною причиною, щоб люди уникали цього, особливо якщо вони мають справу з протоколом, щодо якого вони не впевнені на 100%.

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

Я б встановив NAT-цикл, підключив до перемикача DMZ і надсилав би пакети із підробленими внутрішніми адресами джерела. Перевірте журнал сервера, щоб перевірити, чи були вони отримані. Тоді я б зайшов до кав’ярні і подивився, чи блокує мій провайдер підроблені адреси. Якби я виявив, що NAT-роутер не перевіряє джерело інтерфейсу, я, ймовірно, не використовував би NAT-цикл, навіть якщо мій провайдер перевіряє.