Как стать автором
Обновить
4
0
Владимир @spacewalk

Пользователь

Отправить сообщение
Я не изобретал, а сказал, что немного подпилил существующее решение. В частности добавил авторизацию на сервер по ключам, отдельного пользователя (чтобы не логиниться под рутом, обычно отключаю эту возможность в ssh) и хождение через socks-прокси из-под Windows
)) поправил ошибку, спасибо за замечание

А как Вы считаете правильным написать?

А как Вы считаете правильным написать?

так он консольный? т.е. надо логиниться непосредственно на сервер?
она снята, само собой. может изза большого колва роутов отваливается встроенный в микротик опенвпн-клиент?
после добавления всех маршрутов через push, где клиентом выступает mikrotik 951, падает основное соединение почему-то, пока не отключишь впн и не перезагрузишь роутер. он не может проглотить столько маршрутов?
Задача Network 1 — организовать сетевую доступность между виртуальными машинами и dom0. Network 0 наверное можно было бы обойтись, если назначить alias интерфейсу xenbr0 с адресом приватной сети 172.16.1.1/24.

Но без использования приватной сети мне решения не видится
помоему вы путаете. хетнцер дает мне 8 адресов, /29. я могу их использовать как мне удобно. могу организовать шлюз .65, «клиенты» 66-71. тогда у меня будет бродкаст 72, и данная рекомендация
>>https://tools.ietf.org/html/rfc2644
будет по отношению к этому шлюзу
>> дропать пакеты с src 46.4.205.64 и .72 для сети 46.4.205.64/29. понятие бродкаст адреса лежит в рамках одного бродкаст домена, а не всего интернета. завтра мне захочется поделить мою /27 на две /28 и у меня станет уже два бродкаста. И мне рекомендуют (https://tools.ietf.org/html/rfc2644) закрыть хождение пакетов от бродкаста через мой шлюз, потому что если извне через шлюз придет пакет с dest_ip бродкаста моей подсети, на него ответят все узлы этой подсети

представленная сеть не имеет шлюза, не имеет бродкаст-доменов в полном их понимании, там маршрутизируются /32 адреса и на крайний адрес ответит только он и никто больше, потому что пакет придет не через шлюз в бродкаст домен, он придет конкретно к узлу с адресом .72 или .64

потому что это статический роут на всю подсеть /29 через интерфейс сети network 1, а этот интерфейс имеет адрес 172.16.1.1
> А в RFC написано дропать пакеты с src 46.4.205.64 для сети 46.4.205.64/29
Можно ссылочку?
Понятия адреса сети и бродкаст адреса это исключительно понятия вашей сети. Для интернета эти адреса маршрутизируются одинаково. Если бы я использовал на клиентах в настройках сети 46.4.205.64/29, то для них существовал бы адрес сети .64 и броадкаст .72. А у меня /32. Для кого .72 является бродкастом?
по уставу) дело в том, что адреса прописаны с маской /32, это своего рода point-to-point
В wiki как раз советуется путь через назначения одного из адресов шлюзом + 2 неиспользуемые.



От этого я и пытался уйти
К счастью не сталкивался с такой ситуацией) поэтому не в курсе
это решение обходит данную проблему
в интернете я встречал много мануалов, когда во второй сети самому xen'у назначается адрес из выделенной /29 подсети, и он является шлюзом. в этом случае теряется 3 адреса — адрес на xen'е + 2 (адрес подсети и бродкаст)
В нашем случае провайдер отдавал 486 ошибочно постоянно, после того как начал проводить ремонтные работы. Это было выявлено на 100%, и уточнено у него. Поэтому и возникла такая необходимость.
В остальных случаях согласен, Ваше решение подходит лучше
Я писал про наш пример, когда сам абонент отдает 486 — нет необходимости к нему ломиться с другой линии, поэтому звонок не переходит на другой транк. И иной случай, когда провайдер вместо 503 отдает 486 — тогда необходимо в существующей логике просто подменить код.
В Вашем случае у Вас настроено иначе, и наш пример не работает
1

Информация

В рейтинге
Не участвует
Откуда
Одесса, Одесская обл., Украина
Дата рождения
Зарегистрирован
Активность