M-a-x-Z

Кто-нибудь знает, в какой момент у сабжа стоковая прошивка применяет правила Firewall? Из-за того, что при пробросе портов нельзя указать определённый диапазон для подключений (например, мне надо прокидывать шаровую домашнюю папку, но только таким образом, чтобы я её видел с работы и ниоткуда больше), мне пришлось задействовать штатный брандмауэр. Выглядит это следующим образом: 1. На вкладке "Трансляция сетевых адресов (NAT)" включена трансляция 445 TCP порта на 445 порт внутреннего сервера 192.168.0.2 (фото 1) 2. На вкладке межсетевого экрана для домашней сети разрешён трафик сервера 192.168.0.2, порт 445 к рабочим ПК на любой порт 3. Весь остальной IP-трафик от узла 192.168.0.2 запрещён (фото 2) В принципе, эта схема даёт желаемый эффект. Но не понятно, в какой момент включаются правила. Например, я сделал настройки из п. 1 и 3. Естественно с работы шара была недоступна. Затем я добавил правило из п. 2 и всё мгновенно заработало. А вот когда я его снова выключил - связь не прервалась и шара была доступна! (Точно это был не кэш, т.к. воспользовался Wireshark для того, чтобы убедиться в наличии трафика). Перезагрузка роутера помогла. Т.е. правило 2 применяется мгновенно, а отключается вообще не понятно как. Гистерезис какой-то. В чём может быть логика?

А почему по L2? По L3 веером сканит сетку и привет. Если на сетий управления ACL на входе нет...

Вот вам две оговорки: 1. Проброс L2 (интересно, а чем ещё занимается L1 и можно ли у него забрать адрес) 2. Вместо /30 берём /32. И уж точно не стоит попусту расходовать паблик на точку-точку между R1 и R2. Проще прокинуть роут и получить 4 белых адреса на R2. А в задаче вы хотите 3 адреса в землю зарыть)

vpdn-group DEFAULT ! Default L2TP VPDN group accept-dialin protocol pptp Вот это циска не хочет жрать. L2TP есть. И даже с IPSec работает, но только не поддерживается. В соседней теме копипастил ответ из TAC по этому поводу. Мол работает? Ок. Не работает - ничем не можем помочь. Ветка заморожена.

Не "не работает", а "никто не поддерживает" (((

По условиям задачи она не разрешима. Если белый адрес остаётся на R1, то его не исопльзовать под NAT на R2. ....если не L2 через R1 на R2. Но тут надо точнее знать железо и ограничения.   Ну и потом в условиях вы пишете про /30, а я говорю, что моно и /32 обойтись.

Так вроде не обязательно абонентов иметь? По L3 IP должен быть виден из любой части сети с клиентами... настоятельно рекомендую на влан управления deny tcp any any eq 4786 log

???? можно полный sh ver (без серийников)?? PPTP там сразу не поддерживается, а L2TP портирован в виде AS-IS из предыдущего релиза софта и тоже не поддерживается. Там один нормальный VPN остался IKEv2 - и тот хрен настроишь. 15 дней у меня кейс в TAC открыт   И кусок конфига, которым вы PPTP включили

Вообще не обязательно /30. Достаточно /32 )) Т.е. точка-точка может быть в любой адресации, распознаваемой R1 и R2. Быть глобально маршрутизируемой ей не надо совсем. А вот поиметь хотя бы один паблик IP на R2 надо ибо во что-то надо NAT. Маршрут на /32 пров должен кинуть в сторону R1, а R2 через частную точку-точку на R2.

Поправка: для SFP прошивка не делает вообще ничего в логике работы. Ну почти ничего. Прошивал для Cisco SM трансиверы прошивку от витопарных. Всё рбаотало. При этом циска показывала уровень оптического сигнала для витопарного(!) трансивера. У Cisco главное, что бы прошитый трансивер покрывался лицензией (LAN Lite не жрёт трансов свыше 10 км) и что бы в одной железяки не было двух трансиворов с одинаковым среийником. А, собственно как вы получили трансивер с железом 100 мбит/с и прошивкой на 1000? Мне кажется, что 8TC-L не держит 100 Мбит/с трансиверы, а прошивка обманывает только ОС, но не сам модуль, который хоть и говорит, что он гиг - работает на 100

"Code: The Captive-Portal DHCPv4 option (160) (one octet)" - очень интересно, удобно и логично. Жаль, что походу все колхозят ((( Ща РКН детекторы каптив-порталов-то поблокирует ((

А есть какие-то таблицы по браузерам - кто куда лезет или rfc описание алгоритма или устоявшийся термин-название?

Сейчас очень много систем с веб-аутентификацией. В Wi-Fi и даже в кабеле. Пользователь, обычно в браузере пытается зайти на нужную страницу и его форвардит на страницу входа. Технически всё понятно - пограничный маршрутник меняет IP-адрес назначения в IP-пакете, следующем на произвольный сервер, порт 80. Но с давнего времени андроиды, а с недавнего времени десктопы (в FF, например) стали выводить плашку "требуется аутентификация в сети. Перейти на страницу входа?" пользователю вместо прямого форварда. Вопрос чисто теоретический: а как браузер узнаёт, что форвард выполнил именно шлюз доступа в интернет? Ведь в обратных пакета от портала, как я понимаю, тоже происходит обратная подмена адреса источника на тот, к которому клиент обращался изначально. И как это работает для HTTPS, ведь там тоже не выдаётся страшное сообщение о том, что подмена узла, В всё тоже нейтральное предупреждение о наличие Captive-портала. То ли в гугле забанили, то ли не могу правильно вопрос сформулировать. Может кто подкинет инфу, где почитать можно про логику браузеров.

Это их собственное требование. Соответственно никому ничего они доказывать не должны и обсера не будет. Просто прекратят блокировку на основе выполнения требовнаий. Кто поумнее закричит "РКН слил". Но основная масса людей скорее поверит в железную руку ФСБ на яйцах Дурова. Имидж-с. А для западных инвесторов в ICO это будет выглядеть как очень тревожный сигнал.

Интересно, а РКН мог бы отомстить Дурову. Просто объявить, что ключи переданы и остановыить блокировку. Репутация телеги в западных странах, на которые Павел делает ставку, после этого будет безнадёжно испорчена, даже если Дуров подаст в суд и в суде докажет обратное.   И репутация РКН на внутреннем хайпе подросла бы.