Привет всем. Есть такая задача: на Allied Telesyn AT-AR410S настроен VPN сервер, нужно D-link DFL-200 соединить по IPsec L2TP как клиента. С виндовой машины VPN поднимается, а D-link не работает. Если кто-нибудь встречался с такой проблемой, поделитесь опытом пожалуйста.

Вы лучше расскажите как настроено, что в логах устройств...

_________________
С уважением -- Александр Шебаронин.

В Telesyn настройки следующие

NN:# IPSEC configuration
NN:#
NN:create ipsec sas=3 key=isakmp prot=esp enc=des hasha=sha
NN:create ipsec sas=4 key=isakmp prot=esp enc=des hasha=md5
NN:set ipsec sas=4 mod=transport
NN:create ipsec bund=1 key=isakmp string="4"
NN:create ipsec bund=2 key=isakmp string="3"
NN:create ipsec pol="isakmp" int=eth0 ac=permit
NN:set ipsec pol="isakmp" lp=500 rp=500
NN:create ipsec pol="hq" int=eth0 ac=ipsec key=isakmp bund=1 peer=ANY isa="keys

NN:# L2TP configuration
NN:enable l2tp
NN:enable l2tp server=both
NN:add l2tp ip=1.1.1.1-255.255.255.254 ppptemplate=1
Т.е. клиент при подключении с компьютера должен авторизоватся по name и passvord при этом используя PSK. Никакие authentikation не применяются.

D-Link настраиваем следующим образом:
WAN
Type: Static IP
Далее настройки IP интерфейса
Firewall/VPN
Username: ***
password:***
remote gateway:x.x.x.x
remote net: x.x.x.x/30
authenticatio: no auth
NPPE encryption: none
Use IPsec enkryption V
PSK-Pre-Shared Key
Key:***
Все остальное выставляем по умолчанию.
К сожалению логи пока выложить нет возможности.
Ответьте пожалуйсто, правильно ли я настраиваю VPN в D-Link?

Если мне не изменяет память, то там могут быть грабли с разным восприятием строки preshared key - в одном случае это может быть строка, а в другом HEX. Вы на AT как ключ создавали, через cre enco key=1 type=gen val=0xHEX? Проверьте его значение по show enco Key=1

В AT ENCO configuration вообще пусто, вводил show enco Key=1 соответственно ключа нет. Но сконфигурен ключь в ISAKMP Configurations, вводил show enco Key=xxx соответственно ключ еcть.
Этот ключ вводят виндовые пользователи в своих настройках VPN соединения (Безопасность -> Параметры IPSec -> Ключ).
Возникает вопрос: смогут ли, конектится и внешние пользователи, и D-Link? И напишите пожалуйста поподробнее, как настроить AT. Просто я неспециалист по AT. Зарание благодарен.

Ну, естественно 1 в параметре "Key=1", это номер ключа, у Вас он может быть иной, так что Вы должны указать номер Вашего ключа.

Кроме того, 1) L2TP я у себя не конфигурил, пока не нужно. 2) статические туннели IPSEC/ISAKMP между 2-мя АТ работают без проблем. 3) Если не ошибаюсь, то я вроде тоже пытался "скрестить" DI-804 с АТ, но не получилось. Почему - уже не помню, т.к. это было в первые дни "знакомства" с АТ, так что может быть не получилось, т.к. был ещё чайником. Потом задача уже не понадобилась.

Из советов, если не получается - попробуйте в тестовых целях упростить задачу - например, сначала просто IPSEC/ISAKMP или даже IPSEC/Manual.

Про настройки - я для себя в процессе "познания" обычно записываю полезную инфу, что бы через год было проще вспомнить. Вот что у меня записано по АТ в части VPN:

VPN:
Генерация ключа и перенос его на другие роутеры
cre enco key=10 type=gen random
или
cre enco key=10 type=gen val=0xa1...skipped...38
show enco Key=10 (0xa1...skipped...38)

