у тебя просто трафик идет по разным маршрутам

да вот я тоже думаю

включи нат на R1 для трафика до камеры

между ними еще много на самом деле роутер тоже через ospf

у тебя приходит внешний айпишник до камеры, соответственно обратно он пойдет по своему дефолтному маршруту

включив нат на R1, до камеры дойдет айпишник интерфейса R1

включив нат на R1, до камеры дойдет айпишник интерфейса R1

ок спасибо , щас попробую

Всем привет, подскажите как пробросить порт в этой ситуации? На R1 белый ip , R2 по ospf в локальной сети с R1 , но для всех хостов R2 заведен простой инет. Если 0.0.0.0/0 пустить через R1 то все работает, а если через простой инет R2 то нет.

Либо на р1 делать и dst nat и src nat. Либо на всех хостах от р1 до камеры маркировать соединения и ответ направлять на те порты откуда был пакет инет->камера

Либо на р1 делать и dst nat и src nat. Либо на всех хостах от р1 до камеры маркировать соединения и ответ направлять на те порты откуда был пакет инет->камера

я предложил по моему мнению самый простой вариант

я предложил по моему мнению самый простой вариант

Подскажите в dst. Address ip камеры нужно вбивать? out interface тот за которым камера?

Подскажите в dst. Address ip камеры нужно вбивать? out interface тот за которым камера?

ну да, интерфейс можно и не указывать

ну да, интерфейс можно и не указывать

а во вкладке action to address: нужен белый ip инета?

блин, запутал ты меня

на R2 тоже маскарад работает:)

dst белый адрес R1, а в action адрес камеры

Ну я сделал при попытке подключится счетчик пакетов срабатывает ,

dst белый адрес R1, а в action адрес камеры

У R2 нету белого адреса

очепятался

R1

ок спс

Не получается попробую Vlanom разделить до роутера где инет через R1

значит просто что-то сделал не так

Друзья, а какого уровня в OSI считается BRAS?

Друзья, а какого уровня в OSI считается BRAS?

???

BRAS маршрутизатор это ядро l4? Правильно я понял?

BRAS маршрутизатор это ядро l4? Правильно я понял?

😂😂😂

Да, я в это пень

L85

Вот хочу сообразить

минимум, +фаерболы умеет

Друзья, а какого уровня в OSI считается BRAS?

а что такое «уровень»?

Layer

Я это имел ввиду

Layer

https://youtu.be/je0QFU7p5Oo

https://youtu.be/je0QFU7p5Oo

хорошее было бы видео, если бы не наврало в самом главном

Layer

что Layer? что вы имели в виду под словом Layer, можете описать?

хорошее было бы видео, если бы не наврало в самом главном

вы не сделали лучше )

