ru.unix.bsd

Hello *All* Сабж https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250525 Мейнтейнеp там 100% не активный. Bye, , 25 октябpя 20

Hello, Eugene! Помню ты спрашивал сабж http://pics.rsh.ru/img/IMG_20201017_133533_oknt07cu.jpg В общем такой стоит, вроде сошлись на том что он IEEE 802.11n в эхотаге умеет С наилучшими пожеланиями, Sergey Anohin.

14 окт. 2020, среда, в 14:06 NOVT, Dmitry Dolzenko написал(а): DD> А если на резервном VPS 25 порт пробросить через туннель на основной DD> почтовый сервер какой то затычкой. Может тем же ipfw получится? DD> IP_VPS:25 ---vpn ---- IP_MAILSERV:25 DD> это не решит проблему с валом отбойников? Да, это вариант. Стандартный redirect_port у ipfw nat/natd это делает. Причём лучше всего поднять до VPS два туннеля, один через основной канал, а второй через LTE и запустить на обоих сторонах frr7 с RIPv2 или OSPF (лучше OSPF) с неравными приоритетами, чтобы приходящая на VPS почта роутилась по основному каналу, пока он жив, и чтобы трафик автоматом перероучивался в VPN через LTE, если падает основной канал. OSPF лучше тем, что он, в отличие от RIPv2, умеет определять ситуацию с односторонней проходимостью трафика по трассе, когда анонсы маршрута проходят, а трафик в обратную сторону нет. OSPF в таком случае рвёт отношение соседства до полного восстановления канала, а RIPv2 продолжает роутить пакеты в пустоту. Eugene -- Устав от вечных упований, Устав от радостных пиров

From: Dmitry Dolzenko 28.09.2020 10:42, Eugene Grosbein пишет: > 26 сент. 2020, суббота, в 14:03 NOVT, Dmitry Dolzenko написал(а): > > DD> Арендую VPS, к нему сделаю туннель через tp-link, и резервный mx на этом > DD> VPS с пропихиванием почты в случае чего по vpn тоннелю на основной MX. > > Вообще конкретно с SMTP это не особая проблема, потому что очереди > на доставку есть у всех серверов отправителей, в крайнем случае > почта полежит там, при условии что у тебя зарезервирован DNS. > > А если не зарезервирован DNS, ты хоть делай себе доступный резервный MX, > хоть не делай - почта на него даже не пойдет. > > И, допустим, ты сделал себе резервный MX и он принимает почту и льёт > её через резервный канал поверх LTE. А LTE идёт через операторские соты и > конкурирует за полосу с другими клиентами оператора, которые смотрят > футбол на ютубчике или киношечки. И вполне может случиться так, > что почта с резервного MX тебе станет забивать доступную тебе ширину. > > А кроме того, ты очень быстро столкнёшься с тем фактом, > что спамеры очень любят слать спам через низкоприоритетные > (резервные) MX вместо основного, даже когда основной нормально > доступен, потому что наивно настроенный резервный MX легче > принимает всякий мусор. Hапример, основной MX может сразу отбивать > почту на несуществующие локальные ящики, а резервный MX > может принимать на любые адреса домена, затем при попытке доставки > на основной сервер получит отлуп из-за несуществования имени, > так что будет сгенерирован DSN на скорее всего подставной > адрес отправителя и твой резервный MX отправит спам-письмо > в виде возврата невинной жертве. За такое ты сам быстро попадёшь > в черные списки. > > Это можно пытаться решить с помощью milter-ahead (в случае sendmail) > или ещё каких наворотов, но я бы вообще сильно не парился > созданием резервного MX для LTE, почта спокойно полежит в очередях > серверов отправителей. А вот вторичный внешний DNS завести обязательно. > > DD> Плюс скрипт на основном роутере конторы, который переключает роутинг в > DD> случае проблем на tp-link. > DD> Есть еще нерешенная проблема с вебсервером конторы, который не виден в > DD> случае падения канала. > DD> Первое что приходит на ум - поставить на VPS nginx в режиме reverse > DD> proxy с работой по 2 каналам. В случае падения основного переключение на > DD> резерв. > DD> Или может есть способ лучше? > > Обратный прокси на VPS добавит тебе заметных задержек при обращении > к сайту, а интерактивный HTTP(S) к задержкам чувствителен. > > Да, есть способ лучше - подключить второго оператора фиксированной связи :-) > Это, кстати, кардинально решает проблему с почтой и с DNS: > почта будет приходить по "резервной" записи MX реально на основной > почтовый сервер, и DNS будет зарезервирован так же второй записью NS. > > А сайт можно вообще вынести на внешний хостинг. > Качественное резервирование без затрат скорее утопия. > > Eugene Да, сайт надо на внешний хостинг, ты прав. По поводу второго оператора, тут ничего не выходит, это госучереждение, и там _нельзя второго оператора_ . Поэтому и приходится заморачиваться с LTE. По поводу почты - при падении канала ее критично важно получать и отправлять, поэтому вариант с лежанием в очереди не подходит. А если на резервном VPS 25 порт пробросить через туннель на основной почтовый сервер какой то затычкой. Может тем же ipfw получится? IP_VPS:25 ---vpn ---- IP_MAILSERV:25 это не решит проблему с валом отбойников? /D

