Конфиг роутера Juniper будем сохранять через scp, причём подключаться будем при помощи публичного ключа, а не пароля.
На сервере заводим пользователя juniper.
На роутере из-под пользователя root генерируем ключи:

>start shell
% su -
% ssh-keygen -t rsa -b 4096
cat /root/.ssh/id_rsa.pub

Обращаю внимание, что именно из-под пользователя root, а не из-под обычного пользователя, под которым вы вошли на роутер.

Полученный публичный ключ сохраняем в одну строку на сервере в папке пользователя juniper (в файле /home/juniper/.ssh/authorized_keys):

ssh-rsa AAAA...[очень много символов]... user@router

Теперь собственно автоматическое копирование конфига при коммите:

set system archival configuration transfer-on-commit
set system archival configuration archive-sites "scp://juniper@10.1.1.11/home/juniper"

Конфиги копируются в домашнюю папку юзера juniper /home/juniper:
router_20180303_072352_juniper.conf.gz
router_20180303_072625_juniper.conf.gz
…

Если на роутере несколько IP-адресов и вы хотите, чтобы по-умолчанию трафик исходил от адреса интерфейса lo0.0, то нужно сделать вот такие настройки:

set interfaces lo0 unit 0 family inet address 10.1.1.2/32 primary
set system default-address-selection

Указанные настройки влияют не только на копирование по scp, так что после коммита, не закрывая текущую сессию, проверьте доступность роутера открыв новую сессию )

Дополнение.

Если про комите выдаётся ошибка:

[edit security]               
  'ssh-known-hosts'           
    warning: statement has no contents; ignored

То нужно ввести ключ хоста, с которого мы подключаемся, в секции security — security: можно вручную, можно запросить с сервера, а можно импортировать его из уже созданного системой роутера. Лично мне последний вариант показался наиболее логичным:

set ssh-known-hosts load-key-file /var/home/user/.ssh/known_hosts

Сегодня поисковик Google аннонсировал стабильные релизы браузера Google Chrome для Mac и Linux. Это первый стабильные релизы для «хрома».



Так что же новенького?

Читать дальше →

В интернет-магазине BEST KG поступлениe материнских плат Biostar,ASRock,ASUS,Intel!

Biostar H61MLC,LGA1155,intel H61,2DDR3 DPC10600,1PCI-E16X,2PCI-E1X,int VGA by CPU,Sound6CH,LAN,4SATA,mATX,8USB

EliteGroup H61H2-M2,LGA1155,Intel H61,1333Mhz,2DDR3 DPC8500,1PCI-E16X,2PCI-E1X,Sound6CH,GB LAN,4SATA,mATX,8USB,DVI

ASRock H61M-VS, LGA1155,intel H61, 2DDR3 PC10600,1PCI-E16X,1PCI-E1X,int VGA,Sound5.1CH,LAN,4SATA,mATX,10USB

ASUS P7H55,LGA1156,intel H55,4DDR3 PC17600(oc),1PCI-E16X,3PCI-E1X,3PCI,Sound8CH,GB LAN,6SATA & 1ATA,ATX,12USB

MB Intel BLKDH55TC,LGA1156,intel H55,4DDR3 PC10600,1PCI-E16X,2PCI-E1X,1PCI,8CH,LAN,SATA,uATX

MB ASROCK G41M-S3 iG41,S775, FSB1333, DDRIII1333, PCIEx16, GMAX4500, 4xSATA2,Lan, 2xPCI,1xPCIE,mATX

MB Biostar G41D3C iG41, FSB1333, DDR3, PCI-Ex16, GMAX4500, SATA2,Lan, mATX
LGA1156 ELITEGROUP IC55H-A V1.0A

LGA1156 ELITEGROUP P55H-A2 V1.0 <i P55 (Sound 5.1,GLAN/6SATA-2,RAID 0/1/5/10,UDMA None),DMI 2.5GT/s,4DDR3 2100 OC/1600/1333/1066/800 up to 16GB,1PCI-E x16,3PCI-E x1,3PCI,11USB2.0,1COM,ATX 24+4pin

Сравните цены, они Вас приятно удивят! Товар в наличии.

www.best.kg

Салют! Наткнулась вот на местное блог-сообщество.
Прочитав пару блогов стало интересно… люди живут, дышат… страдать изволят…

Я тоже хочу

Буду рада интересным постам, людям и идеям!!!

Сразу поделюсь событиями в своей жизни.
Вчера сходили в местный бар… а там такоооое!!!
Воть:

