LAG_LAGbI4: но как маршрутизатор может отвечать интерфейсом, который не смотрит в мою сторону? ведь пакет в таком случае не дойдёт до меня, а уйдёт в сеть провайдера.
Здесь чуть хитрее ;)
Итак:
1. Маршрутизатор R1 в интерфейсе eth0 получает запрос с вашей стороны:
src ip: 77.111.222.5
dst ip: 93.158.134.3
TTL: 1
2. R1 заглядывает в таблицу маршрутизации: что с ним делать? Видит запись: положить в интерфейс eth1 и отправить на маршрутизатор R2.
3. R1 кладёт запрос в очередь отправки интерфейса eth1.
5. Интерфейс eth1 маршрутизатора R1 создаёт сообщение ICMP TTL Exceeded.
Ладно, с destination ip всё понятно: 77.111.222.5
А какой адрес мне указать в качестве адреса отправителя? А возьму-ка я свой - 10.22.2.1!
6. Интерфейс eth1 маршрутизатора R1 выпихивает ответ обратно в системную шину R1.
7. R1 смотрит: ой, пакет для ip-адреса 77.111.222.5! Смотрит в таблицу маршрутизации: куда его девать? Ага! Положить в интерфейс eth0!
Но не с того интерфейса, на который получил traceroute-запрос, а с того, которым смотрит внутрь провайдерской сети.
Поведение это, с непривычки, неочевидное, и объясняется архитектурой маршрутизатора провайдера.
Да, .1, .2 и .5 на схеме - это последние октеты ip-адреса.
Получется, ASBR провайдера смотрит в вашу сторону адресом 77.111.222.1/29, а внутрь провайдерской сети - адресом 10.22.2.1/30
2 Dark Hole :
Если в интернете сидеть - это одно дело.
А автор вопроса, как он пишет, на личном ноутбуке работает - в отличие от ;)
Хочу напомнить, что работа за ПК, в подавляющем большинстве случаев, представляет из себя не сидение в интернете, а изменение множества .doc и .xls-файлов, лежащих в сети в расшаренных папках.
Ах, да!
Ещё часто для нормальной работы надо установить непойми кем и как ломаные Офис и 1C.
Dark Hole: я не безопасник, но пример могу придумать.
Расшаренные папки в сети наверняка есть?
А давайте-ка вспомним про целое семейство дряни, которая подменяет реальные папки своим экзешником с иконкой "папка"!
У всех хватит внимания заметить, что это на самом деле не папка?
И ведь всё это может годами жить в сети предприятия.
1. Принадлежит фирме:
1.1. Стол
1.2. Стул
1.3. Компьютер
1.4. Выданный на работе служебный сотовый телефон
1.5. 8 часов Вашего времени в рабочий день
1.6. Всё, что Вы сделали с использованием пп. 1.1-1.5
2. Вы сами зачем-то дали ему контролировать:
2.1. Список и содержимое сайтов, на которые Вы ходите с использованием пп. 1.1-1.5
2.2. Личный номер телефона, используемый Вами вместо рабочего
2.3. Время сверх рабочего, на которое Вас однажды попросили задержаться, и которое почему-то вошло в норму
Вывод: не хотите слежки - отделяйте личное от рабочего:
1. Не звоните со служебного телефона по личным вопросам
2. Уходя с работы, оставляйте служебный телефон на столе
3. Принадлежащее фирме (пп. 1.1-1.5) используйте только для работы
Господа, предлагаю отбросить эмоции, и включить логику ;)
Итак, исходя из личного опыта:
1. Работодатель обязуется обеспечить работника необходимыми для работы инструментами - в данном случае, ПК. Взамен, работодатель вправе требовать, чтобы эти инструменты использовались исключительно для рабочих целей, для чего вправе контролировать их использование.
Верно? "Вот Вам молоток, но потрудитесь махать им только на рабочем месте".
2. Ещё раз: работодатель _обязан_ обеспечить работника необходимыми инструментами, и приучать работодателя к иному подходу считаю крайне безответственным шагом.
Поскольку ноутбук был уже продемонстрирован, предлагаю придерживаться тактики "Ааааа! Ноутбук сломался, работать не могу! Где мой рабочий компьютер?"
3. Подключение личного ноутбука к сети предприятия нецелесообразно и опасно для обеих сторон. Помните: заразить можете не только Вы, но и, наоборот, Вас!
4. Возможность бесконтрольного подключения к сети предприятия сторонних устройств говорит о низкой компетентности ИТ-отдела, что косвенно свидетельствует о повышенной опасности заразиться Вам самим, потеряв личную информацию: фотографии, реквизиты доступа к социальным сетям и пр.
5. Про полтора часа в день в соцсетях.
Из наблюдаемого лично: пусть на данный момент руководство смотрит на сидение сотрудников в соцсетях сквозь пальцы.
Однако, при сокращении штата - да хоть при распределении премий -руководство, зачастую, смотрит не на профессионализм работника, а на формальные признаки, например, соблюдение трудовой дисциплины.
В таком случае, ИТ-отделу даётся команда: посмотреть, кто куда ходит по интернету, и отчёт по top-10 нарушителей отправить директору.
Если кратко, ищется не причина для увольнения, а повод.
Видел лично, хотя и немного со стороны.
Поэтому: на рабочем ПК только работа, всё личное - на планшете/смартфоне. Повода не давайте.
6. Использование на рабочем месте Tor/VPN.
Я писал про "не давать повода?"
Озвучить реакцию руководства?
"Ладно, эти лентяи в соцсетях сидят. А этот от кого таится? Что и кому он сливает?"
Поэтому:
1. Руководство не балуем и к хорошему не приучаем
2. Повода не даём
Кстати, вдогонку: надо понять, от кого автор вопроса хочет спрятаться?
Мобильного оператора не интересует, сколько народу сидит за вайфаем.
Мобильному оператору интересны:
- сам факт наличия вайфая, потому что за это можно брать дополнительные деньги
- на какие сайты абоненты ходят, потому что за это можно брать деньги не с абонентов, а с владельцев сайта
Есть другие люди - они в погонах - и им интересно, кто что сказал.
Копия абонентского трафика сливается к ним, и как они его обрабатывают, не знает никто. Но род их деятельности предполагает очень глубокий анализ - допускаю, что и с помощью ворованных SSL-сертификатов )
Я не думаю, что они будут разбираться, сколько человек сидит за вайфаем, и за вайфаем ли, и, полагаю, если привлечь их внимание, они придут в первую очередь к тому человеку, на имя которого оформлена сим-карта.
Отсюда и встречный вопрос: от кого именно хочет спрятаться автор вопроса? ;)
Вот!
А я говорил ещё и про случай, когда коммутатор не знает про существование 802.1Q
В SOHO что только не водится )
Вот возьмём, например, прости господи, D-link DES-1008P+
PoE умеет, гигабит якобы держит - а тегирования не умеет.
Если всё это в него воткнуть - схема даже заработает.
Прописываем на интерфейсе роутера адреса из обеих сетей, которые на ПК будут default gateway.
И в интернет обе подсети вылезут.
Но друг с другом будут общаться напрямую, потому acl на роутере прописывать бесполезно.
Поднимать ли три vlan на одном и том же интерфейсе, или на разных - принципиальной разницы нет.
Если надо экономить порты, и перед srx стоит умеющий VLAN'ы свитч - можно и объединить.
Если интерфейсы находятся в одной и той же routing-instance (например, routing-instance не созданы явно, и тогда все интерфейсы находятся в inet.0), то _маршрутизацию_ между сегментами прописывать явно не требуется: SRX и так все адреса знает.
А вот настроить правила фильтрации трафика придётся как раз силами security zone/security policies.
По security zone: если необходимо фильтровать трафик между сегментами, есть смысл создать отдельную security zone для каждого сегмента.
Если требование - чтобы все всех видели без каких-либо ограничений, можно засунуть все три сегмента в одну и ту же security zone.
Внимание! По умолчанию, транзитный трафик блокируется, и его надо явно разрешить в security policy.
Это касается как случая с тремя security zone:
set security policies from-zone zone1 to-zone zone2 policy allow match source-address any destination-address any application any
set security policies from-zone zone1 to-zone zone2 policy allow then permit
И так все возможные комбинации:
zone1 -> zone2
zone2 -> zone1
zone1 -> zone3
и т.д.
Есть ещё один момент: транзитный трафик _внутри_ зоны блокируется тоже, поэтому, даже если все три сегмента будут прописаны в одной и той же security zone, для того, чтобы сегменты увидели друг друга, надо прописать что-то типа:
set security policies from-zone zone1 to-zone zone1 policy allow match source-address any destination-address any application any
set security policies from-zone zone1 to-zone zone1 policy allow then permit
Всю жизнь мечтал увидеть человека, который знает _весь_ SS7 :)
Я - в довольно узкой области: MAP, CAMEL.
И да, BGP, MPLS, RADIUS, Diameter, DPI, спецификации 3GPP Release 11, и если всё это собрать вместе, получится LTE-сеть :)
Зайдём с другой стороны: есть специалист в достаточно узкой области.
Что-то интересное происходит, как и в любом операторе, раз в несколько лет.
Свободное время есть, и хочется потратить его и имеющиеся умения с пользой.
С social networking - беда.
Веб-разработчики в таком случае идут на фриланс-биржу.
А сетевые инженеры?
Инженеры телекома?
Здесь чуть хитрее ;)
Итак:
1. Маршрутизатор R1 в интерфейсе eth0 получает запрос с вашей стороны:
src ip: 77.111.222.5
dst ip: 93.158.134.3
TTL: 1
2. R1 заглядывает в таблицу маршрутизации: что с ним делать? Видит запись: положить в интерфейс eth1 и отправить на маршрутизатор R2.
3. R1 кладёт запрос в очередь отправки интерфейса eth1.
4. Интерфейс eth1 маршрутизатора R1 достаёт запрос из очереди отправки, уменьшает TTL...
Ой! TTL == 0! Надо сообщить отправителю: запрос протух!
5. Интерфейс eth1 маршрутизатора R1 создаёт сообщение ICMP TTL Exceeded.
Ладно, с destination ip всё понятно: 77.111.222.5
А какой адрес мне указать в качестве адреса отправителя? А возьму-ка я свой - 10.22.2.1!
6. Интерфейс eth1 маршрутизатора R1 выпихивает ответ обратно в системную шину R1.
7. R1 смотрит: ой, пакет для ip-адреса 77.111.222.5! Смотрит в таблицу маршрутизации: куда его девать? Ага! Положить в интерфейс eth0!
8. Маршрутизатор LAG_LAGbI4 получает ответ:
TTL Exceeded
dst ip: 77.111.222.5
src ip: 10.22.2.1
9. LAG_LAGbI4 удивляется ;)