06 окт. 2020, вторник, в 14:57 NOVT, Vassily Kiryanov написал(а): VK> Дорогие коллеги, нужно мне на LAN-сетевухе иметь несколько разных IP-адресов, VK> которые будут default router для разных клиентов разные. И нужно различать, на VK> который из этих внутренних адресов был настроен маршрут-по-умолчанию у клиента, VK> чтобы решить, что нужно сделать с пакетом дальше. VK> Hапример, на внутренней сетевухе у меня будут три IP из одной сети: VK> 192.168.1.1 и 192.168.1.10 и 192.168.1.100 и разным группам клиентов по DHCP VK> будет выдаваться один из адресов в качестве маршрутизатора по умолчанию. Hужно VK> пихать пакеты, ну пусть хоть в очереди с разным приоритетом. VK> Такое совершабельно во фряхе стандартными средствами (какими, если да)? VK> А нестандартными (какими, если да)? VK> Спасибо! Первым делом нужно осознаь, что в сетях Ethernet нет IP-адресов вообще. Трафик в сетях Ethernet передаётся не по IP-адресам, а по MAC-адресам, с MAC-адреса отправителя на MAC-адрес получателя. И что в IP-пакете внутри Ethernet-фрейма нет "адреса шлюза", а есть только IP-адрес источника и IP-адрес назначения. Поэтому если ты не разводишь такие группы по отдельным vlan-ам, то различать их ты можешь только по адресу источника, информации о шлюзе в трафике нету. После сегментации сети на vlan-ы следующий самый лучший способ это разграничивать по границам подсетей типа /26, по 64 (по 32 и т.п.) адреса в "подсети", чтобы потом форвардить или транслировать пакеты простыми правилами типа: nat 100 ip from 192.168.064/26 to any out Такой матчинг это одна побитовая операция маскирования и затем одно сравнение 32-битных чисел, быстрее особо некуда. Различать разрозненные группы IP-адресов одной подсети тоже можно при помощи ipfw table, но это более заморочено и менее эффективно. Eugen -- Поэты - страшные люди. У них все святое.

hi, Vassily! 06 Oct 20 14:57, Vassily Kiryanov wrote to All: VK> Дорогие коллеги, нужно мне на LAN-сетевухе иметь несколько разных VK> IP-адресов, которые будут default router для разных клиентов разные. И VK> нужно различать, на который из этих внутренних адресов был настроен VK> маршрут-по-умолчанию у клиента, чтобы решить, что нужно сделать с VK> пакетом дальше. Hапример, на внутренней сетевухе у меня будут три IP VK> из одной сети: 192.168.1.1 и 192.168.1.10 и 192.168.1.100 и разным VK> группам клиентов по DHCP будет выдаваться один из адресов в качестве VK> маршрутизатора по умолчанию. Hужно пихать пакеты, ну пусть хоть в VK> очереди с разным приоритетом. Такое совершабельно во фряхе VK> стандартными средствами (какими, если да)? А нестандартными (какими, VK> если да)? Спасибо! по src не проще ли это делать? или PBR рулить необходимо именно через конфиг dhcp? например, сделай три таблички, натолкай туда клиентские адреса и верти табличками дальше как душе угодно. wbr, Dmitriy.

Hi All! Дорогие коллеги, нужно мне на LAN-сетевухе иметь несколько разных IP-адресов, которые будут default router для разных клиентов разные. И нужно различать, на который из этих внутренних адресов был настроен маршрут-по-умолчанию у клиента, чтобы решить, что нужно сделать с пакетом дальше. Hапример, на внутренней сетевухе у меня будут три IP из одной сети: 192.168.1.1 и 192.168.1.10 и 192.168.1.100 и разным группам клиентов по DHCP будет выдаваться один из адресов в качестве маршрутизатора по умолчанию. Hужно пихать пакеты, ну пусть хоть в очереди с разным приоритетом. Такое совершабельно во фряхе стандартными средствами (какими, если да)? А нестандартными (какими, если да)? Спасибо! Всего хорошего. "За верную и прибыльную дружбу!" (c) Яго. Vassily