Как вы знаете единственным регистраторов доменов в зоне КГ является АзияИнфо. Изменить эту ситуацию коренным образом пытался Улан Мелисбек, будучи руководителем КыргызПатента. Не получилось — помешала очередная революция. Я не питаю к Мелисбеку каких-либо симпатий и не питаю какой-то особенной неприязни к АзияИнфо, но в данном случае я жалею, что Мелисбеку не удалось довести дело до конца.
У меня давно есть ощущение, что некие сотрудники АзияИнфо крутят своим же регламентом как хотят и поступают так, как им выгоднее, или, я бы даже сказал, что эти недобропорядочные сотрудники злоупотребляют своим служебным положением ради выгоды своей или своих знакомых.
Есть мой личный опыт. Один раз просроченный домен мне не отдали, хотя по регламенту должны были и поступали так с другими доменами. Потом один домен, который я зарегистрировал через domain.kg мне не отдали под тем предлогом, что домен уже кому-то продали, но забыли указать это в базе данных, хотя я проверял его наличие в ДНС-е (я достаточно в этом разбираюсь), запись же в БД потом появилась задним числом. А ещё были случаи с другими людьми, но их я не привожу, т.к. у меня нет достаточно информации про них.
Вот появился ещё один пример. Довольно давно, наверно уже больше полугода назад, обратил внимание на домен OK.KG — он был в базе, но в неактивном состоянии с датой регистрации месячной давности. Т.е. кто-то зарегистрировал домен, но не оплатил его и в таком состоянии домен висит месяц, а потом, по идее, должен быть удалён, чтобы другой мог его зарегистрировать. Мне всё это показалось странным и я решил понаблюдать за ним. Я периодически смотрел состояние домена и было нетрудно заметить, что имеет место быть простая махинация — регистрируем домен, не платим за него, месяц он наш, а потом регистрируем его снова и так пока не найдётся какой-нибудь покупатель на домен и можно будет заработать денег не вложив ни копейки.
Ну ладно, думаю, попытаюсь, ради интереса, перехватить домен — зайду когда подойдёт срок окончания домена и зарегистрирую его, может мне удастся зайти раньше махинатора. Однако дело оказалось сложнее, чем я думал — домен упорно не хотел удаляться из базы данных, а через некоторое время он был просто с новой датой регистрации и окончания срока. Сначала я подумал, что домены удаляется не когда должен, а когда попало и мне просто не повезло. Тогда я решил это дело автоматизировать — написал скрипт, который через определённые промежутки времени, проверял бы состояние домена. И вот что получается, приведу последний по времени пример. Дата окончания срока домена была 18 сентября 03:26, но запись была на месте вплоть до 19 сентября 14:36. При этом, за промежуток в 6 минут между проверками моим скриптом домен чудесным образом успели удалить из базы данных АзияИнфо, а махинатор успел зайти и зарегистрировать его снова и это при том, что домен был удалён не в указанный срок, а когда попало. Вот логи моего скрипта (жирным шрифтом выделено время проверки):
Mon Sep 19 14:30:00 KGT 2011
Record created: Fri Aug 19 03:26:04 2011
Record last updated on Fri Aug 19 03:26:04 2011
Record expires on Sun Sep 18 03:26:04 2011

Mon Sep 19 14:36:00 KGT 2011
Record created: Mon Sep 19 03:25:04 2011
Record last updated on Mon Sep 19 03:25:04 2011
Record expires on Wed Oct 19 03:25:04 2011

Это всё приводит к мысли, что кто-то из ответственных сотрудников АзияИнфо нечист на руку и просто пользуется своим положением, чтобы держать этот домен при себе. А уж дата регистрации, указанная задним числом — типа домен зарегистрировали ещё в 3:25, совсем уж явно указывает на вмешательство сотрудника АзияИнфо.

Linux иштетүү системасынын версиясын кароо дистрибутивге (Red Hat Linux, Ubuntu, Debian, CentOS жана башка) карай өзгөрүшү мүмкүн, бирок, көбүнчө ылдыйда берилген командалар колдонулат.

Linux иштетүү системасынын дистрибутивинин атын жана версиясын кароо үчүн:

$ lsb_release -a

LSB Version: :core-4.0-amd64:core-4.0-ia32:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-ia32:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-ia32:printing-4.0-noarch
Distributor ID: RedHatEnterpriseServer
Description: Red Hat Enterprise Linux Server release 5.11 (Tikanga)
Release: 5.11
Codename: Tikanga

Дистрибутивдин атын жана версиясын бул ыкма менен дагы караса болот:

$ cat /etc/issue

