У меня есть Linux-сервер (CentOS 5.5) с прямым доступом в Интернет с фиксированным IP-адресом. То есть IP-адрес 200.29.X.Y. Шлюз предоставлен центром обработки данных (200.29.X.Z), и соединение работает идеально.
Мне нужно подключиться к другому компьютеру, расположенному в удаленной локальной сети. Мы договорились сделать это через VPN, поэтому они настроили туннель (IPsec с использованием предварительного ключа) и предоставили нам всю информацию (одноранговый узел, домен шифрования, свойства фазы 1 и свойства фазы 2).
Проблема в том, что моя машина не защищена брандмауэром, и у меня нет доступа к брандмауэру центра обработки данных ... Таким образом, брандмауэр должен быть создан на том же компьютере (с использованием любого программного обеспечения командной строки VPN).
Проблема в том, что если моя машина имеет брандмауэр (и настраивает VPN), одноранговый узел будет одним и тем же доменом шифрования (то есть одним и тем же IP-адресом для однорангового узла и домена шифрования) ...
Другая часть сообщила мне, что это неправильно, и при такой конфигурации их брандмауэр не знает, куда отправлять ответы (поскольку домен шифрования является одним и тем же узлом).
Пытаясь решить эту проблему, я создал виртуальный интерфейс Ethernet под названием eth0.4 с локальным IP-адресом 192.160.0.4; и я сказал другой части настроить это как мой домен шифрования, но он все равно не работает.
Выполняя несколько локальных тестов с внутреннего виртуального IP-адреса 192.160.0.4, я не могу проверить связь с моим настоящим IP-адресом 200.29.X.Y (ping -I eth0.4 200.29.X.Y) ... Я добавил некоторые правила пересылки в iptables, но мой внутренний IP-адрес все еще не может взаимодействовать с моим реальным IP-адресом ... Поэтому я думаю, что этот «виртуальный локальный IP-адрес» не решит мою проблему (если я не добавил некорректную пересылку правила).
Я использую openswan для настройки VPN и в соответствии с другой частью, они получают данные фазы I, они верны, но есть проблема с ответом ... поэтому туннель никогда не создается (фактически, этап I никогда не завершается).
010 «сеть-сеть» # 1: STATE_MAIN_I1: повторная передача; будет ждать ответа 20 с
010 «сеть-сеть» # 1: STATE_MAIN_I1: повторная передача; будет ждать ответа 40 с
010 «сеть-сеть» # 1: STATE_MAIN_I1: повторная передача; будет ждать ответа 40 с
010 «сеть-сеть» # 1: STATE_MAIN_I1: повторная передача; будет ждать ответа 40 с
031 "net-to-net" # 1: максимальное количество повторных передач (20) достигло STATE_MAIN_I1. Нет ответа (или нет приемлемого ответа) на наше первое сообщение IKE
000 "net-to-net" # 1: начало второй попытки ввода неограниченного числа, но безвозвратный удар ...
Журнал openswan не дает мне дополнительной информации (он отправляет правильные данные, но не отвечает), а tcpdump всегда сообщает мне, что я отправляю пакеты, но нет ответов ...
Какие-либо предложения?
Если я правильно понимаю, другая сторона говорит, что они не могут завершить туннель до адреса, который настроен в качестве целевой сети для туннелируемых данных. Это зависит от возможностей их устройства - вы знаете, от какого оно производителя?
Несмотря на озабоченность по поводу определения удаленной сети и их проблемы с их системой, пытающейся вернуть пакеты ESP туннеля в туннель, они даже не отвечают на ваши пакеты фазы 1 - это подключение необходимо сначала изучить. Скажите им, чтобы они начали отвечать на ваши пакеты ISAKMP, а затем разобраться с удаленными сетями IPSec, как только они заработают.