IPSec туннель между двумя CentOS 6.3

racoon не создаёт ipsec* интерфейс. Разруливается всё это через iptables

У редхатов «родной» openswan. Бери и пользуйся, примеры настроек - в гите и в доках внутри пакета.

Т.е. лучше использовать openswan? А ipsec не заставить работать? Просто требуется именно с помощью него.

ipsec - это протокол. а racoon/strongswan/openswan это фреймворки для работы с ним со своими особенностями. Самый просто способ - настроить между серверами шифрование в transport режиме и всё. Если нужно роутить какие-либо подсети, то создать туннельные интерфейсы типа gre/ipip и роутить через них.

Выше уже написали, что такое IPSec.
Не надо искать «статейки». В изменчивом никсовом мире они устаревают быстрее, чем успевает протухнуть кэш гугла. Бери официальную документацию и узнавай, что есть что и кто на ком стоял.
А то еще не узнал, что такое IPSec, а уже полез «настраивать».

В общем спрошу еще раз: из-за чего возникает

Bringing up interface ipsec0:  Device does not seem to be present, delaying initialization.

Чувак, ты вобще осознаешь, что твой вопрос выглядит вот так: «я не глядя накопипастил первых попавшихся конфигов от одной операционки в другую операционку, каковые конфиги я взял с сайта с полумашинными переводами туториалов, написанными в неизвестном году, а еще я поставил софт из первого попавшегося репозитория и у меня ничего не работает, помогите разобраться»?
Какие тут нафиг могут быть «ответы по делу»?
Сноси левый реп со всем тамошним софтом, ставь openswan и лезь копипастить из /usr/share/openswan-какаятамнынчеверсия-doc. Хочешь учиться рхелу - учись рхелу, а рукоделие отложи на потом.

Ну не такой я уж и дЭбил, как в описании выше :) Хотя, если так уж хочется, по ряду причин, то представляйте меня таким :) В сети искал про настройку ipsec на CentOS и почему-то мне попадалась не одна статья именно с использованием racoon, поэтому и стал двигаться именно в ту сторону. Само собой смотрел в рамках одной и той же операционки, если открыть пиведенную для примера ссылку - можно увидеть, что там не debian и не *BSD. Сейчас один из серверов, на котором планирую ipsec отлично работает в качестве сервера openvpn, но если я не ошибаюсь для соединения двух офисов надо нечто большее, чем просто openvpn, если я ошщибаюсь - пожалуйста поправте меня. Про openswan читаю и пробую понять чем он лучше.

Да не пытаюсь я тебя представить дэбилом, ну прекрати. Просто пришел человек и говорит - пацаны, я тут кактус нашел, помогите прожевать.
Да выплюнь ты кактус, а мы поможем :)

если я не ошибаюсь для соединения двух офисов надо нечто большее, чем просто openvpn, если я ошщибаюсь - пожалуйста поправте меня

Поправляю: ошибаешься. На ЛОРе тыщща тем про это. Они хорошо ищутся по фразам типа «хочу связать две сети, из одной пакеты не идут в другую» или типа того. OpenVPN народ часто выбирает в силу простоты его настройки.

Но ксли надо именно IPSec, все-таки воткни openswan'а, у него в каталоге с доками готовые примеры конфигов лежат. Если аутентификация не по сертификатам, то настройка сводится практически к копипасте конфигов (если остальное в сетевых настройках уже сделано и сети маршрутизируются как надо).

ЗЫ. Ну воткнула шапка в шестой версии openswan'а (pluto) по дефолту, всё, про туториалы от пятерки можно забыть.

Завтра в офисе попробую openswap. Спасибо большое за силы, которые пришлось потратить на разъяснение. P.S. Про кактус - очень наглядно :)

что-то пока не пойму с чего начать, да и доков особо не нашел:

# locate openswan
/usr/lib/python2.6/site-packages/sos/plugins/openswan.py
/usr/lib/python2.6/site-packages/sos/plugins/openswan.pyc
/usr/lib/python2.6/site-packages/sos/plugins/openswan.pyo
/usr/share/doc/openswan-2.6.32
/usr/share/doc/openswan-2.6.32/BUGS
/usr/share/doc/openswan-2.6.32/CHANGES
/usr/share/doc/openswan-2.6.32/COPYING
/usr/share/doc/openswan-2.6.32/CREDITS
/usr/share/doc/openswan-2.6.32/LICENSE
/usr/share/doc/openswan-2.6.32/README
/var/lib/yum/yumdb/o/b0828e6ff519435de9d07255c2c28e6969712be4-openswan-2.6.32-19.el6_3-x86_64
/var/lib/yum/yumdb/o/b0828e6ff519435de9d07255c2c28e6969712be4-openswan-2.6.32-19.el6_3-x86_64/checksum_data
/var/lib/yum/yumdb/o/b0828e6ff519435de9d07255c2c28e6969712be4-openswan-2.6.32-19.el6_3-x86_64/checksum_type
/var/lib/yum/yumdb/o/b0828e6ff519435de9d07255c2c28e6969712be4-openswan-2.6.32-19.el6_3-x86_64/command_line
/var/lib/yum/yumdb/o/b0828e6ff519435de9d07255c2c28e6969712be4-openswan-2.6.32-19.el6_3-x86_64/from_repo
/var/lib/yum/yumdb/o/b0828e6ff519435de9d07255c2c28e6969712be4-openswan-2.6.32-19.el6_3-x86_64/from_repo_revision
/var/lib/yum/yumdb/o/b0828e6ff519435de9d07255c2c28e6969712be4-openswan-2.6.32-19.el6_3-x86_64/from_repo_timestamp
/var/lib/yum/yumdb/o/b0828e6ff519435de9d07255c2c28e6969712be4-openswan-2.6.32-19.el6_3-x86_64/installed_by
/var/lib/yum/yumdb/o/b0828e6ff519435de9d07255c2c28e6969712be4-openswan-2.6.32-19.el6_3-x86_64/reason
/var/lib/yum/yumdb/o/b0828e6ff519435de9d07255c2c28e6969712be4-openswan-2.6.32-19.el6_3-x86_64/releasever

ну само собой не было документации т.к. я ее не поставил

# yum install openswan-doc

а тут что-то глухо, или не то ищу...

/usr/share/doc/openswan-doc-2.6.32/quickstarts/host-host.txt

«L"eft == „L"ocal, „R"ight == „R"emote, для простоты админа. На самом деле это пофиг, насколько я знаю, можно и наоборот и даже симметрично - одну машину считать лефтом, другую - райтом. Если у тебя туннель должны держать пограничные машины, торчащие непосредственно в незащищенную сеть, то проблем даже на старте быть вообще не должно.

С ключами застопорился я... попробовал сгенерить, но:

# ipsec newhostkey --output /etc/ipsec.d/polygon.secrets --configdir /etc/ipsec.d/ --verbose
getting 60 random bytes from /dev/random...

Может не так объяснил, но у меня интерфейсы, между которыми настроено соединение, а точнее туннель ipsec. закрыты по полной, кроме крайне необходимых портов, а если бы создались интерфейсы, то я бы открыл между ними все, но не понял пока можно ли так сделать или же как-то все с помощью iptables и route.