однако, сделал(

но надо переделать

однако, сделал(

в студию )

главное вранье там - попытка соотнести уровни и протоколы (а еще девайсы)

ни протоколы, ни девайсы к уровням не относятся

главное вранье там - попытка соотнести уровни и протоколы (а еще девайсы)

это натянутая условность для дилетантов

из которой потом вытекают натянутые условности в виде того, что BRAS относится к уровню 4

я согласен, что устройства там притянуты за уши, но дилетантам так немного понятнее

не так важно, притянутое вранье или не притянутое, оно все равно остается враньем

а дилетантам становится понятнее, но совершенно не то

вранье или упрощение

вранье

упрощение имеет какую-то компоненту правды, скрывая ненужные в контексте детали

продавец врет тогда 100% времени

вранье не имеет компонента правды, напрямую противореча правде и причудливо выворачивая ее наизнанку

"Уровень" в OSI - совокупность функций, выполняющих некоторую задачу в процессе коммуникации

список задач закрытый, их всего 7

тогда сделайте ролик для дилетантов на 7 минут с описанием OSI, который будет понятен хотя бы 10 бабушкам

протоколы/устройства могут реализовывать некоторые функции, относящиеся к одному или нескольким уровням

протоколы/устройства могут реализовывать некоторые функции, относящиеся к одному или нескольким уровням

это тонкости, которые бабушкам не нужны

тогда сделайте ролик для дилетантов на 7 минут с описанием OSI, который будет понятен хотя бы 10 бабушкам

самая главная ложь этого видео: оно рассказывает понятным для бабушек образом нечто, что не имеет никакого отношения к модели OSI

с тем же успехом можно было бы кусок передачи малахова про здоровье показать - тоже вроде все понятно

(неявное следствие: никому не нужно знать, что такое модель OSI, потому что и без нее прекрасно обходятся)

самая главная ложь этого видео: оно рассказывает понятным для бабушек образом нечто, что не имеет никакого отношения к модели OSI

самая главная ложь - это то, что людям нужна еда. им нужны калории и баланс микроэлементов

вот стандарт

вот цитата из него

вот стандарт

а теперь пожалуйста его в 7 минут ролика

зачем?

и что бы без терминов

чтобы что?

зачем?

что бы 10 бабушек посмотрело и поняло

1. мне наплевать на 10 бабушек 2. от того, что поймут 10 бабушек, мир не изменится 3. даже если все бабушки в мире посмотрят и поймут, что они раньше знали модель OSI неправильно, ничего не изменится все равно. потому что тот факт, что все бабушки в мире уже сейчас не знают, что такое модель OSI, наглядно показывает, что она не нужна

1. мне наплевать на 10 бабушек 2. от того, что поймут 10 бабушек, мир не изменится 3. даже если все бабушки в мире посмотрят и поймут, что они раньше знали модель OSI неправильно, ничего не изменится все равно. потому что тот факт, что все бабушки в мире уже сейчас не знают, что такое модель OSI, наглядно показывает, что она не нужна

твоё мнение понятно. но условным бабушкам тоже хочется упрощённого объяснения. как мне, например про реакторы и погружение на 1 км.

а fasttrack подразумевает accept? надо дублировать?

а fasttrack подразумевает accept? надо дублировать?

под fasttrack правилом нужно accept правило, которое может поймать все пакеты, подпадающие под fasttrack правило. они не обязательно должны быть одинаковыми, например, у меня фастрэчатся только established,related пакеты между определёнными сетями, а акцептятся все est,rel пакеты

благодарю, освежил на всякий... просто не очень понятна логика... зачем нужен fasttrack без accept?

благодарю, освежил на всякий... просто не очень понятна логика... зачем нужен fasttrack без accept?

если я правильно понимаю, fasttrack работает на нетфильтровых flowtable. он создаёт две записи в таблице с конкретными src-addr,src-port,protocol,dst-addr,dst-port (и обратно), и после этого входящие на интерфейс пакеты, подпадающие под эти критерии, отправляются самым коротким путём в исходящий интерфейс (в идеале просто копируется из буфера ingress интерфейса в буфер egress интерфейса) но чтобы эту запись в flowtable создать, пакет надо сначала разрешить. поэтому нужно правило, которое пропустит как минимум первый пакет соединения

под fasttrack правилом нужно accept правило, которое может поймать все пакеты, подпадающие под fasttrack правило. они не обязательно должны быть одинаковыми, например, у меня фастрэчатся только established,related пакеты между определёнными сетями, а акцептятся все est,rel пакеты

accept в цепочке форвард же?

accept в цепочке форвард же?

а fasttrack кроме как в форварде не имеет смысла

а fasttrack кроме как в форварде не имеет смысла

я тут тоже хотел подробнее разобраться по фасттреку и нашел тоже условие про ацепт после фасттрека, но тогда не понятно, зачем автор в статье сделал 2 правила между ван и бридж туда и обратно по фасттреку и после этих правил форвард-акцепт

сколько Олегов собралось, разберемся... я думаю, что ещё нюанс в том, что не все пакеты идут в фасттрак

в условиях типы пакетов и трафика не указывались,только соединения

conntrack сам отслеживает адреса, порты и sequence numbers

я понимаю, но речь про то, что даже по счётчикам видно, соединение периодически акцептится какими-то пакетами

но ему нужно сначала увидеть оба направления соединения