И снова добрый день, коллеги!
Продолжаю серию статей про NAT на Cisco, т.к. предыдущая статья все нашла некоторое количество положительных отзывов.
В этой статье мы рассмотрим, как и было обещано, inside destination NAT. Кому интересно — велкам под кат.
Прежде чем читать дальше — дисклаймер: коллеги, я понимаю, что не все ровно относятся к Cisco вообще, CLI в частности и цискарям в особенности. Но давайте все же не разводить холиваров и делать обсуждение более конструктивным, а именно обсуждать конкретно эту статью и описываемую технологию. Поскольку блог-то тематический, то и статья в его тематику. И еще просьба, давайте при несхождении мнений не выходить за рамки корректности. :) все, извините за лирическое отступление.
Итак,
На самом деле весьма и весьма экзотический вид NATа, созданный специально для балансировки нагрузки между серверами, работающими по TCP протоколу. В реальной жизни встречается не чаще солнечного затмения :)
Давайте углубимся.
1. Итак, данная трансляция срабатывает ТОЛЬКО когда соединение инициируется (простите за такое слово) со стороны outside интерфейса в сторону inside интерфейса и для ответного трафика. Но если трафик инициируется со стороны inside — трансляция не произойдет.
2. Такой NAT работает только для протокола TCP.
Зачем нам такая радость?
Допустим, у нас есть десяток web-серверов, имеющих адреса с 10.0.0.1 по 10.0.0.10. На всех серверах крутится один и тот же сайт (вернее это могут быть просто frontend-сервера) и порт у них тоже один, для простоты — 80 (HTTP).
Клиенты снаружи достукиваются до нашего «размазанного» сайта по адресу 11.1.1.1:80.
И мы хотим балансировать нагрузку между ними по принципу RR (Round Robin), т.е. чтобы каждый следующий клиент, обращающийся снаружи к нашему маршрутизатору по глобальному адресу, обращался к следующему серверу из этой десятки (по кругу).
Вот тут-то там и поможет этот хитрый NAT.
Как это работает?
1. Прямая трансляция. Вопреки логичным и привычным ожиданиям, основанным на логике работы inside source NAT, для этого типа прямая трансляция та, которая создается при обращении со стороны outside в сторону inside. При появлении TCP (и только его, повторюсь) трафика на outside интерфейсе, трафик сначала проверяется на соответствие inside destination NAT. Если он соответствует — адрес назначения меняется на следующий в пуле и трансляция заносится в список трансляций. После этого пакет с уже измененным адресом назначения подвергается маршрутизации.
___
UPD: не-TCP трафик будет направлен на первый адрес в пуле. За комментарий спасибо Ilya_Drey
2. Обратная трансляция. Опять же — многое наоборот. Обратная трансляция происходит в направлении inside-to-outside. И здесь уже сначала отрабатывает маршрутизация, если она бросает трафик с inside на outside и есть соответствующая запись в таблице трансляций — пакет растранслируется.
Замечания.
1. В отличие от static inside source NAT и static inside source PAT, маршрутизатор не отвечает на ARP-запросы по поводу глобального адреса, если конечно этот адрес не назначен его интерфейсу. Поэтому возможно потребуется добавить его к интерфейсу как secondary.
2. Как и в случае inside source NAT, трафик роутера тоже подвергается трансляции, даже если нет ни одного inside интерфейса.
3. Следствие из п. 2: если нет inside-интерфейсов, транслируется только трафик самого роутера.
давайте теперь посмотрим, как это конфигурируется.
1. Итак, сначала создаем пул. Адреса в пуле — адреса наших серверов.
я специльно выделил слово rotary — для этого типа NAT пул должен быть ротационным (т.е. мы как раз указываем, что адреса будут браться один за другим
по кругу, иначе по достижению конца пула следующий пакет будет дропнут).
2. Создаем access-list, который будет выделять трафик, подлежащий трансляции. Специально сделал его расширенным:
Т.е. транслировать мы будем трафик, направленный к нашему глобальному адресу и даже конкретному порту (TCP!).
3. Создаем трансляцию, остались мелочи:
4. И маркируем интерфейсы (там где сервера — inside, где внешний мир — outside)
И теперь, можем пронаблюдать картину обращений к нашему серверу:
видим, что один и тот же порт глобального адреса (а именно 11.1.1.1:80) странслировался в разные адреса.
___
UPD: естественно, трафик балансируется per-session, что необходимо для корректной работы TCP. За комментарий спасибо Ilya_Drey
Замечания.
1. Нельзя перенаправлять какой-то порт глобального адреса на другие порты серверов (например 80й на 8080й), порты должны совпадать. Если очень нужно — можно прицепить loopback, транслировать на него обычным inside source static PAT с заменой порта, оттуда уже на сервера с помощью inside destination NAT. И совсем нельзя (ощущение, что с помощью еще и nat enable — можно) такое делать, если на серверах один и тот же протокол отвечает по разным портам (где-то по 80, а где-то по 8080 например). Но если кому-то до зарезу нужно — пишите, попробую сообразить.
2. Если настроены две трансляции — одна inside destination, как выше, а другая — inside source dynamic PAT для тех же серверов, т.е. для трафика, идущего от них наружу, но не попадающего в обратную трансляцию (например для доступа серверов к репозиториям):
Видим, что они перекрываются, т.е. ответ от серверов с 80го порта должен подвергнуться обратной трансляции inside destination и прямой inside source (кстати, обе они сработают только после маршрутизации). В этом случае, обратная трансляция выигрывает и все будет работать как положено.
3. Нельзя сделать статический inside destination NAT. Для этого нужно использовать static inside source NAT.
В заключение. Подводя итоги, хочу еще разок отметить следующее:
1. Inside destination NAT — технология трансляции адресов с целью балансировки и работает она только для протокола TCP.
2. Хотя интерфейсы маркируются так же, как и в случае inside source NAT, направление прямой и обратной трансляции противоположное.
3. Приоритеты NAT (inside-to-outside и outside-to-inside) такие же, как и в случае inside source NAT.
4. Если трафик инициируется в направлении inside-to-outside, то трансляции он не подвергается (если только Вы там еще не наворотили и inside source NAT).
Я решил не перегружать статью, так что outside source NAT мы рассмотрим в следующей статье.
По традиции — я открыт для пожеланий и предложений. Пока в списке видел policy-NAT.
Продолжаю серию статей про NAT на Cisco, т.к. предыдущая статья все нашла некоторое количество положительных отзывов.
В этой статье мы рассмотрим, как и было обещано, inside destination NAT. Кому интересно — велкам под кат.
Прежде чем читать дальше — дисклаймер: коллеги, я понимаю, что не все ровно относятся к Cisco вообще, CLI в частности и цискарям в особенности. Но давайте все же не разводить холиваров и делать обсуждение более конструктивным, а именно обсуждать конкретно эту статью и описываемую технологию. Поскольку блог-то тематический, то и статья в его тематику. И еще просьба, давайте при несхождении мнений не выходить за рамки корректности. :) все, извините за лирическое отступление.
Итак,
inside destination NAT
На самом деле весьма и весьма экзотический вид NATа, созданный специально для балансировки нагрузки между серверами, работающими по TCP протоколу. В реальной жизни встречается не чаще солнечного затмения :)
Давайте углубимся.
1. Итак, данная трансляция срабатывает ТОЛЬКО когда соединение инициируется (простите за такое слово) со стороны outside интерфейса в сторону inside интерфейса и для ответного трафика. Но если трафик инициируется со стороны inside — трансляция не произойдет.
2. Такой NAT работает только для протокола TCP.
Зачем нам такая радость?
Допустим, у нас есть десяток web-серверов, имеющих адреса с 10.0.0.1 по 10.0.0.10. На всех серверах крутится один и тот же сайт (вернее это могут быть просто frontend-сервера) и порт у них тоже один, для простоты — 80 (HTTP).
Клиенты снаружи достукиваются до нашего «размазанного» сайта по адресу 11.1.1.1:80.
И мы хотим балансировать нагрузку между ними по принципу RR (Round Robin), т.е. чтобы каждый следующий клиент, обращающийся снаружи к нашему маршрутизатору по глобальному адресу, обращался к следующему серверу из этой десятки (по кругу).
Вот тут-то там и поможет этот хитрый NAT.
Как это работает?
1. Прямая трансляция. Вопреки логичным и привычным ожиданиям, основанным на логике работы inside source NAT, для этого типа прямая трансляция та, которая создается при обращении со стороны outside в сторону inside. При появлении TCP (и только его, повторюсь) трафика на outside интерфейсе, трафик сначала проверяется на соответствие inside destination NAT. Если он соответствует — адрес назначения меняется на следующий в пуле и трансляция заносится в список трансляций. После этого пакет с уже измененным адресом назначения подвергается маршрутизации.
___
UPD: не-TCP трафик будет направлен на первый адрес в пуле. За комментарий спасибо Ilya_Drey
2. Обратная трансляция. Опять же — многое наоборот. Обратная трансляция происходит в направлении inside-to-outside. И здесь уже сначала отрабатывает маршрутизация, если она бросает трафик с inside на outside и есть соответствующая запись в таблице трансляций — пакет растранслируется.
Замечания.
1. В отличие от static inside source NAT и static inside source PAT, маршрутизатор не отвечает на ARP-запросы по поводу глобального адреса, если конечно этот адрес не назначен его интерфейсу. Поэтому возможно потребуется добавить его к интерфейсу как secondary.
2. Как и в случае inside source NAT, трафик роутера тоже подвергается трансляции, даже если нет ни одного inside интерфейса.
3. Следствие из п. 2: если нет inside-интерфейсов, транслируется только трафик самого роутера.
давайте теперь посмотрим, как это конфигурируется.
1. Итак, сначала создаем пул. Адреса в пуле — адреса наших серверов.
(config)# ip nat pool NAME_OF_POOL 10.0.0.1 10.0.0.10 netmask 255.255.255.0 type rotaryя специльно выделил слово rotary — для этого типа NAT пул должен быть ротационным (т.е. мы как раз указываем, что адреса будут браться один за другим
по кругу, иначе по достижению конца пула следующий пакет будет дропнут).
2. Создаем access-list, который будет выделять трафик, подлежащий трансляции. Специально сделал его расширенным:
(config)# access-list 100 permit tcp any host 11.1.1.1 eq wwwТ.е. транслировать мы будем трафик, направленный к нашему глобальному адресу и даже конкретному порту (TCP!).
3. Создаем трансляцию, остались мелочи:
(config)# ip nat inside destination list 100 pool NAME_OF_POOL4. И маркируем интерфейсы (там где сервера — inside, где внешний мир — outside)
(config)# int fa0/0
(config-if)# ip nat inside
(config-if)# int fa0/1
(config-if)# ip nat outsideИ теперь, можем пронаблюдать картину обращений к нашему серверу:
R3#sh ip nat translations
Pro Inside global Inside local Outside local Outside global
tcp 11.1.1.1:80 10.0.0.1:80 11.1.1.251:18747 11.1.1.251:18747
tcp 11.1.1.1:80 10.0.0.2:80 11.1.1.250:52943 11.1.1.250:52943видим, что один и тот же порт глобального адреса (а именно 11.1.1.1:80) странслировался в разные адреса.
___
UPD: естественно, трафик балансируется per-session, что необходимо для корректной работы TCP. За комментарий спасибо Ilya_Drey
Замечания.
1. Нельзя перенаправлять какой-то порт глобального адреса на другие порты серверов (например 80й на 8080й), порты должны совпадать. Если очень нужно — можно прицепить loopback, транслировать на него обычным inside source static PAT с заменой порта, оттуда уже на сервера с помощью inside destination NAT. И совсем нельзя (ощущение, что с помощью еще и nat enable — можно) такое делать, если на серверах один и тот же протокол отвечает по разным портам (где-то по 80, а где-то по 8080 например). Но если кому-то до зарезу нужно — пишите, попробую сообразить.
2. Если настроены две трансляции — одна inside destination, как выше, а другая — inside source dynamic PAT для тех же серверов, т.е. для трафика, идущего от них наружу, но не попадающего в обратную трансляцию (например для доступа серверов к репозиториям):
ip nat inside source list 110 interface FastEthernet0/1 overload
access-list 110 permit ip 10.0.0.0 0.0.0.255 anyВидим, что они перекрываются, т.е. ответ от серверов с 80го порта должен подвергнуться обратной трансляции inside destination и прямой inside source (кстати, обе они сработают только после маршрутизации). В этом случае, обратная трансляция выигрывает и все будет работать как положено.
3. Нельзя сделать статический inside destination NAT. Для этого нужно использовать static inside source NAT.
В заключение. Подводя итоги, хочу еще разок отметить следующее:
1. Inside destination NAT — технология трансляции адресов с целью балансировки и работает она только для протокола TCP.
2. Хотя интерфейсы маркируются так же, как и в случае inside source NAT, направление прямой и обратной трансляции противоположное.
3. Приоритеты NAT (inside-to-outside и outside-to-inside) такие же, как и в случае inside source NAT.
4. Если трафик инициируется в направлении inside-to-outside, то трансляции он не подвергается (если только Вы там еще не наворотили и inside source NAT).
Я решил не перегружать статью, так что outside source NAT мы рассмотрим в следующей статье.
По традиции — я открыт для пожеланий и предложений. Пока в списке видел policy-NAT.