Диагностика конфигурации VPN

show ipsec pol
Проверяем наличие политик IPSec и !!! ИХ порядок !!! Роутер при обработке пакета перебирает политики "сверху вниз", то есть начиная с 0 (графа Position). Как только найдётся подходящая, он её и применит. То есть, если перед нужной политикой, описывающий IPSec тунель, стоит политика PERMIT для "прочего" интернет-трафика, то именно она и сработает и трафик пойдёт согласно ей без применения IPSec. При необходимости изменить порядок:

set ipsec pol=*** pos=*** - нумерация списка подряд, она изменится сразу автоматически, то есть если надо переместить политику снизу вверх с 5 на 2 надо писать pos=2, она вствится на это место, остальные подвинутся вниз.


show ip nat
Проверяем наличие NAT-записи для сети на другом конце тунеля. Не понял почему, но так и в примере мануала и по факту - без неё не работает. Дя этой записи можно даже GBLIP ставить любой - всё равно работает.


Диагностика работоспособности VPN

DISABLE ISAKMP
ENABLE ISAKMP
DISABLE IPSEC
ENABLE IPSEC
Краткое описание IPSec в варианте с ключами по ISAKMP.
1. Политика IPSec назначается для определённых логических интерфейсов и указывает, какое действие надо применить для каждого пакета, подходящего под задаваемый в этой же политике фильтр. В примере ниже в [скобках] сразу после параметра дан его комментарий:
create ipsec
pol=t31 [имя политики, для роутера ничего не значит, но не должно повторяться]
int=eth0 [интерфейс, на который назначается эта политика]
action=ipsec [действие, которое надо предпринять, если пакет подходит под фильтр политики: allow - пропустить без применения IPSec, deny - запретить, просто "выбросить" пакет из обработки без всяких реакций на него, ipsec - применить IPSec]
key=isakmp [режим выбора ключей: manual - ручной, isakmp - автоматически через ISAKMP]
bund=1 [ссылка на спецификацию параметров, cм.далее. Собственно именно отсюда "через 1 колено" следуют применяемые шифры и подписи аутентификации] peer=82.194.230.108 [противоположная точка туннеля]
[далее, собственно, начинается фильтр, который описывает те пакеты, к которым будет применено, то что описано ранее]
lad=10.2.1.0 lma=255.255.255.0 [локальный, то есть источник, адрес и маска пакетов, которые надо направлять в указанный туннель]
rad=10.3.1.0 rma=255.255.255.0 [удалённый, то есть назначение, адрес и маска пакетов, которые надо направлять в указанный туннель]

2. Политика IPSec обычно ссылается на 2 внешних "определения" - явно на bundle по его номеру и неявно на политику ISAKMP.
bundle - это определение возможных комбинаций и предпочтений протоколов инкапсуляции/шифрования ESP/DES,3DES,etc и аутентификации AH/MD5,SHA. Задаётся командой create ipsec bund=1 и состоит из строки, описывающей в порядке предпочтений комбинации элементарных SAS по их номерам. Эти SAS определяются, например, командой "create ipsec sas=1 key=isakmp prot=esp [протокол ESP или AH] enc=des [алгоритм шифрования] hasha=sha [алгоритм аутентификации пакета]".
Неявная ссылка на ISAKMP состоит в том, что требуемая политика выбирается роутером "самостоятельно" исходя из заданного интерфейса и PEER-а (противополодного конца туннеля).

3.

