Най-вероятно линксиса не поддържа нат-т. Вероятно там където ти работи тунела, модема има 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 <[email protected]>: > Здрасти, > > Благодаря за отговора. > > Псевдоустройство не се създава по дизайн, така че съм го приел като > даденост. > 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<[email protected]>: >> >>> Здравейте, >>> >>> Опитвам са за изградя 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 >>> [email protected] >>> http://linux-bulgaria.org/mailman/listinfo/lug-bg >>> >>> >> _______________________________________________ >> Lug-bg mailing list >> [email protected] >> http://linux-bulgaria.org/mailman/listinfo/lug-bg >> > > _______________________________________________ > Lug-bg mailing list > [email protected] > http://linux-bulgaria.org/mailman/listinfo/lug-bg > _______________________________________________ Lug-bg mailing list [email protected] http://linux-bulgaria.org/mailman/listinfo/lug-bg
