Я не изобретал, а сказал, что немного подпилил существующее решение. В частности добавил авторизацию на сервер по ключам, отдельного пользователя (чтобы не логиниться под рутом, обычно отключаю эту возможность в 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
Понятия адреса сети и бродкаст адреса это исключительно понятия вашей сети. Для интернета эти адреса маршрутизируются одинаково. Если бы я использовал на клиентах в настройках сети 46.4.205.64/29, то для них существовал бы адрес сети .64 и броадкаст .72. А у меня /32. Для кого .72 является бродкастом?
в интернете я встречал много мануалов, когда во второй сети самому xen'у назначается адрес из выделенной /29 подсети, и он является шлюзом. в этом случае теряется 3 адреса — адрес на xen'е + 2 (адрес подсети и бродкаст)
В нашем случае провайдер отдавал 486 ошибочно постоянно, после того как начал проводить ремонтные работы. Это было выявлено на 100%, и уточнено у него. Поэтому и возникла такая необходимость.
В остальных случаях согласен, Ваше решение подходит лучше
Я писал про наш пример, когда сам абонент отдает 486 — нет необходимости к нему ломиться с другой линии, поэтому звонок не переходит на другой транк. И иной случай, когда провайдер вместо 503 отдает 486 — тогда необходимо в существующей логике просто подменить код.
В Вашем случае у Вас настроено иначе, и наш пример не работает
А как Вы считаете правильным написать?
А как Вы считаете правильным написать?
Спасибо!
Но без использования приватной сети мне решения не видится
>>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
Можно ссылочку?
От этого я и пытался уйти
В остальных случаях согласен, Ваше решение подходит лучше
В Вашем случае у Вас настроено иначе, и наш пример не работает