В некоторых ситуациях состояние SA на разных концах рассинхронизируется, особенно при перебоях со связью, перезагрузках и внесении изменений. В этом варианте есть смысл перезапустить службы. Но при удалённом управлении надо подумать чтобы не обрубить себе канал. При наличии транспортной политики IPSec между теми интерфейсами, с которого на который производится удалённое управление, можно попробовать:
1. отрубить IPSec (dis ipsec) сначала на удалённом роутере
2. после этого управление "упадёт", это нормально, т.к. произошло рассогласование политик между роутерами
3. затем отключить IPSec на своём роутере, теперь транспортная (как и любая другая) политика IPSec отменена на обоих концах.
4. "залогиниться " опять на удалённый роутер
5. включить "enable IPsec" на удалённом роутере, связь опять пропадёт
6. включить "enable IPsec" на своём роутере
7. наблюдать за согласованием ключей на обоих концах: show isakmp sa, show ipsec sa


show isakmp sa
show isakmp sa=***
Проверяем ISAKMP SA на обоих концах, можно просмотреть их детали Если ISAKMP не создаёт свои SA, то ковыряемся в DEBUG
enable isakmp debug=all (DISABLE ISAKMP DEBUG=ALL)

SHOW IPSEC SA
Проверяем наличие IPSec SA на обоих концах, смотрим соответствие именам туннелей (одному тунелю могут соотв. 2 SA), протоколов ESP, AH и "перекрёстное" соответствие SPI с другой стороной тунеля

SHOW IPSEC SA=***
здесь смотрим соответствие Mode, алгоритмов Encryption и Hash, перекрёстное соответствие сетей и PEER-ов (...tunnel IP...)

ENABLE IPSEC POLICY[=name] DEBUG=ALL
Если непонятки, то включаем отладку, вот пример нормальной работы тунеля для одно пакета 10.2.1.2->10.3.1.1 туда и обратно, после ## комментарии

## IPSec сообщает что фильтр по полю laddr - LocalAddress политики tun02 прошёл успешно - pass, и в следующей строке приводит собственно данные, которые он проверял, а именно ip и маску из политики (pol 10.2.1.0:255.255.255.0) и ip пакета (pkt 10.2.1.2)
IPSEC: filt: pass: laddr: pol tun02
pol 10.2.1.0:255.255.255.0, pkt 10.2.1.2

## тоже самое, но теперь уже для поля raddr - RemoteAddress
IPSEC: filt: pass: raddr: pol tun02
pol 10.3.1.0:255.255.255.0, pkt 10.3.1.1

## Ниже приводятся данные по пакету, принятому для обработки IPSec, а именно - имя политики, направление (OUT, IN), до обработки (pre processing) и после обработки (post processing). В строке IP приводится заголовок IP-пакета, в котором последние hex-числа это IP-адреса ("0a020102"=10.2.1.2, "0a030101"=10.3.1.1), далее приводятся названия и данные других вложенных протоколов. Это вошедший ещё не шифрованный пакет ICMP 10.2.1.2->10.3.1.1:
IPSEC tun02: 10: OUT: pre processing:
IP: 4500003c9cdc00007f0188dd0a0201020a030101
ICMP: 08005733
data: 0200f4286162636465666768696a6b6c6d6e6f7071727374757677616263646566676869

## Это уже зашифрованный и инкапсулированный в ESP пакет с Peer-адресами тунеля в IP-заголовке: "52c2xxxx52c2yyyy" - from 82.194.xx.xx -> 82.194.yy.yy
IPSEC tun02: 10: OUT: post processing:
IP: 45000070af61000040325c0552c2xxxx52c2yyyy
ESP: d6bdeecd0000038b:e9af7867555ee6ed3a79e733
data: d4a402b7472e1c9144d2b052b45f37f588261f974b0586cb90208e77d800849c7eb2c342
8dc72dcfa9324d316be2a777cd4b35d1abf570f66fa34a5e546664b078dbdfc604f0699a

## В этом месте на другой стороне тунеля происходит деинкапсуляция пакета и передача его получателю, затем получатель в ответ на него посылает новый ответный пакет, который опять инкапсулируется и вливается в тунель в направлении рассматриваемого сейчас конца.

