Antony: При таком подходе, если по какой-либо причине нет возможности изменить порядок добавления адресов на интерфейс - то действительно, никак.
В линуксе вообще нет возможности изменить primary адрес.
Как вариант - вручную навешивать primary адрес, а фейловером накрывать secondary.
Опять же heartbeat-у можно подсунуть скрипт вместо ресурса, и уже скриптом вручную при поднятии удалять и/или передобавлять сразу всю пачку адресов в зависимости от состояния.
Antony: удаляются все адреса только в том случае, если удалить primary адрес для данной подсети. Primary адресом выступает первый добавленный на интерфейс адрес для каждой подсети. Адреса, отмеченные secondary, можно удалять как угодно.
Дамир Синицын: а попробуйте ему симлинком подпихнуть вместо javac.exe - нативный линуксовый ELF-бинарь? Вайн нормально определяет нативные файлы и запускает их как обычные процессы без трансляций.
Проблема может возникнуть, если лаунчер попытается что-то в оперативке на ходу пропатчить.
Если я верно понял, то просто адрес из второй полученной сети опять же на джунипер (их можно на один интерфейс сколько угодно вешать), разрешайте сеть в фаерволе и указывайте этот адрес (который на джунипере) шлюзом на всех остальных хостах принадлежащих этой сети. Должно заработать.
По поводу CCNA - начните с CCNA Discovery и с "Сети Для Самых Маленьких"
pavelkolodin: в таких дистрах апдейты латают все известные дырки, пока не истек срок поддержки. И, при этом, НИКОГДА не добавляют новый функционал (с новыми, еще не найденными дырами, с изменениями форматов конфига, поведением команд, и прочими потенциально опасными изменениями).
Из этого следует, что, сделав apt upgrade, система не превратится в тыкву, а дырки будут закрыты.
Именно здесь намного меньше шанс получить дыру в приложении или сломать сервис при обновлении из-за несовместимости, чем в "самом свежем", которое толком не оттестировали, не вылизали, и попутно сломали десяток опций в конфигах.
zucker: Статьи, думаю, есть, можно поискать по презентациям всяких Цисок и Джуниперов, но в целом технологии и принципы, используемые в высоконагруженных сетях сильно отличаются от того, что можно и нужно использовать в SOHO.
Всякого рода TRILL и подобное ему для коммутации, хитрые L2 VPN, опять же BGP для связи с внешним миром и прочее, что требует больших денег и человеческих ресурсов.
На сервере, конечно.
man screen
Подключился, запустил screen, в нем нужную комманду, отключился от скрина посредством CTRL+a, d, отключился от ssh.
Когда надо возобновить сеанс - снова подключился по ssh, но вместо создания нового сеанса скрина подключаемся к существующему через screen -r
Дмитрий: Тогда теребить договор и техподдержку на предмет наличия NAT. Опять же, если куплен "реальный белый", то и требовать, чтоб он был реальным белым.
Альтернативно, если провайдер все же упирается и говорит, что у вас там full cone nat - динамик днс в скрипте указывать не по local ip, а по внешнему резольверу, типа
/tool fetch mode=https address="wtfismyip.com" src-path="/text" dst-path="/ipaddr"
:local result [/file get ipaddr contents]
Дмитрий: инфа из rfc1918 и rfc6598.
Серые диапазоны для IPv4:
10.0.0.0/8
100.64.0.0/10
172.16.0.0/12
192.168.0.0/16
Понятно, что провайдер внутри может крутить-мутить как угодно, и использовать любые диапазоны адресов, лишь бы наружу не просочились, но при этом высокий шанс отстрелить себе ногу, а пользователям - различные куски интернета.
Ничего не изменится по факту. Агрегация работать будет, но точно так же. Даже если на входе фреймы будут правильно и равномерно размазаны, на выходе опять же коммутатор сам будет решать, в какой порт из группы их впихнуть, опять же по своему алгоритму.
Как вариант - пробовать делать не lacp/ec, а агрегирование средствами ОС (bonding/teaming), и устанавливать tx hash в l3+l4 или в round robin, а на коммутаторе делать порты аксессом в разных вланах, соединяя их соответственно. Но это жуткий костыль,не всюду применим, и не факт, что заработает.
А сферической надежности и предсказуемости поведения - меньше.
Понятно, что грамотный специалист может из тазика с 10г портом и i7 сделать отличный роутер, и оно будет работать десятилетиями, если его не ковырять кривыми руками. Но стоить такой специалист будет намного дороже, чем студент с CCNA, который сможет настроить аналогичный функционал на циске. Правда, циска с аналогичной производительностью может стоить дороже десятка специалистов...
Это даст лишь маршрут, по которому уйдет пакет к клиенту. И если rp_filter выключен, совсем не факт, что маршруты симметричные.
В принципе, решений кроме netfilter и/или pcap, я не могу придумать сходу.
Konkase: Точно не скажу, на таком точно работает:
root@ubuntu14:/etc# tc -V
tc utility, iproute2-ss131122
root@ubuntu14:/etc# uname -a
Linux ubuntu14 3.19.0-25-generic #26~14.04.1-Ubuntu SMP Fri Jul 24 21:16:20 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
