https://www.opennet.ru/openforum/vsluhforumID6/1626.html Добрый день.<br><br>Необходимо дать доступ к серверу (ssh) через ipsec соединение.<br><br>Сервер: 192.168.20.4/24.<br>маршрут на 192.168.1.1 настроен через 192.168.20.5<br><br>C2800:<br><br>Белый адрес(l2tp на провайдера) - 55.55.55.55<br>FE0/0 (в сторону сервера) - 192.168.20.5<br>Loopback 0 (используется как local ident) 192.168.1.1<br>ping 192.168.20.4 source 192.168.1.1 - успешен<br><br>На той стороне ipsec Freebsd:<br><br>Белый адрес: 77.77.77.77<br>Адреса клиентов в туннеле 192.168.200.0/24<br>----<br><br>Как настроить NAT при обращении к 192.168.1.1 из 192.168.200.0/24 попадать на 192.168.20.4<br><br>Пробую сделать так, безуспешно:<br>!<br>version 12.4<br>no service pad<br>service tcp-keepalives-in<br>service tcp-keepalives-out<br>service timestamps debug datetime msec localtime show-timezone<br>service timestamps log datetime msec localtime show-timezone<br>service password-encryption<br>service sequence-numbers<br>!<br>hostname ipsec<br>!<br>boot-start-marker<br>boot-end-marker<br>!<br>!<br>no aaa new-model<br>clock timezone MSK 3<br>no ip source-route<br>ip cef<br>!<br>!<br>!<br>!<br>ip vrf https://www.opennet.ru/openforum/vsluhforumID6/1626.html#19 Fri, 20 Feb 2015 10:06:26 GMT &gt;[оверквотинг удален]<br>&gt; [code] <br>&gt; ip nat inside source list nat_interface interface f0/1 overload <br>&gt; !<br>&gt; ip access-list extended nat_interface <br>&gt; deny ip any 10.0.0.0 0.255.255.255 <br>&gt; deny ip any 192.168.0.0 0.0.255.255 <br>&gt; deny ip any 172.16.0.0 0.15.255.255 <br>&gt; permit ip 192.168.0.0 0.0.0.255 any <br>&gt; !<br>&gt; [/code] <br><br>Понятно. Спасибо.<br><br> https://www.opennet.ru/openforum/vsluhforumID6/1626.html#18 Fri, 20 Feb 2015 03:35:42 GMT &gt;&gt; При попадании в роутер R2 траффик из сети 192.168.0.0/24 будет сперва натится <br>&gt;&gt; а потом будет обработка IPsec.<br>&gt;&gt; Принятые в стек IPsec пакеты будут сперва декапсулированы и снова "как-бы" приняты <br>&gt;&gt; на внешнем интерфейсе (минуя аксес листы правда) и проверены на таблицы <br>&gt;&gt; трансляции.<br>&gt; Интересное решение.<br>&gt; Можно его усложнить?<br>&gt; Если за R2 совсем лузеры, им надо эту самую 192.168.0.0/24 еще <br>&gt; и в инерент выпустить?<br><br>Да как обычно<br><br>[code]<br>ip nat inside source list nat_interface interface f0/1 overload<br>!<br>ip access-list extended nat_interface<br> deny ip any 10.0.0.0 0.255.255.255<br> deny ip any 192.168.0.0 0.0.255.255<br> deny ip any 172.16.0.0 0.15.255.255<br> permit ip 192.168.0.0 0.0.0.255 any<br>!<br>[/code]<br> https://www.opennet.ru/openforum/vsluhforumID6/1626.html#17 Thu, 19 Feb 2015 15:30:27 GMT &gt; При попадании в роутер R2 траффик из сети 192.168.0.0/24 будет сперва натится <br>&gt; а потом будет обработка IPsec.<br>&gt; Принятые в стек IPsec пакеты будут сперва декапсулированы и снова "как-бы" приняты <br>&gt; на внешнем интерфейсе (минуя аксес листы правда) и проверены на таблицы <br>&gt; трансляции.<br><br>Интересное решение.<br>Можно его усложнить?<br>Если за R2 совсем лузеры, им надо эту самую 192.168.0.0/24 еще<br>и в инерент выпустить?<br><br> https://www.opennet.ru/openforum/vsluhforumID6/1626.html#16 Thu, 19 Feb 2015 14:38:51 GMT &gt; При попадании в роутер R2 траффик из сети 192.168.0.0/24 будет сперва натится <br>&gt; а потом будет обработка IPsec.<br>&gt; Принятые в стек IPsec пакеты будут сперва декапсулированы и снова "как-бы" приняты <br>&gt; на внешнем интерфейсе (минуя аксес листы правда) и проверены на таблицы <br>&gt; трансляции.<br><br>Спасибо! Буду иметь ввиду предоставленную информацию!<br><br>С учетом того, что трансляция не работала, а работоспособность туннеля надо было проверять другого варианта наглядно проверить туннель не вижу. <br> https://www.opennet.ru/openforum/vsluhforumID6/1626.html#15 Thu, 19 Feb 2015 14:25:53 GMT При попадании в роутер R2 траффик из сети 192.168.0.0/24 будет сперва натится а потом будет обработка IPsec.<br>Принятые в стек IPsec пакеты будут сперва декапсулированы и снова "как-бы" приняты на внешнем интерфейсе (минуя аксес листы правда) и проверены на таблицы трансляции.<br> https://www.opennet.ru/openforum/vsluhforumID6/1626.html#14 Thu, 19 Feb 2015 14:21:02 GMT &gt;&gt;&gt; Loopback для того, чтобы настроить PAT к 192.168.20.4, через адрес который на <br>&gt;&gt;&gt; нем(lo) висит.<br>&gt;&gt;&gt; Можешь конкретней рассказать о негодовании по поводу использования лупбека?<br>&gt;&gt; Для НАТ наличие интерфейса не обязательно а местами даже вредно, ибо роутер <br>&gt;&gt; часть трафика будет считать "своим" <br>&gt; В условиях когда клиенту нельзя видеть на прямую сети в которой находится <br>&gt; сервер(ssh), что мне оставалось сделать?<br><br>Чтобы транслировать адреса, не обязательно эти адреса иметь на каком-то интерфейсе.<br>Главное чтобы пакеты с такими адресами как-то заходили в роутер, например посредством тунеля и с правильной стороны (inside/outside).<br><br>простой пример:<br><br>(10.0.1.0/24) - (fas0/0 ip: .1)(R1)(fas0/1 ip: r1.r1.r1.r1)-(inet)-(fas0/1 ip:r2.r2.r2.r2)(R2)(fas0/1 ip: .1)-(192.168.0.0/24)<br><br>Пользователи со стороны R1 - крупное предприятие и совершенно справедливо считает лузерами тех, кто в локалке а не домашней сети заводит сеть 192.168.0.0/24.<br>Чтобы как-то дать доступ к своим ресурсам сети R2, они им с барс https://www.opennet.ru/openforum/vsluhforumID6/1626.html#13 Thu, 19 Feb 2015 13:45:11 GMT &gt;&gt; Loopback для того, чтобы настроить PAT к 192.168.20.4, через адрес который на <br>&gt;&gt; нем(lo) висит.<br>&gt;&gt; Можешь конкретней рассказать о негодовании по поводу использования лупбека?<br>&gt; Для НАТ наличие интерфейса не обязательно а местами даже вредно, ибо роутер <br>&gt; часть трафика будет считать "своим" <br><br>В условиях когда клиенту нельзя видеть на прямую сети в которой находится сервер(ssh), что мне оставалось сделать?<br> https://www.opennet.ru/openforum/vsluhforumID6/1626.html#12 Thu, 19 Feb 2015 13:43:38 GMT &gt;[оверквотинг удален]<br>&gt;&gt; пока это в теории, не знаю верно ли предположение?<br>&gt; Подозрение не верно. Loopback интерфейс маршрутизатора не доступен как connected для интерфейса <br>&gt; сервера.<br>&gt; У вас не происходит инкапсуляция трафика от сервера к клиентскому подключению.<br>&gt;&gt; #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0 <br>&gt;&gt; #pkts decaps: 238, #pkts decrypt: 238, #pkts verify: 238 <br>&gt; Попробуйте использовать только NAT. SSH сам по себе защищенный протокол. Использование <br>&gt; для SSH подключения дополнительного шифрования, это все равно что автобус с <br>&gt; пассажирами поставить на отдельную платформу и перевозить платформу, а не использовать <br>&gt; автобус по назначению.<br><br>Спасибо большое за отзывчивость!!! Проблема решена!<br><br>Увы, условия клиента жесткие и требуют ipsec. <br>Инкапсуляции к клиентскому подключению не было возможно потому, что он был неактивен?<br><br>В итоге проблема была решена добавлением еще одного маршрута на сервер(где ssh сервер), как я и предложил выше: -host 192.168.200.21 gw 192.168.1 https://www.opennet.ru/openforum/vsluhforumID6/1626.html#11 Thu, 19 Feb 2015 13:38:39 GMT &gt; Loopback для того, чтобы настроить PAT к 192.168.20.4, через адрес который на <br>&gt; нем(lo) висит.<br>&gt; Можешь конкретней рассказать о негодовании по поводу использования лупбека?<br><br>Для НАТ наличие интерфейса не обязательно а местами даже вредно, ибо роутер часть трафика будет считать "своим"<br>