Red Hat Enterprise Linux Server release 5.11 (Tikanga)

Linux иштетүү системасынын өзөгүнүн версиясын кароо үчүн:

$ uname -a

Linux srvname 2.6.18-398.el5 #1 SMP Tue Aug 12 06:26:17 EDT 2014 x86_64 x86_64 x86_64 GNU/Linux

Бул жерде Linux иштетүү системасынын «бит»тиги тууралуу дагы маалымат бар: x86_64 — 64-биттик иштетүү системасына таандык экенин билдирет.

Приветствую всех. Хотелось бы Вас пригласить на игровой форум Кыргызстана — CYB.NET.KG. На форуме вы можете найти единомышленников, и обсудить любимую игру. А также на форуме вы найдете, свежи новости, файлы (мувики, демки, конфиги и.т.п), более того, Вы можете оставить заявку на скачивание игровых файлов (патчей, локализаций, мувиков и.т.п) до 200 МБ — выбрав нужный раздел в ФайлоАрхиве, и в теме прочитать подробные условия.

Команда CYB.NET.KG — с радостью выслушает ваши предложения и замечания по форуму в теме: Предложения по форуму.. Также сейчас на форуме проходит Набор Модераторов — вакансии ограниченны, торопитесь.

По любым вопросом и предложениям от игроков или команд. Можно писать либо на форуме мне в ЛС либо в icq: 5-995-870

Не совсем понятен смысл коллективности блога, вроде как к нему могут подключаться другие авторы.

Удача — то, что нужно всем из нас. Простые методы фэн шуй позволяют не только рационально уладить собственный быт, а так же войти в поток счастья и благополучия. Как стоит оборудовать квартиру соответствуя фэн шую, советуют восточные знатоки.
Читать дальше →

Довольно распространённая ситуация — на моёй рабочей станции есть два интерфейса и два айпишника, скажем из подсети А и подсети Б. При обращении клиента с хоста из сети Б к моему айпишнику из подсети А ответ к нему уходит через другой интерфейс с моего айпишника из подсети Б, т.к. он из той же подсети, что и адрес клиента. Мне надо сделать, чтобы эти ответы уходили с того же адреса на который пришли.

Тут нужен policy-routing — маршрутизация на основе определённых правил. Логика получается такая: ответы на запросы из подсети Б к моему адресу из подсети А отправлять с адреса из подсети А (т.е. на шлюз подсети А).

Маркируем соединения из сети Б к нашему адресу из сети А при помощи iptables и таблицу mangle (используется для изменения пакетов):
iptables -t mangle -I INPUT -i eth0 -s 10.1.100.0/24 -d 10.2.96.3 -j CONNMARK --set-mark 1
А на выходе копируем маркировку соединения в маркировку пакетов, насколько я понимаю, это означает, что мы маркируем пакеты промаркированных ранее соединений:
iptables -t mangle -I OUTPUT -s 10.2.96.3 -d 10.1.100.0/24 -j CONNMARK --restore-mark
Вероятно, в этом правиле можно обойтись и без указания адресов источника и адресата, но мне кажется так будет правильнее, более точно чтоли )

В таблицу маршрутизации 111 добавляем маршрут для сети Б, но на шлюз из подсети А:
ip route add to 10.1.100.0/24 via 10.2.96.1 dev eth0 table 111
И, наконец, добавляем правило для перенаправления пакетов с нашей маркировкой в отдельную таблицу маршрутизации:
ip rule add fwmark 1 lookup 111

Для удобства можно назначить название для таблицы в файле /etc/iproute2/rt_tables, которое можно будет использовать вместо номера.

Так же нужно проверить не включена ли проверка обратного пути (reverse path checking):
sysctl net.ipv4.conf.eth0.rp_filter
Если включена, то система будет проверять пакеты на соответствие источника интерфейсу, с которого пакет получен. Например, если пакет пришёл с адреса, который виден через другой интерфейс (а не тот, с которого пакет пришёл), то значит этот пакет надо отбросить.

Если всё заработало как надо, то сохраняем правила iptables в файл "/etc/sysconfig/iptables", а правила для маршрутизации в файл "/etc/sysconfig/network-scripts/route-eth0".

Далее несколько вспомогательных команд, которые могут пригодиться.

Посмотреть определённую таблицу маршрутизации:
ip route show table 111
Удалить маршрут из указанной таблицы
ip route del table 111 to 10.1.100.0/24
Посмотреть правила маршрутизации:
ip rule show
Удалить правило маршрутизации:
ip rule del fwmark 1

Как посмотреть правила iptables писать не буду )