## Это вернувшийся от получателя пакет, который только вошёл (IN) к нам из тунеля 82.194.yy.yy -> 82.194.xx.xx
IPSEC tun02: 10: IN: pre processing:
IP: 45000070d1e600003d323c8052c2yyyy52c2xxxx
ESP: fd5b93590000038b:bb48a070ff18bad4f30950ce
data: c80ba34a5417a4f7be581deec209c6caa0e8e7e21a5b70e0c7bd31eca10a1330495b7365
232838a94e12aa2de04e80e5632efa1dde4ad380b7c52438aa82d4de875de995931f6db9

## Это дешифрованный и деинкапсулированный пакет уже исходном формате ICMP 10.3.1.1->10.2.1.2 ("0301010a020102")
IPSEC tun02: 10: IN: post processing:
IP: 4500003c18d200007e010de80a0301010a020102
ICMP: 00005f33
data: 0200f4286162636465666768696a6b6c6d6e6f7071727374757677616263646566676869

## Это пример того, как через фильтр проходит пакет, который не подходит (filt: fail) под его критерии, он к нему не применяется данная (pol tun02) политика. Это не обязательно ошибка, такие пакеты тоже и могут и должны быть. В данном примере это пакет в "открытый интернет" и ему IPSec не нужен.
IPSEC: filt: fail: laddr: pol tun02
pol 10.2.1.0:255.255.255.0, pkt 81.95.xx.xx

Уважаемые Администраторы, понимаю, что мой ответ это 50% офф.топ. (в смысле, что не D-Linbk), но раз уж есть вопрос, то почему бы и не ответить...

Вот логи c D-Link/

[2006-01-09 13:50:18] <6>EFW: IPSEC: prio=1 Phase-1 [initiator] between ipv4(udp:500,[0..3]=169.254.28.64) and ipv4(udp:500,[0..3]=x.x.34.190) failed; Timeout.

[2006-01-09 13:49:25] <5>EFW: L2TP: event=l2tpclient_init iface=XZ remotegw=x.x.34.190

[2006-01-09 13:48:21] <5>EFW: L2TP: event=l2tpclient_init iface=XZ remotegw=x.x.34.190

[2006-01-09 13:47:17] <5>EFW: L2TP: event=l2tpclient_init iface=XZ remotegw=x.x.34.190

[2006-01-09 13:47:06] <6>EFW: IPSEC: prio=1 Phase-1 [initiator] between ipv4(udp:500,[0..3]=169.254.28.64) and ipv4(udp:500,[0..3]=x.x.34.190) failed; Timeout.

[2006-01-09 13:46:13] <5>EFW: L2TP: event=l2tpclient_init iface=XZ remotegw=x.x.34.190

[2006-01-09 13:45:09] <5>EFW: L2TP: event=l2tpclient_init iface=XZ remotegw=x.x.34.190

[2006-01-09 13:44:06] <5>EFW: SYSTEM: cfgfile=FWCore_N.cfg cfgver=35 bidir=ok (* см. сноску)

[2006-01-09 13:44:05] <5>EFW: L2TP: event=l2tpclient_init iface=XZ remotegw=x.x.34.190

[2006-01-09 13:44:03] <5>EFW: NETCON: event=init_complete

[2006-01-09 13:43:55] <5>EFW: SYSTEM: shutdown=RECONFIGURE time=7 reason="Configuration changed by admin (192.168.1.2)"

* В этот момент AT пишет в логе пишет

Exchange 92: Failed

Exchange 92: No proposal chosen

Exchange 92: MAIN Phase 1 [resp] started with peer x.x.33.66

IP WAN на D-Link x.x.33.66

Я никак понять не могу, откуда берется IP 169.254.28.64???
Когда захожу на D-Link Status -> interfaces -> IP интерфейса XZ 169.254.28.64
Откуда этот IP???
Знатоки D-Link подскажите пожалуйста.

