О мисье знает толк в извращениях. Защищать фрю от атак из вне фейковой машиной — это что-то новое. ssh по ключам, file2ban, ацесс листы и прочее и прощай лишний гудящий ящик. Я бы еще и роутер выкинул, то-есть приход сразу на фрю от провайдеров, за шлюзом свич с абонентами. Если фря — только шлюз, то систему на флешку монтировать в ридонли, логи на офисную помойку. Уменьшаем количество точек отказа, упрощаем структуру сети для понимания, снижаем энергопотребление. На логи парсер и алярму в мониторинг при аномалиях, смотреть в реальный монитор для отлова атак — это, простите, охренеть.
Ну это я так на коленке набросал, само собой где брать конфиги, как перезапускать правила и менять дефолт — ньюансы. Уберите в статье листинг весь под теги, ну пожалуйста, читать вырвиглазно. Кстати, если нужна ассиметричная балансировка как у Вас, 2 разных канала, можно использовать костыль типа
nat from 10.0.0.0/20 to !<no_nat> -> { ($ext_if1) ($ext_if2) ($ext_if1) } round-robin sticky-address
, то-есть чем жирнее канал, тем чаще он выпадает, может это можно и красивее как-то реализовать, но мне сейчас на ум не приходит.
И все же зачем squid, тем более на слабой машине — это лишняя прослойка. sticky-address — решит вашу проблему с
#Например, клиент-банки или тендерные площадки чувствительны к смене ip-адреса при балансировке.
Еще пинговать шлюз не показатель, иногда бывает такая неприятность когда шлюз живой а вот у провайдера интернет прилег, как правильный вариант делаем пинг 3х разных точек в мире, если хоть до одной пинг есть, канал считаем живым. Еще в переключалку я бы добавил ситуации:
1) Оба канала активны — балансируем всех, кроме исключений, через round-robin sticky-address
2) лег первый канал — поменяли шлюз, отключили балансировщик, вообще всех пустили через второй канал
3) лег второй канал — всех со второго канала перебросили на первый.
4) легли оба канала — проверяем доступность точек в мире через первый канал, если нет меняем шлюз, проверяем доступность через второй канал, если снова нет ждем (на Ваше усмотрение промежуток) уходим в рекурсию.
Вот набросал для Вас простенький скрипт переключения, может пригодится:
#!/bin/sh
PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin
#Ip адреса на интерфейсах разных каналов.
INT1="192.168.88.99"
INT2="192.168.89.99"
#Какой внешний адрес проверяем для определения жив ли канал.
testaddress="8.8.8.8" #Для 3х адресов, надо чуть поменять
#Шлюзы по умолчанию для каждого из каналов
GW1="192.168.88.1"
GW2="192.168.89.1"
#Куда складывать лог.
logfile=/var/log/canalchange.log
fl=`date "+%H:%M:%S %d-%m-%Y"`
tester=0;
itest1=`/sbin/ping -S $INT1 -c 3 $testaddress | grep "64 bytes" | wc -l`;
itest2=`/sbin/ping -S $INT2 -c 3 $testaddress | grep "64 bytes" | wc -l`;
if [ ! -f "/tmp/countGW.tmp" ]
then
echo 3 > /tmp/countGW.tmp
fi
oldtest=`cat /tmp/countGW.tmp`
if (test $itest1 -gt "0")
then
let tester=tester+1
fi
if (test $itest2 -gt "0")
then
let tester=tester+2
fi
#Если последняя проверка такая же как предыдущая, то ничего не делаем
if [ $oldtest = $tester ]; then
exit;
else
if [ $tester = 3 ]; then
cp /etc/pf.conf3 /etc/pf.conf
/sbin/route change default $GW1
echo ${fl}" OK" >> $logfile
echo 3 > /tmp/countGW.tmp
fi
if [ $tester = 2 ]; then
cp /etc/pf.conf2 /etc/pf.conf
/sbin/route change default $GW2
echo ${fl}" CHANAL 1 DOWN" >> $logfile
echo 2 > /tmp/countGW.tmp
fi
if [ $tester = 1 ]; then
cp /etc/pf.conf1 /etc/pf.conf
/sbin/route change default $GW1
echo ${fl}" CHANAL 2 DOWN" >> $logfile
echo 1 > /tmp/countGW.tmp
fi
if [ $tester = 0 ]; then
echo ${fl}" CHANAL 1 DOWN and CHANAL 2 DOWN" >> $logfile
# Если лежат оба то при каждом запуске скрипта меняем дефолтный, ведь неизвестно какой подымется первым
if [ $(/usr/bin/netstat -rn | awk '/default/ {print $2}') == $GW1 ]; then
/sbin/route change default $GW2
else
/sbin/route change default $GW1
fi
fi
/etc/rc.d/pf restart
fi
/etc/pf.conf3 — конфиг для 2х активных каналов
/etc/pf.conf2 — когда только второй канал активен
/etc/pf.conf1 — только первый канал активен.
Почему так, а не только смена гетвея, можно предусмотреть разные параметры шейперов и QoS для разных ситуаций.
Скрипт в крон, раз в минуту, для большинства небольших фирм такой скорости реакции бедет достаточно с головой (лень было придумывать вертушку и демонизацию скрипта).
В серверной среде ориентироваться только на ОС от Майкрософт — терять огромную долю рынка. Где сравнение с конкурентами, графики нагрузочных тестов, одна маркетинговая чушь.
Есть несколько достаточно спорных моментов, например зачем squid? Пожалуйста уберите простыню конфигов под теги. Почему в балансировщиках не используете sticky-address (чем чревато неиспользование рассказать?), например
nat from 10.0.0.0/20 to !<no_nat> -> { ($ext_if1) ($ext_if2) } round-robin sticky-address
из них выкинута. Вместо нее появляются две строки:
pass out route-to ($ext_if $gw1) from $int_if to any
pass out route-to ($ext_if2 $gw2) from $int_if to any
Я бы заменил их на, так оба канала постоянно активны и переключать нужно только GW:
pass out on $ext_if1 route-to ($ext_if2 $ext_gw2) from $ext_if2 to !<no_nat>
pass out on $ext_if2 route-to ($ext_if1 $ext_gw1) from $ext_if1 to !<no_nat>
<no_nat> — адреса, на которые натить не нужно.
Добавим к этому простой скрипт проверки каждого канала и можем оставлять в автоматическом режиме, нам станут не страшны падения одного из линков.
Не совсем понял для чего Вам ALTQ в ядре? Еще могу придраться к выпускающим правилам на интерфейсе. Статья, очень спорная, как туториал для новичков во фре категорически не рекомендую, но за старания плюс.
Простите, а что Вы имеете в виду под: «зачастую предполагают тонкую душевную организацию», если это, то лично мне не хочется работать с такими людьми. Я сам айтишнек, но очень надеюсь, что меня не воспринимают как мудака человека с «тонкой душевной организацией».
Вы таки не поверите, но вернул ноутбук, когда в работе мне не понравился высокочастотный шум его вентиляторов, которых небыло слышно в магазине, а только под нагрузкой. Именно с формулировкой, что не нравится как гудит. Украина, если что.
По ТОП конторам не скажу, сам себя прекрасно аутсорсю, не вижу смысла отдавать конторе половину дохода с заказов в обмен на кофе с печеньками. В контору есть смысл идти начинающему админу за экспой, пару лет и отделяться. Если программисту платят за то, что он работает, то админу за то, что ВСЕ работает, «интима» как такового у админов нет, даже если сидят в одной конторе за соседними столами то занимаются разными фирмами и разными задачами, пересекаясь только на обеде и перекурах.
Как это я уже 3 года аутсорс-админом работаю и из моих коллег знакомых почти все тоже. Про Россию не скажу, а Украина — страна аутсорсеров, зарплаты местного рынка труда хорошо если на еду хватит, почти все IT-специалисты, которых я знаю, работают на США и/или Европу.
Заменить мышку на трекбол и я сразу куплю такую, при текущей конструкции, когда руку над «мышкой» придется держать на весу, чтоб не нажимать клавиши и общий вес вряд-ли будет удобоваримым, мое запястье мне спасибо совсем не скажет.
Мне палка возвращала дважды, правда 1 раз посылка все-же дошла через месяц после возврата, написал продавцу и снова перечислил деньги. Палка часто на стороне покупателя и если есть подтверждение не получения посылки (оборвавшийся треккинг) то рассматривают быстро и возвращают.
Интересный эффект дает масштабирование от видно оба фрукта, до видно то один то второй, с туксом не работает, везде пингвин с рогами. Вот подогнал примерно 1 масштаб для наглядности скрин, слева Опера 12, справа Сафари 6
Прокрастинация мое все. Пытался одно время вести журнал, хватило меня месяца на 2, потом все планы плывут, записывать идеи лень, так запомню думаю, что-то запомню, что-то забуду. Зато за это время научился спихивать огромное количество своих задач на подчиненных, себе оставил контроль результатов и все, самое интересное повышения зп и должности расти стали быстрее, претензий меньше, времени свободного на чтение больше. Как любой прокрастинирующий, люблю читать разную литературу про мотивацию, попалась на глаза книга Бодо Шефера, название сейчас и не вспомню, несколько читал. Так вот вычитал там интересный рецепт, заниматься только деятельностью приносящей доход (в моем случае или удовольствие), посмотрел назад и понял что когда я спихнул всю рутину, планы, ежедневники и т.д. то сам того не зная оставил себе именно такую деятельность. К чему я это, да ну его нафиг не жить с 9 до 18, не нравится работа — меняю, что-то не запоминаю, скорее найму секретаршу (пока жены хватает). Планирование увеличивает производительность временно, зато убивает мотивацию напрочь, а так захотел днем поработал, захотел — ночью, но это подходит для меня, не факт что подойдет всем, в конце концов лень — двигатель прогресса и так ли нужно всем обязательно с ней бороться.
Так хуавей почти полностью передрали цисковский cli, за редким исключением типа show/dis. Не холивара ради, но мне жунос нравится больше по возможностям, все кроме работы с 802.1q, зато у циски самая лучшая, логичная и вменяемая документация ИМХО.
Опять же как считать, бухгалтер обслужил 2х человек, а не 4х. В самом идеальном варианте через свич нельзя передать более 480Гбит трафика и именно эта цифра будет фигурировать в расчете архитектуры сети. Я лично спрашивал у представителей трех вендоров, почему пишут завышенный вдвое показатель. Ответ:«Все так делают, пользователь купит то, где цифра больше», то-есть чистый маркетинг.
Я имел в виду под печеньками, оплаченное обучение, мед. страховка и т.п. А «требуха» бывает первые пару месяцев после открытия почти у всех, а потом печеньки не закупили, кофе кончилось, кофемашина сдохла, боулинг раз в год и за свой счет :)
, то-есть чем жирнее канал, тем чаще он выпадает, может это можно и красивее как-то реализовать, но мне сейчас на ум не приходит.
Еще пинговать шлюз не показатель, иногда бывает такая неприятность когда шлюз живой а вот у провайдера интернет прилег, как правильный вариант делаем пинг 3х разных точек в мире, если хоть до одной пинг есть, канал считаем живым. Еще в переключалку я бы добавил ситуации:
1) Оба канала активны — балансируем всех, кроме исключений, через round-robin sticky-address
2) лег первый канал — поменяли шлюз, отключили балансировщик, вообще всех пустили через второй канал
3) лег второй канал — всех со второго канала перебросили на первый.
4) легли оба канала — проверяем доступность точек в мире через первый канал, если нет меняем шлюз, проверяем доступность через второй канал, если снова нет ждем (на Ваше усмотрение промежуток) уходим в рекурсию.
Вот набросал для Вас простенький скрипт переключения, может пригодится:
/etc/pf.conf3 — конфиг для 2х активных каналов
/etc/pf.conf2 — когда только второй канал активен
/etc/pf.conf1 — только первый канал активен.
Почему так, а не только смена гетвея, можно предусмотреть разные параметры шейперов и QoS для разных ситуаций.
Скрипт в крон, раз в минуту, для большинства небольших фирм такой скорости реакции бедет достаточно с головой (лень было придумывать вертушку и демонизацию скрипта).
Я бы заменил их на, так оба канала постоянно активны и переключать нужно только GW:
<no_nat> — адреса, на которые натить не нужно.
Добавим к этому простой скрипт проверки каждого канала и можем оставлять в автоматическом режиме, нам станут не страшны падения одного из линков.
Не совсем понял для чего Вам ALTQ в ядре? Еще могу придраться к выпускающим правилам на интерфейсе. Статья, очень спорная, как туториал для новичков во фре категорически не рекомендую, но за старания плюс.
мудакачеловека с «тонкой душевной организацией».