Hi, Victor! On Mon, 05 Oct 2020 19:58:20 +0700 Victor Sudakov writes: [...] VS>>> А как в bundle запихать не всю историю, а только с коммита XXX по VS>>> коммит YYY? ZK>> На сколько я понимаю, как и для git fetch при работе с удалённым ZK>> репозитарием, ему нужен ref, поэтому нужно оттежить или отбранчить ZK>> YYY. ZK>> % git tag name-for-remote YYY ZK>> Затем ZK>> кратко: вместо HEAD в примере выше, XXX..name-for-remote (XXX не ZK>> включается). VS> Примерно понятно. Непонятно зачем недостаточно просто двух commit ID. Я когда-то давно смотрел в удалённый протокол, он был завязан на ref'ы. Точных причин не знаю, ибо попросить вызвать git rev-list при некоторой переделке выглядело возможным. Но тонкостей не вспомню сейчас. [...] ZK>> в принципе там в мане пример, где достаточно просто git pull ZK>> /tmp/bundle, когда ref из бандла мержится в текущий бранч. VS> В том примере AFAIR они сперва бандл как удалённый репозиторий VS> прописывают, а я не хотел так. Это не обязательно. Просто иллюстрация бандла как полноценного удалённого, чтобы git pull по-умолчанию работал. Как с любым удалённым, его можно не прописывать, а просто сказать, откуда fetch'ить.

Dear Zhenja, 04 Oct 20 20:28, you wrote to me: VS>>>> Почитал про git bundle (по аналогии с hg bundle), но там VS>>>> какой-то слишком сложный процесс описан, надо на 2-м объявить VS>>>> bundle как remote, на 1-м его как-то хитро создать, VS>>>> синхронизировать... ZK>>> Вроде как без проблем совсем: ZK>>> /tmp/git1 % git log --oneline ZK>>> 016bbf6ffdf5 (HEAD -> master) 2 ZK>>> aff2fdcca797 1 ZK>>> /tmp/git1 % git bundle create /tmp/bundle HEAD ZK>>> Enumerating objects: 6, done. ZK>>> Counting objects: 100% (6/6), done. ZK>>> Compressing objects: 100% (3/3), done. ZK>>> Total 6 (delta 0), reused 0 (delta 0), pack-reused 0 VS>> А как в bundle запихать не всю историю, а только с коммита XXX по VS>> коммит YYY? ZK> На сколько я понимаю, как и для git fetch при работе с удалённым ZK> репозитарием, ему нужен ref, поэтому нужно оттежить или отбранчить ZK> YYY. ZK> % git tag name-for-remote YYY ZK> Затем ZK> кратко: вместо HEAD в примере выше, XXX..name-for-remote (XXX не ZK> включается). Примерно понятно. Непонятно зачем недостаточно просто двух commit ID. VS>> Или лучше bundle делать всегда полный, а он потом при VS>> unbundle/merge сообразит, с какого места надо импортировать VS>> изменения? ZK> вопрос скорости и места. Можно и полный .git копировать и потом просто ZK> fetch/pull из него (fetch/pull также можно сделать из бандла). Вот кстати да, спасибо за идею, самый простой способ скопировать репозиторий полностью. Только что проверил - можно делать из принесенного репозитория pull, не прописывая его как remote и пр., а просто указав путь на fs. На том наверное и остановлюсь. [dd] VS>> О, вот это круто, благодарю. ZK> в принципе там в мане пример, где достаточно просто git pull ZK> /tmp/bundle, когда ref из бандла мержится в текущий бранч. В том примере AFAIR они сперва бандл как удалённый репозиторий прописывают, а я не хотел так. Victor Sudakov, VAS4-RIPE, VAS47-RIPN

03 окт. 2020, суббота, в 14:11 NOVT, Andrey Melnikoff написал(а): AM> 3 ненужных прослойки, зато стандартно. Стандартно это важно. А если тебя волнует количество прослоек, можно сэкономить на L2TP и PPP, оставив только одну инкапсуляцию UDP-Encap в случае с if_ipsec(4), когда IP-пакеты шифруются просто IPSec-ом туннельного режима и заворачиваются в UDP с дополнительными 8 байтами: 4 байта SPI и 4 номера последовательности, итого 36 байт оверхеда на заголовки. В качестве демона IKE/ISAKMB годится strongswan из портов, только что потестировал. Eugene -- Сердце - малочувствительный, мускулистый, грубый и жесткий орган.