Вот логи c D-Link/
[2006-01-09 13:50:18] <6>EFW: IPSEC: prio=1 Phase-1 [initiator] between ipv4(udp:500,[0..3]=169.254.28.64) and ipv4(udp:500,[0..3]=x.x.34.190) failed; Timeout.
[2006-01-09 13:49:25] <5>EFW: L2TP: event=l2tpclient_init iface=XZ remotegw=x.x.34.190
[2006-01-09 13:48:21] <5>EFW: L2TP: event=l2tpclient_init iface=XZ remotegw=x.x.34.190
[2006-01-09 13:47:17] <5>EFW: L2TP: event=l2tpclient_init iface=XZ remotegw=x.x.34.190
[2006-01-09 13:47:06] <6>EFW: IPSEC: prio=1 Phase-1 [initiator] between ipv4(udp:500,[0..3]=169.254.28.64) and ipv4(udp:500,[0..3]=x.x.34.190) failed; Timeout.
[2006-01-09 13:46:13] <5>EFW: L2TP: event=l2tpclient_init iface=XZ remotegw=x.x.34.190
[2006-01-09 13:45:09] <5>EFW: L2TP: event=l2tpclient_init iface=XZ remotegw=x.x.34.190
[2006-01-09 13:44:06] <5>EFW: SYSTEM: cfgfile=FWCore_N.cfg cfgver=35 bidir=ok (* см. сноску)
[2006-01-09 13:44:05] <5>EFW: L2TP: event=l2tpclient_init iface=XZ remotegw=x.x.34.190
[2006-01-09 13:44:03] <5>EFW: NETCON: event=init_complete
[2006-01-09 13:43:55] <5>EFW: SYSTEM: shutdown=RECONFIGURE time=7 reason="Configuration changed by admin (192.168.1.2)"

* В этот момент AT пишет в логе пишет

Exchange 92: Failed

Exchange 92: No proposal chosen

Exchange 92: MAIN Phase 1 [resp] started with peer x.x.33.66

IP WAN на D-Link x.x.33.66

Я никак понять не могу, откуда берется IP 169.254.28.64???
Когда захожу на D-Link Status -> interfaces -> IP интерфейса XZ 169.254.28.64
Откуда этот IP???
Знатоки D-Link подскажите пожалуйста.

169.254.0.0/16 - это зарезервированный диапазон Link Local. Применяется, например, win-дами в случае, если на интерфейсе назначено DHCP, а DHCP-сервер недоступен. Тогда windows "сама себе" назначает адрес из этого диапазона (3-ий и 4-ый байты она или случайно выбирает или генерит, возможно, исходя из имени хоста или МАС-адреса) и маской 255.255.0.0. Сделано для того, чтобы компы с настройкой DHCP, воткнутые в сеть без DHCP-сервера могли отконфигуриться самомтоятельно хотя бы для работы в локальной сети между собой.

Соотв. можно попробовать предположить, что у Вас на каком-то из интерфейсов отсутствует или несконфигурирован (не выделен пул или т.п.) DHCP-сервер.

Ввовдил команду show enco Key=xxx, ключ действительно есть. А как создавали не знаю, не я настраивал. Порты в firewalle все необходимые открыты, т. е. UDP 500 (для связи клиент - сервер) и UDP 1701 (точка - точка). Только вот я врубится не могу, почему AT один раз воспринимает D-Link, а потом игнорирует и D-Link в пустую долбится. Куда копать не пойму, но сегодня вечером попробую, точка - точка. Уважаемый v932, давайте я необходимые части конфига AT выложу, а вы посмотрите, может чего неправильно сконфигурино.

Ну попробуйте выложить, но тогда уж лучше, наверное, личным сообщением.

Если есть сомнение в ключе, то проверьте, именно он используется для IKE? Затем возьмите его значение из АТ через show enco Key=xxx и попробуйте вбить в D-Link. Или создайте новый ключ и используйте его...