Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 30
Тема нужная и полезная, и обфускация текста замечетельная :)
Обозначте модельку роутера?
Ах, какой слог!
забавно. я подобную штуку делал только на 3х маршрутизаторах: два смотрят к двум разным isp, третий во внутреннюю сеть. и на роутерах смотрящих в isp делал одновременно src и dst nat, так чтоб к серверу приходящие пакеты од первого isp имели один src, а от второго isp другой src, и именно так и разделялись каналы.
а на линупсе с ip tables одновременный src/dst nat для такого случая можно на одной коробке сделать… люблю линупс :)
а на линупсе с ip tables одновременный src/dst nat для такого случая можно на одной коробке сделать… люблю линупс :)
Можно. Как раз готовил статью. Но раз тут такое написали про циску — то грех не опубликовать ;)
А всего-то можно было серверу два внешних адреса сразу повесить ;).
я бы сделал (и делал) через nat enable + pbr…
Смотри первый способ? Про NAT NVI там упомянуто…
там как раз упомянуто, что не получилось. А у меня вроде ничего… Но я не в критику, просто мне кажется изящнее, чем нагружать маршрутизатор, бросая на loopback пакеты (ведь фактически это означает двойную обработку)
Илья, когда то на сером, мне уже давали линк на вашу статью про NAT NVI, возможно это были вы. =) Но:
Как видите, поведение абсолютно идентичное тому, с которым я столкнулся при использовании NAT. Просто так бы не писал. Мне было бы очень любопытно увидеть конфиг и версию IOS на котором это работает иначе — с удовольствием добавлю ещё один способ решения с ссылкой на Вас.
R1#sh ip nat nvi translations
Pro Source global Source local Destin local Destin global
------------ OUTPUT OMMITTED ------------
tcp 192.168.133.1:16947 ZZ.ZZ.ZZ.ZZ:16947 172.16.12.4:80 192.168.1.31:80
tcp 192.168.133.1:19109 ZZ.ZZ.ZZ.ZZ:19109 172.16.13.4:80 192.168.1.31:80
--- 192.168.133.1 ZZ.ZZ.ZZ.ZZ --- ---
Как видите, поведение абсолютно идентичное тому, с которым я столкнулся при использовании NAT. Просто так бы не писал. Мне было бы очень любопытно увидеть конфиг и версию IOS на котором это работает иначе — с удовольствием добавлю ещё один способ решения с ссылкой на Вас.
хм. воспроизведу как время появится, интересно сравнить.
сел ковырять свое решение :) вспомнил, какая хитрость была применена. дешево и сер
дито: я повесил на сервер второй ip (серый). и смотрите что получилось
:) без заморочек и хитростей. а NVI тут не поможет, согласен
дито: я повесил на сервер второй ip (серый). и смотрите что получилось
ip nat inside source static 192.168.1.31 172.16.12.4 extendable
ip nat inside source static 192.168.1.32 172.16.13.4 extendable:) без заморочек и хитростей. а NVI тут не поможет, согласен
И у Вас это работало?
Не могли бы Вы описать чуть подробнее. Сейчас бьюсь над решением задачи, описанной вами в заголовке топика. Но никак не выходит у меня каменный цветок.
Одновременная доступность без BGP, я так понял, недостижима. Но PAT с разных IP думаю реален. Но как-то не получается у меня победить 15.0.1
Не могли бы Вы описать чуть подробнее. Сейчас бьюсь над решением задачи, описанной вами в заголовке топика. Но никак не выходит у меня каменный цветок.
Одновременная доступность без BGP, я так понял, недостижима. Но PAT с разных IP думаю реален. Но как-то не получается у меня победить 15.0.1
ответил сам себе чуть ниже…
Спасибо, поржал. Я, конечно, не о сути, а о слоге. Видимо, вместе с последней сожженной деревней сгорел мешок чего-то веселящего-)
Феерично. Подача материала оценена мною на 6 баллов по двух-бальной шкале.
Сейчас сам ломаю голову над подобной задачей, но есть два но:
НО №1 — DMVPN Ph1
НО №2 — Не считаю себя гуру по «кошкам».
Отсюда 2 вопроса — это можно адаптировать для VPN или не получится, и ломать голову и железо не стоит? Меня терзает сомнение, которое растет из природы VPN, что туннель не поднимится после удара в горе-бубен на стороне одного из провов. Или я все-же не прав. Железо 12 x 2811 (12.4 AdvSec)
Сейчас сам ломаю голову над подобной задачей, но есть два но:
НО №1 — DMVPN Ph1
НО №2 — Не считаю себя гуру по «кошкам».
Отсюда 2 вопроса — это можно адаптировать для VPN или не получится, и ломать голову и железо не стоит? Меня терзает сомнение, которое растет из природы VPN, что туннель не поднимится после удара в горе-бубен на стороне одного из провов. Или я все-же не прав. Железо 12 x 2811 (12.4 AdvSec)
скажите, а зачем цизко? Ж))) любая современная ОС для сервера умеет посылать обратно пакеты в тот аплинк с которого они пришли. например в линуксе это реализуется тремя коммандами iptools'ами. в free/open bdsm есть fib'ы и routing-domains соответственно, у solaris'а есть crossbow…
вы еще взяли cisco _маршрутизатор_ для того что бы делать nat, — решение годное лишь для очень не больших нагрузок. при возрастании до сколько бы то ни было приличного количества сессий оно будет загибаться. нужно было брать какой из фаерволов: pix, asa. но я щитаю, дешевле и удобнее nat'а чем на писюках нет нигде в лоуэнде.
а так вы конешно большой молодец: не только решили проблему но и статью написали. к сожалению, не имею возможности кинуть вам в карму плюсик.
вы еще взяли cisco _маршрутизатор_ для того что бы делать nat, — решение годное лишь для очень не больших нагрузок. при возрастании до сколько бы то ни было приличного количества сессий оно будет загибаться. нужно было брать какой из фаерволов: pix, asa. но я щитаю, дешевле и удобнее nat'а чем на писюках нет нигде в лоуэнде.
а так вы конешно большой молодец: не только решили проблему но и статью написали. к сожалению, не имею возможности кинуть вам в карму плюсик.
Ну, как то не странно, но бывают места где наличие Сisco идёт по дефолту, а наличие линуксов (подставить нужное) в качестве маршрутизатора, а тем более установка их ради одного сервиса выглядит довольно нелепо, ну или просто невозможна. Поэтому делалось на том что делалось. =) Насчёт нагрузок всё верно, они не большие — около полусотни единовременных трансляций, но 2811 с 2 гигами оперы на борту выдержит и много больше.
А так, если придерживаться такой точки зрения, то ваш вопрос: —
А так, если придерживаться такой точки зрения, то ваш вопрос: —
скажите, а зачем цизко? Ж))) можно разместить жирным шрифтом на странице блога Cisco, а постинг тут запретить за ненадобностью. :-)
Существует более комфортное решение данной задачи, которое, в частности внедрили у нас в офисе на маршрутизаторе с ценой до $100.
Исходные данные:
два канала к ISP, при чем разной природы: один скоростной ethernet со статикой, второй — резервный pppoe линк через adsl модем с плавающим ip.
Цель: обеспечить схему бесперебойной работы терминального сервера наружу.
Средство: покупка VPN PPTP туннеля с постоянным честным ip (за совсем недорого), настройка на офисном маршрутизаторе поднятие PPTP туннеля и получение этого самого IP.
Готово.
Пользователь на самом деле подключался на ip предоставленный pptp туннелем, а этот самый pptp туннель поднимался на любом из живых каналов. Чистый profit.
Исходные данные:
два канала к ISP, при чем разной природы: один скоростной ethernet со статикой, второй — резервный pppoe линк через adsl модем с плавающим ip.
Цель: обеспечить схему бесперебойной работы терминального сервера наружу.
Средство: покупка VPN PPTP туннеля с постоянным честным ip (за совсем недорого), настройка на офисном маршрутизаторе поднятие PPTP туннеля и получение этого самого IP.
Готово.
Пользователь на самом деле подключался на ip предоставленный pptp туннелем, а этот самый pptp туннель поднимался на любом из живых каналов. Чистый profit.
Только вот одна проблема — по такому VPN кроме сайтов и интернета ничего гонять низзя. Нет, физически то можно, но вот с точки зрения ИБ такое решение очень сомнительно. Можно и свой туннель поднять внутри, но производительность такоего решения, опять же…
Если задача — дать доступ к сайту или публичному FTP — то может и сойдет, а вот объединять сети или терминал вывешивать — я бы не рискнул. Куда рациональнее поднять свой VPN-сервис с балансировкой, а пользователи пусть к нему цепляются и работают уже.
Как говорят — «Лучшк перебдеть, чем не добдеть»
Если задача — дать доступ к сайту или публичному FTP — то может и сойдет, а вот объединять сети или терминал вывешивать — я бы не рискнул. Куда рациональнее поднять свой VPN-сервис с балансировкой, а пользователи пусть к нему цепляются и работают уже.
Как говорят — «Лучшк перебдеть, чем не добдеть»
Вариант с reflexive ACL рассматривали?
Не знаю как остальным, но вид подачи материала слишком часто отвлекает… может хотя бы разграничивать лирическую и техническую части, раз уж так хочется «излить душу»? )
Господа, а каким образом будут передаваться на сервер src_ip? В логах Apache, например, есть необходимость отслеживать все ip адреса, с которых заходили клиенты. Приложение, которое крутится на Apache, на основе src_ip должно отображать определенный контент. Как тут быть?
без слёз не взглянешь. простейшая задача, которая на junuper решается в два счета (да что там на juniper, даже на mikrotik!) на cisco превращается в ламбаду.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Cisco Router + 2ISP + NAT. Доступность сервиса через 2ух провайдеров