Допиши leftsubnet=местная_сетка и rightsubnet=удаленная_сетка (если у тебя left считается local'ом с обеих сторон) на шлюзах - будет тоннель между сетками.
Тогда возникнет особенность: трафик между шлюзами и между шлюзом и удаленной сетью шифроваться не будет. Чтобы шифровался, надо будет еще сплясать.

Что-то не так я понял видимо. Донастроил conf, дописав вышесказанное:

conn office1-office2
        left=xx.xx.xx.xx
        leftrsasigkey=1KEY
        leftsubnet=192.168.0/24
        right=yy.yy.yy.yy
        rightrsasigkey=2KEY
        rightsubnet=192.168.1/24
        auto=start

# service ipsec status
IPsec running  - pluto pid: 26050
pluto pid 26050
1 tunnels up
some eroutes exist

Пинги не идут откуда и куда?
Должны ходить только из внутренней сети во внутреннюю сеть, то есть, если ты тупо пингуешь со шлюза противоположную сеть, то отклика быть не должно.

Пинги из внутренней сети во внутреннюю не идут. Думаю что я забыл. И еще меня терзает смутное сомнение, что у меня в одном из офисов сетка то tun и там компьютеры, подключенные по vpn. Кстати, решил конфиг немного изменить:

conn office1-office2 
left=xx.xx.xx.xx 
leftrsasigkey=1KEY 
leftsubnet=192.168.0.0/24 
leftsourceip=192.168.0.1 
leftnexthop=yy.yy.yy.yy 
right=yy.yy.yy.yy 
rightrsasigkey=2KEY 
rightsubnet=192.168.1.0/24 
rightsourceip=192.168.1.1 
rightnexthop=xx.xx.xx.xx 
auto=start

сетка то tun и там компьютеры, подключенные по vpn

А подробнее?

Ну в одном случае сеть это реальная сеть 192.168.0.0/24, состаящая из реальных компов, а в другом случае это сеть, которая состоит из компьютеров, подключенных по VPN.

Я перестал понимать топологию начисто.
192.168.1.0/24 - это всё ВПНщики? Которые подключаются ко второй машине с центосом?
Дык может выкинуть эту вторую машину и пусть ВПНщики подключаются прямо к первой?

к сожалению так нельзя. Политика компании и прочая хрень :(

Дык распиши подробнее топологию, что куда как, где какие интерфейсы.
Я думал у тебя просто две сети, в каждой шлюз с белым айпишником, между ними - страшный интернет и всё.

Ну в конце рабочего дня я пробовал соединить и такие две сети. С одной стороны мой сервак с двумя сетевухами, являющийся шлюзом в сети предприятия и раздающий интернет посредством маскарадинга. Он же DHCP-сервер :) А с другой стороны сервер другой конторы со своими администраторами. В общем настроили, запустили ipsec и вот что странно, мою локальную сетку пинговать получалось компы в моей сетке с компов удаленной конторы, а я не мог пинговать с компов своей сетки компы удаленной. Пытались понять из-за чего так, а точнее у кого искать что не так настроено. По идее, если ко мне в сеть зайти можно, то у меня все открыто как надо?

Понимаю, что все смазанно объяснил, но после выяснений голова квадратная.

Еще я читал про ipsec, что если маскарадинг используется, то надо настроить так, чтобы пакеты не «улетали» куда не следует

-A POSTROUTING -s 192.168.0.0/24 ! -d 192.168.100.0/24 -o eth0 -j MASQUERADE

Ну ты от меня уже вообще чистой телепатии ждешь.
Насчет iptables и прочего - openswan не требует существования маршрутов между сетями, то есть объяснять отдельно каждому шлюзу, куда слать пакеты для удаленной сети, не надо. Также не надо эти пакеты пытаться НАТить и т.д.

Насчет ВПНщиков - поищи конфиги по слову roadwarriors. Подход в случе «две сети + третья подсеть для ВПН-клиентов» может быть такой: создается подключение шлюз-шлюз, без всяких *subnet, по имени, допустим, «gws», создается второе подключение с объявлением подсетей локалок, а потом создается третье подключение, где указываются подсеть ВПН и подсеть «удаленной» локалки. Во втором и третьем подключении дописываешь also=gws. Вроде ничего не напутал.

То есть, если у тебя вторая подсеть это только клиенты ВПН, то подключения будет описано два. А вот уж как они у тебя там ходят - я понятия не имею, поэтому никакой конкретики.

Телепаты все в отпуске :) Расписать все боюсь полностью не смогу, слишком много нюансов, значит просто попробую советов поспрашать. Пожалуйста зацените мой iptables, все ли в нем нормально:

