Elrik12 пишет:можно как нибудь это кодом показать??? если можно чтоб хоть наглядно видеть как это делается
В плане маршрутизации надо разбираться с iproute2. Там можно много чего попонастраивать, например нагрузку (исходящий трафик) побалансировать между провайдерами по разным правилам. Гугли запрос "балансировка нагрузки в iproute2" и ищи статью, доступную для понимания. Например, на OpenNet'е. Информации много. Это для исходящего трафика.
Далее, если появляется задача удаленного доступа (из Инета) к хостам внутренней сети, то вот достаточно неплохая статья на эту тему: http://sys.net.ru/docs/tri-provajdera-i … utri-seti/
Там всё очень доходчиво разжёвано для случая если организуется доступ из внешнего мира. Это первое. Второе - то о чем молчат подобные статьи, но на чем можно очень хорошо наплясаться - при организации поинтерфейсных таблиц маршрутизации там только указывается дефолтный гейт. А что если в сети, обслуживаемой данным интерфейсом есть еще хосты? Передавать на них пакеты через этот дефолтный роутер? А его производительности хватит? Не ляжет? Так вот, чтобы обслужить такую сеть, в которую подвешен интерфейс, надо в соответствующую интерфейсную таблицу марширутизации добавить правило обслуживания этой сети. Примерно такой записью:
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.6
Здесь обслуживается в ARP сеть 192.168.0.0/24, доступная на интерфейсе eth0, который имеет адрес 192.168.0.6. И пакеты пойдут хостам этой сети не через роутер, а напрямую.
И еще - внимательно почитай статьи в Инете о перенаправлении портов (особенно 22-го) и применения правила recent в iptables на предмет противостояния попыткам подбора паролей и DoS атакам. Статистика здесь примерно такая - на адресе в DNS не прописанном (то есть найденном ботами случайно) если ничего в iptables не предпринимать - попыток зайти на 22й порт больше сотни. Если применить recent и поставить таймаут минуть на 5, то не больше десятка. А если перенести порт куда=нибудь наверх - вообще ни одного.
