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

[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