Re: [Lug-bg] IPSec между Linksys BEFVP41 и линукс

[Kamen Medarski <kamedarski@xxxxxxxxx>]

Най-вероятно линксиса не поддържа нат-т. Вероятно там където ти работи
тунела, модема има ipsec passtrough и не се налага енкапсулация. Не
познавам това устройство, но ако поддържа GRE, може да пробваш. Или
другия вариант който се сетих е описан детайлно тук.
http://www.cyprotect.com/ssh/sentinel/SSH-Sentinel-1.4-Linksys.pdf
http://www.cyprotect.com/ssh/sentinel/SSH-Sentinel-1.4.0-User-Manual.pdf

Успех.

2010/3/9 Ico <ico@xxxxxxxxxx>:
> Здрасти,
>
> Благодаря за отговора.
>
> Псевдоустройство не се създава по дизайн, така че съм го приел като
> даденост.
> Itables не ми пречи (основно защото няма правила на машината на която
> тествам).
>
> БТК (Виваком де) се развиват и вече е възможно през уеб интерфейса им да
> се прави forward-ване не портове.
> Портове 500 и 4500 се използват за първата фаза (IKE) и затова се е
> наложило да ги пренасочваш (съответно без и при наличие на NAT).
>
> След известна борба стигнах до извода, че проблемите ми са два и ако
> реша поне един от тях ще се оправя:
>
> * NAT Traversal (NAT-T). Стигам до извода, че този Linksys не поддържа
> NAT-T (този факт е доста умело замаскиран в спецификациите им). Както
> написах и в първия мейл racoon-а и устройството договарят успешно
> параметрите на тунела, но нито един пакет не минава през него. При
> по-внимателни тестове установих, че се договаря само "истински" IPSEC,
> но не и NAT-T, съответно не се ползва encapsulate на пакетите през UDP.
> При никакви обстоятелства устройството не ще да договори NAT-T. Това,
> което се случва е, че линукса праща пакетите по IPSec протокол (номер
> 50) към ADSL модема, който отговаря с "protocol 50 unreachable"
>
> * NAT на IPSec протокола (тоя термин не е точен и вероятно е
> неправилен). За да работи тунела при горната схема ADLS - модема би
> трявало да се сети да forward-не съответните пакети към Linksys
> устройството. Но тук не става дума за портове, а за IP протокол. Това не
> можах да го поискам от поддръжката на Виваком, признавам си, че не знам
> точния термин, но и не можах да попадна на човек от поддръжката, които
> да разбере какво му искам.
>
> При предварителните ми тестове симулирах подобно нещо, като сложих
> модема зад линукс машина, която прави нат и всичко работеше. Интересното
> е, че не съм правил специално пренасочване от линукс-а. Изглежда по
> някакъв начин ядрото (може би модула conntrack) само се сеща да прави
> съответното пренасочване към линксис-а.
>
> Другото интересно, нещо което искам да споделя, е че горната ситуация е
> умножена по 4, като linksys-устройствата са в различни градове. В един
> от градовете тунела работи, в другите три се държи по разказания от мен
> начин. Там където работи отново не се договаря NAT-T.
>
> Ще съм благодарен за идеи.
> Ицо
>
>
>
> On 09.03.2010 13:28, Kamen Medarski wrote:
>> Здрасти Ицо,
>>
>> Преди години и на мен ми се наложи да изградя подобна на твоята
>> топология, с тази разлика че и от двете страни бяха линукси.
>> Проблемите които може да срещнеш не са един или два за жалост. Тъй
>> като беше доста отдавна спомените са малко избледнели, но да видим ...
>>
>> Това което първо трябва да ти кажа, че на мен ми се наложи на всички
>> адсл модеми които бяха в тази топология да ми foward-нат порт 4500 и
>> 500 (udp и/или tcp добавих и 22 и още един за всеки случай) към
>> машинките зад модемите. Нямах проблеми, отне ми време да ги убедя, но
>> в крайна сметка успях. Дори ако се поровя може  да намря и телефона но
>> който звънях. Това защо, обаче ми се наложи да направя това действие е
>> отмито безвъзвратно от времето.
>>
>> За да не гадая обаче, ако искаш позачисти си конфизите (racoon i
>> ipsectools.conf май че бяха)  и ги прати да ги видим.  Също се убеди
>> че iptables-a не ти пречи по никакъв начин на комуникацията. Прегледай
>> и рутингите.
>>
>> Сетих се нещо което беше ме отвратило малко от racoon-a тогава, а
>> именно проблема с рутирането на мрежите. Единственият начин да насочиш
>> комуникация през тунела беше с рулове в  ipsectools  конфига. Не се
>> създаваше псевдо устройство което може да манипулираш, дано сега да са
>> го оправили.
>>
>> Та това е което успях да изчета от тавана :)
>>
>> Действай и успех!
>>
>> 2010/2/18 Ico<ico@xxxxxxxxxx>:
>>
>>> Здравейте,
>>>
>>> Опитвам са за изградя IPSec VPN  между устройството Linksys BEFVP41 и
>>> линукс.
>>> Първо да кажа, че при тестова установка Linksys =>  NAT Device =>
>>> Internet =>  VPN Server връзката се изгражда без проблем.
>>>
>>> Проблемът възникна, когато сложих Linksys устройството там където
>>> наистина трябва да работи, а именно зад ADSL на БТК (Виваком).
>>> Това което се случва е, че устройството и racoon-а на линукса се
>>> договарят успешно - устройството казва, че тунелът е изграден, racoon-а
>>> също си създава необходимите полици, но през тунела нищо не минава и в
>>> двете посоки.
>>> При опит за ping от линукса през тунела се наблюдава следното:
>>>
>>> #tcpdump -i any -vn host 79.100.153.16
>>> tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture
>>> size 96 bytes
>>> 11:02:00.081267 IP (tos 0x0, ttl 64, id 34697, offset 0, flags [none],
>>> proto ESP (50), length 168)
>>>      212.116.143.142>  79.100.153.16: ESP(spi=0xc01a551e,seq=0x1e),
>>> length 148
>>> 11:02:00.114842 IP (tos 0xc0, ttl 57, id 10026, offset 0, flags [none],
>>> proto ICMP (1), length 196)
>>>      79.100.153.16>  212.116.143.142: ICMP 79.100.153.16 protocol 50
>>> unreachable, length 176
>>>          IP (tos 0x0, ttl 57, id 34697, offset 0, flags [none], proto
>>> ESP (50), length 168)
>>>      212.116.143.142>  79.100.153.16: ESP(spi=0xc01a551e,seq=0x1e),
>>> length 148[|icmp]
>>> 11:02:05.246955 IP (tos 0x0, ttl 142, id 24296, offset 0, flags [none],
>>> proto UDP (17), length 320)
>>>      79.100.153.16.500>  212.116.143.142.500: isakmp 1.0 msgid : phase 1
>>> I agg: [|sa]
>>> 11:02:05.344651 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
>>> UDP (17), length 300)
>>>      212.116.143.142.500>  79.100.153.16.500: isakmp 1.0 msgid : phase 1
>>> R agg: [|sa]
>>>
>>> Въпросите ме са два:
>>> 1. Някой има ли опит с подобно устройство, ако да открил ли е начин да
>>> го накара да ползва natt, защото аз не видях такова нещо в настройките
>>> му (в racoon.conf пише nat_traversal force, но това явно не е достатъчно) ?
>>> 2. Другата алтернатива, която виждам и да се убеди ADSL устройството да
>>> не спира ESP протокола, но при няколкото ми обаждания до съпорта не
>>> можах да попадна на човек с който да се разберем.
>>>
>>> Ще съм благодарен за коментари и насочвания.
>>>
>>> Поздрави,
>>> Ицо
>>>
>>> _______________________________________________
>>> Lug-bg mailing list
>>> Lug-bg@xxxxxxxxxxxxxxxxxx
>>> http://linux-bulgaria.org/mailman/listinfo/lug-bg
>>>
>>>
>> _______________________________________________
>> Lug-bg mailing list
>> Lug-bg@xxxxxxxxxxxxxxxxxx
>> http://linux-bulgaria.org/mailman/listinfo/lug-bg
>>
>
> _______________________________________________
> Lug-bg mailing list
> Lug-bg@xxxxxxxxxxxxxxxxxx
> http://linux-bulgaria.org/mailman/listinfo/lug-bg
>
_______________________________________________
Lug-bg mailing list
Lug-bg@xxxxxxxxxxxxxxxxxx
http://linux-bulgaria.org/mailman/listinfo/lug-bg