# -----------------------------------------
*mangle
:PREROUTING ACCEPT [34958297:39645763956]
:INPUT ACCEPT [17757159:26908722455]
:FORWARD ACCEPT [17173449:12734838055]
:OUTPUT ACCEPT [18117228:14741085767]
:POSTROUTING ACCEPT [35210740:27478343141]
-A POSTROUTING -o virbr0 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill 
COMMIT
# -----------------------------------------
*filter
:INPUT ACCEPT [17749571:26908217993]
:FORWARD ACCEPT [301352:17004305]
:OUTPUT ACCEPT [18117223:14741085425]
-A INPUT -p udp --dport 500 -j ACCEPT
-A INPUT -p esp -j ACCEPT
-A INPUT -p ah -j ACCEPT
-A INPUT -i eth0 -j ACCEPT
-A INPUT -i virbr0 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8080 -j ACCEPT
-A INPUT -i virbr0 -p udp -m udp --dport 53 -j ACCEPT 
-A INPUT -i virbr0 -p tcp -m tcp --dport 53 -j ACCEPT 
-A INPUT -i virbr0 -p udp -m udp --dport 67 -j ACCEPT 
-A INPUT -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT 
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -s 192.168.0.0/24 -j ACCEPT 
-A FORWARD -d 192.168.0.0/24 -j ACCEPT
-A FORWARD -i virbr0 -o virbr0 -j ACCEPT 
-A FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable 
-A FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable 
-A FORWARD -m state --state ESTABLISHED -j ACCEPT 
-A FORWARD -d 192.168.0.10/32 -i eth1 -o eth0 -p tcp -m tcp --dport 22 -j ACCEPT 
-A FORWARD -d 192.168.0.15/32 -i eth1 -o eth0 -p tcp -m tcp --dport 22 -j ACCEPT 
-A FORWARD -i eth0 -o virbr0 -j ACCEPT 
-A FORWARD -i virbr0 -o eth0 -j ACCEPT 
-A FORWARD -j REJECT --reject-with icmp-host-prohibite
COMMIT
# -----------------------------------------
*nat
:PREROUTING ACCEPT [2013932:128257452]
:POSTROUTING ACCEPT [471284:37965402]
:OUTPUT ACCEPT [825202:68223145]
-A PREROUTING -d xx.xx.xx.xx/32 -p tcp -m tcp --dport 18822 -j DNAT --to-destination 192.168.0.10:22 
-A PREROUTING -d xx.xx.xx.xx/32 -p tcp -m tcp --dport 18922 -j DNAT --to-destination 192.168.0.15:22 
-A POSTROUTING -o eth1 -j MASQUERADE 
# может правильнее вот так: -A POSTROUTING -s 192.168.0.0/255.255.255.0 ! -d 192.168.1.0/255.255.255.0 -o eth1 -j MASQUERADE
-A POSTROUTING -d 192.168.0.10/32 -p tcp -m tcp --dport 22 -j SNAT --to-source xx.xx.xx.xx 
-A POSTROUTING -d 192.168.0.15/32 -p tcp -m tcp --dport 22 -j SNAT --to-source xx.xx.xx.xx 
COMMIT
# -----------------------------------------

eth1 - смотрит в интернет и имеет внешний IP xx.xx.xx.xx

Разобрался, дело было как и предполагал в настройках iptables. Надо было:

-A POSTROUTING -s 192.168.0.0/255.255.255.0 ! -d 192.168.1.0/255.255.255.0 -o eth1 -j MASQUERADE

-A POSTROUTING -o eth1 -j MASQUERADE