ЯR
да я понял, что его нет, но его надо создать
этот нат будет использован только для вашей задачи - для вывода самого роутера в туннель на указанные в листе адреса. Больше ни для чего он не будет нужен
Size: a a a
2021 February 21
VP
этот нат будет использован только для вашей задачи - для вывода самого роутера в туннель на указанные в листе адреса. Больше ни для чего он не будет нужен
Не совсем так. Там НАТ нужен, но не по dst-adress-list
ЯR
Не совсем так. Там НАТ нужен, но не по dst-adress-list
все именно так как я пишу. В нате так же нужно будет указать src-address - IP адрес интерфейса линка с маршрутом по-умолчанию
VP
все именно так как я пишу. В нате так же нужно будет указать src-address - IP адрес интерфейса линка с маршрутом по-умолчанию
Если речь об аутпуте, то нет .
VB
все именно так как я пишу. В нате так же нужно будет указать src-address - IP адрес интерфейса линка с маршрутом по-умолчанию
смотрите, с манглом на оутпуте оно выходит как раз с адресом интерфейсна на котором дефултроут, но потом заворачивается в туннель. При этом принимающая сторона туннеля обратно не может послать ответ т.к. адрес левый. поэтому его можно былобы натом на выходе поменять на нужный (туннельный)
VP
смотрите, с манглом на оутпуте оно выходит как раз с адресом интерфейсна на котором дефултроут, но потом заворачивается в туннель. При этом принимающая сторона туннеля обратно не может послать ответ т.к. адрес левый. поэтому его можно былобы натом на выходе поменять на нужный (туннельный)
Совершенно верно. И для этого никакие адресслисты не нужны
ЯR
Если речь об аутпуте, то нет .
Задача - отправить пакет в не-дефолтный интерфейс c нужным src-адресом. Она решается легко именно так как я написал. Я не теоритезирую а применяю это на практике
VP
Задача - отправить пакет в не-дефолтный интерфейс c нужным src-адресом. Она решается легко именно так как я написал. Я не теоритезирую а применяю это на практике
Ну, если Вы считаете, что Ваша практика совершенно верна, тогда да. )
ЯR
смотрите, с манглом на оутпуте оно выходит как раз с адресом интерфейсна на котором дефултроут, но потом заворачивается в туннель. При этом принимающая сторона туннеля обратно не может послать ответ т.к. адрес левый. поэтому его можно былобы натом на выходе поменять на нужный (туннельный)
про обратную сторону линка мы не говорим в данном ТЗ, там подразумевается что возврат гарантирован
VP
про обратную сторону линка мы не говорим в данном ТЗ, там подразумевается что возврат гарантирован
Если возврат гарантирован, тогда в чем смысл НАТ?
ЯR
Если возврат гарантирован, тогда в чем смысл НАТ?
выйти с нужного интерфейса с нужным IP
ЯR
без манглов и маркировок пакетов и коннектов
VP
выйти с нужного интерфейса с нужным IP
Так если возврат гарантирован, какая разница, с каким IP будет "выход"? )
ЯR
ну тк возврат именно поэтому и будет гарантирован
ЯR
тк та сторона увидит правильный src и на него и ответит
VP
без манглов и маркировок пакетов и коннектов
Если нет манглов и маркировок, то значит есть четкий маршрут. А если есть четкий маршрут, то НАТ тем более не нужен, поскольку соурс IP будет взят из префсоурса аутинтерфейса. )
ЯR
Если нет манглов и маркировок, то значит есть четкий маршрут. А если есть четкий маршрут, то НАТ тем более не нужен, поскольку соурс IP будет взят из префсоурса аутинтерфейса. )
четки маршрут будет в отдельной таблице
ЯR
вот как в нее попасть - решается так, как я описал
ЯR
наиболее ресурсоэффективно
VP
вот как в нее попасть - решается так, как я описал
НАТ никак не решает в какую таблицу попасть.