На мой взгляд, вначале надо пообщаться с саппортом бегуна, потом писать топики по результатам.
Ну это почти как правило, о том, что перед тем как опубликовать уязвимость, надо о ней разработчику написать.
Топик удивил! Да еще и на главной.
Здравый смысл говорит, что на хостах подключенных к этой циске, она все-таки стоит шлюзом по-умолчанию.
Далее варианта два:
1) Сказать циске, что это одна сеть, поменять маску на меньшую и объединить два интерфейса. Но по условию задачи, маску я так понял менять нельзя.
2) На циске, статически транслировать адреса из одной сети в адреса другой сети. Но это тоже не пройдет по условию задачи.
3) Транслировать адреса динамически, т.е. S-NAT. Пакеты пришедшие из другой сети, хосты будут видеть как пакеты от циски.
Тема хорошая и интересная, только не совсем понятно чего вы хотите добиться. То-ли балансировки нагрузки, то-ли отказоустойчивости, то-ли того и другого вместе.
Я совсем не понял «Сейчас мы настроим сеть состоящую из шлюза и сервера. На шлюзе будет работать SSH и DNS, а сервер у нас будет виндовый на нем у нас RDP и SMTP. Сеть будет настроена таким образом, что через любой из внешних айпишников мы сможем подключаться к любому из серверов....» — так все-таки у вас один сервер или много? Где эти сервера вообще стоят? В DMZ? — Было бы хорошо, если бы была схемка!
Не проще ли рассмотреть ситуацию без шлюза, просто хост с двумя интерфейсами во внешнюю сеть? Я полагаю тогда и двух внутренних айпишниках необходимость отпадет — они вводят в замешательство. Да и не понятно какой из них будет шлюзом в локальной сети. Первый? второй? любой?
вот еще что не совсем логично: элементы из областей неделя и хаос можно перенести на пустое пространство страницы, только непонятно почему эти элементы пропадают при переключении эта_неделя/след_неделя, т.е. они остаются привязанными, хотя визуально это не так. если не прятать, то у пользователя появится возможность перенести на след неделю и сразу указать размещение.
есть подозрение, что это не очень удобно — многие хорошо запоминают положение на листе — им будет проще ориентироваться. можно попробовать сделать страницы хаоса, где расположение не меняется, и показывать все время случайную страницу, если все на одну не влезает.
Странно стойкое желание писать ботов, которые могут жить только на openfire-сервере — как-то это очень не универсально.
Да и еще в добавок он должен крутится на том же хосте, что и сервер — что в двойне странно.
а можно увидеть ссылку на ужасный циферблат на moo?
может быть все-таки как-то можно на основе циферблата решение сделать? а то так — это для роботов, а не для людей решение.
попадались ли какие-нибудь решения интервального timepicker-а?
Ну это почти как правило, о том, что перед тем как опубликовать уязвимость, надо о ней разработчику написать.
Топик удивил! Да еще и на главной.
Но концепция очень интересна.
Далее варианта два:
1) Сказать циске, что это одна сеть, поменять маску на меньшую и объединить два интерфейса. Но по условию задачи, маску я так понял менять нельзя.
2) На циске, статически транслировать адреса из одной сети в адреса другой сети. Но это тоже не пройдет по условию задачи.
3) Транслировать адреса динамически, т.е. S-NAT. Пакеты пришедшие из другой сети, хосты будут видеть как пакеты от циски.
Я совсем не понял «Сейчас мы настроим сеть состоящую из шлюза и сервера. На шлюзе будет работать SSH и DNS, а сервер у нас будет виндовый на нем у нас RDP и SMTP. Сеть будет настроена таким образом, что через любой из внешних айпишников мы сможем подключаться к любому из серверов....» — так все-таки у вас один сервер или много? Где эти сервера вообще стоят? В DMZ? — Было бы хорошо, если бы была схемка!
Не проще ли рассмотреть ситуацию без шлюза, просто хост с двумя интерфейсами во внешнюю сеть? Я полагаю тогда и двух внутренних айпишниках необходимость отпадет — они вводят в замешательство. Да и не понятно какой из них будет шлюзом в локальной сети. Первый? второй? любой?
Путанно все как-то пока (
главное штопор в нее не завернуть!
Да и еще в добавок он должен крутится на том же хосте, что и сервер — что в двойне странно.
может быть все-таки как-то можно на основе циферблата решение сделать? а то так — это для роботов, а не для людей решение.
попадались ли какие-нибудь решения интервального timepicker-а?