subject:"lug\-bg\: VPN "

Re: [Lug-bg] VPN server проблем с не достиг на PPP интерфейси

2009-01-19 Thread Georgi Genov

Tosho Yankov wrote:
Здравейте,
имам изграден и работещ ВПН сървар с pppoe и съответните настройки.
Всичко работеше прекрасно до един момент,когато клиентите станаха
по-голям брой. Открих едното от ограниченията и прекомплирах pppoe
сървъра и проблема се реши .. но временно. След известно време и
увеличване на клиентите отново се появи проблема, но вече не беше на
същото място.
Конкретно за какво говоря. Може би (това са мой предположения и
изследвания по поведението), ограничението е 128 tty/pts -та. когато
се стигне този лимит не могат да се закчат повече клиенти, като
включително и нови ssh сесии не могат да се изградят или пък вече
изградените, започват да бъдат дропвани.
Не знам дали няма да подведа в грешна посока, но ако ми дадете някаква
сламка как да открия къде е точно този лимит и дали мога да го
увелича, ще ви бъда много благодарен.
Опитах из гугъл, но за съжаление не открих някакъв пач или решение.
Благодаря предварително.

В .config-а на kernel-а дали ако пипнеш това CONFIG_LEGACY_PTY_COUNT=
няма да се оправят нещата?

___
Lug-bg mailing list
Lug-bg@linux-bulgaria.org
http://linux-bulgaria.org/mailman/listinfo/lug-bg

[Lug-bg] VPN server проблем с не достиг на PPP интерфейси

2009-01-13 Thread Tosho Yankov

Здравейте,
имам изграден и работещ ВПН сървар с pppoe
и съответните настройки. Всичко работеше прекрасно до един момент,когато
клиентите станаха по-голям брой. Открих едното от ограниченията и прекомплирах
pppoe сървъра и проблема се реши .. но временно. След известно време и
увеличване на клиентите отново се появи проблема, но вече не беше на същото
място.
Конкретно за какво говоря. Може би (това са мой предположения и изследвания по
поведението), ограничението е 128
tty/pts -та. когато се стигне този лимит не могат да се закчат повече клиенти,
като включително и нови ssh сесии не могат да се изградят или
пък вече изградените, започват да бъдат дропвани.
Не знам дали няма да подведа в грешна посока, но ако ми дадете някаква сламка
как да открия къде е точно този лимит и дали мога да го увелича, ще ви бъда
много благодарен.
Опитах из гугъл, но за съжаление не открих някакъв пач или решение.
Благодаря предварително.

___
Lug-bg mailing list
Lug-bg@linux-bulgaria.org
http://linux-bulgaria.org/mailman/listinfo/lug-bg

Re: lug-bg: VPN route problem

2006-08-01 Thread Kamen Medarski

И все пак ти препоръчвам да ползваш generate_policy on; в клаузата remote a.b.c.d { }

Re: lug-bg: VPN route problem

2006-08-01 Thread Stanimir Kabaivanov

Здравейте,И все пак ти препоръчвам да ползваш generate_policy on; в клаузата remote 
a.b.c.d { } 
Благодаря на всички за смислените отговори и за отделеното време. В крайна сметка се изясни какъв е проблема:След много мъки един колега ми даде идея да пусна nmap от десктоп машината (част от ЛАН-а) и от рутер-а (от който всичко работи). И леда се пропука:
- от рутер-а са достъпни всички услуги на въпросната отдалечена машина (портовете са отворени)- от десктоп ПС-то ми се оказа че има отворен един мижав 21 - фтп порт. За него изобщо не ми беше идвало на ума да пробвам дори.
Така или иначе имало е и външна намеса и са ми отразяли достъпа - става дума за отдалечения ЛАН и неговите политики за достъп.Бих искал и да се извиня на всички, че се наложи да ги занимавам с нещо толкова тривиално. Надявам се единствено, от постнатите дотук конфигурационни файлове и иптейбълс правила да може да се състави едно фак-че или поне някой да го ползва след време.
Поздрави,Станимир

lug-bg: VPN route problem

2006-07-31 Thread Stanimir Kabaivanov

Здравейте,Ще се опитам да бъда максимално кратък и ясен с проблема:VPN
установен с racoon и вградената подръжка на IPSec. От едната страна на
тунела стои gateway Федора 5, от другата Линукс съвместимо устройство.Тунела се изгражда успешно. Пинг работи от произволна машина на едната мрежа към произволна машина на другата мрежа (и обратно).
Проблема е, че:1. Пинг и всякакви заявки вървят успешно от Федората към машини на другата мрежа.2. ЕДИНСТВЕНО пинг работи от машини стоящи зад Федората към машини на другата мрежа.Според мен проблема е в настройките на на iptables и route, а не е свързан с MTU. Но не мога да разбера какво точно пропускам:
Настройки на iptables:$LOCAL_GW - wuprosnata Fedora$REMOTE_GW - wuprosnoto Linux suwmestimo ustrojstwo192.168.x.0/23 - remote LAN192.168.y.0/24 - local LAN# Generated by iptables-save v1.3.5
 on Thu Jul 27 18:11:01 2006*mangle:PREROUTING ACCEPT [953:662425]:INPUT ACCEPT [859:646970]:FORWARD ACCEPT [94:15455]:OUTPUT ACCEPT [920:161181]:POSTROUTING ACCEPT [1014:176636]-A PREROUTING -i eth0 -p ipv6-crypt -j MARK --set-mark 0x1 
COMMIT# Completed on Thu Jul 27 18:11:01 2006# Generated by iptables-save v1.3.5 on Thu Jul 27 18:11:01 2006*nat:PREROUTING ACCEPT [69:5073]:POSTROUTING ACCEPT [66:4168]:OUTPUT ACCEPT [54:3554]
-A PREROUTING -m state --state RELATED,ESTABLISHED -j ACCEPT -A PREROUTING -s 192.168.x.0/255.255.254.0 -i eth0 -m mark --mark 0x1 -j ACCEPT -A POSTROUTING -s 192.168.y.0/255.255.255.0 -d ! 192.168.x.0/255.255.254.0 -o eth0 -j MASQUERADE 
COMMIT# Completed on Thu Jul 27 18:11:01 2006# Generated by iptables-save v1.3.5 on Thu Jul 27 18:11:01 2006*filter:INPUT ACCEPT [33:6591]:FORWARD DROP [0:0]:OUTPUT ACCEPT [841:137877]:RH-Firewall-1-INPUT - [0:0]
-A INPUT -s $REMOTE_GW -d $LOCAL_GW -i eth0 -p udp -m udp --sport 500 --dport 500 -j ACCEPT -A INPUT -s $REMOTE_GW -d $LOCAL_GW -i eth0 -p tcp -m tcp --sport 500 --dport 500 -j ACCEPT -A INPUT -s $REMOTE_GW -d $LOCAL_GW -i eth0 -p ipv6-auth -j ACCEPT 
-A INPUT -s $REMOTE_GW -d $LOCAL_GW -i eth0 -p ipv6-crypt -j ACCEPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT -A INPUT -i eth0 -p udp -m udp --dport 500 -j ACCEPT 
-A INPUT -i eth0 -m mark --mark 0x1 -j ACCEPT -A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT -A FORWARD -i eth1 -o eth0 -j ACCEPT -A FORWARD -j LOG -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A FORWARD -i eth0 -m mark --mark 0x1 -j ACCEPT -A FORWARD -i eth1 -j ACCEPT -A OUTPUT -s $LOCAL_GW -d $REMOTE_GW -o eth0 -p udp -m udp --sport 500 --dport 500 -j ACCEPT -A OUTPUT -s $LOCAL_GW -d $REMOTE_GW -o eth0 -p tcp -m tcp --sport 500 --dport 500 -j ACCEPT 
-A OUTPUT -s $LOCAL_GW -d $REMOTE_GW -o eth0 -p ipv6-auth -j ACCEPT -A OUTPUT -s $LOCAL_GW -d $REMOTE_GW -o eth0 -p ipv6-crypt -j ACCEPT -A RH-Firewall-1-INPUT -i lo -j ACCEPT -A RH-Firewall-1-INPUT -p icmp -m icmp --icmp-type any -j ACCEPT 
-A RH-Firewall-1-INPUT -p ipv6-crypt -j ACCEPT -A RH-Firewall-1-INPUT -p ipv6-auth -j ACCEPT -A RH-Firewall-1-INPUT -d 224.0.0.251 -p udp -m udp --dport 5353 -j ACCEPT -A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT 
-A RH-Firewall-1-INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 21 -j ACCEPT -A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT 
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT -A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 139 -j ACCEPT -A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 445 -j ACCEPT 
-A RH-Firewall-1-INPUT -p udp -m state --state NEW -m udp --dport 137 -j ACCEPT -A RH-Firewall-1-INPUT -p udp -m state --state NEW -m udp --dport 138 -j ACCEPT -A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 145 -j ACCEPT 
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited COMMIT# Completed on Thu Jul 27 18:11:01 2006Пътища:r.e.m. - remote GWl.o.c. - local GWKernel IP routing table
Destination   Gateway Genmask Flags Metric Ref  Use Ifacel.o.c.0  *255.255.255.0  U   0   00 eth0192.168.y.0  *  
255.255.255.0  U   0   00 eth1192.168.x.0   localGW . 255.255.254.0  UG  0   00 eth0
169.254.0.0   * 255.255.0.0   U   0   00 eth1default localGW  0.0.0.0 UG  0   00 eth0Направих и следния опит, за да проверя къде е проблема:
пуснах tcpdump в отделни конзоли за eth1 (локална мрежа 192.168.y.0/24) и за eth0 - връзката с кабелния модем и интернет. Резултата леко ме изненада:При опит за ssh към сървър от remote LAN-а заявката ми умира още на eth1, като получавам съобщение ICMP host unreachable. Същевременно изходящ трафик в дъмп-а на eth0 няма. Което ме навежда на мисълта, че наистина не е MTU проблем а глупава пропусната настройка на моя линукс gateway
Предварително благодаря!

Re: lug-bg: VPN route problem

2006-07-31 Thread Georgi Chorbadzhiyski

Stanimir Kabaivanov wrote:
 пуснах tcpdump в отделни конзоли за eth1 (локална мрежа 192.168.y.0/24) и за
 eth0 - връзката с кабелния модем и интернет. Резултата леко ме изненада:
 
 При опит за ssh към сървър от remote LAN-а заявката ми умира още на eth1,
 като получавам съобщение ICMP host unreachable. Същевременно изходящ трафик
 в дъмп-а на eth0 няма. Което ме навежда на мисълта, че наистина не е MTU
 проблем а глупава пропусната настройка на моя линукс gateway
 
 Предварително благодаря!

Според мен нямаш проблем с рутиранете, а с това че Fedora-та не препраща пакети,
тоест не е рутер.

cat /proc/sys/net/ipv4/ip_forward

Трябва да ти върне 1, инче е точно каквото предполагам.

За да го оправиш, добави в /etc/sysctl.conf

net.ipv4.ip_forward=1

и стартирай sysctl -w net.ipv4.ip_forward=1

-- 
Georgi Chorbadzhiyski
http://georgi.unixsol.org/

Re: lug-bg: VPN route problem

2006-07-31 Thread Georgi Chorbadzhiyski

Georgi Chorbadzhiyski wrote:
 Stanimir Kabaivanov wrote:
 пуснах tcpdump в отделни конзоли за eth1 (локална мрежа 192.168.y.0/24) и за
 eth0 - връзката с кабелния модем и интернет. Резултата леко ме изненада:

 При опит за ssh към сървър от remote LAN-а заявката ми умира още на eth1,
 като получавам съобщение ICMP host unreachable. Същевременно изходящ трафик
 в дъмп-а на eth0 няма. Което ме навежда на мисълта, че наистина не е MTU
 проблем а глупава пропусната настройка на моя линукс gateway

 Предварително благодаря!
 
 Според мен нямаш проблем с рутиранете, а с това че Fedora-та не препраща 
 пакети,
 тоест не е рутер.
 
 cat /proc/sys/net/ipv4/ip_forward
 
 Трябва да ти върне 1, инче е точно каквото предполагам.
 
 За да го оправиш, добави в /etc/sysctl.conf
 
 net.ipv4.ip_forward=1
 
 и стартирай sysctl -w net.ipv4.ip_forward=1

И извинения за неграмотното писмо, дано си ме разбрал (note to me, не пиши преди
да си се събудил...)

-- 
Georgi Chorbadzhiyski
http://georgi.unixsol.org/

Re: lug-bg: VPN route problem

2006-07-31 Thread Stanimir Kabaivanov

Здравейте,Stanimir Kabaivanov wrote: пуснах tcpdump в отделни конзоли за eth1 (локална мрежа 
192.168.y.0/24) и за eth0 - връзката с кабелния модем и интернет. Резултата леко ме изненада: При опит за ssh към сървър от remote LAN-а заявката ми умира още на eth1, като получавам съобщение ICMP host unreachable. Същевременно изходящ трафик
 в дъмп-а на eth0 няма. Което ме навежда на мисълта, че наистина не е MTU проблем а глупава пропусната настройка на моя линукс gateway Предварително благодаря!Според мен нямаш проблем с рутиранете, а с това че Fedora-та не препраща пакети,
тоест не е рутер.cat /proc/sys/net/ipv4/ip_forwardТрябва да ти върне 1, инче е точно каквото предполагам.За да го оправиш, добави в /etc/sysctl.confnet.ipv4.ip_forward=1
и стартирай sysctl -w net.ipv4.ip_forward=1ip_forward-а ми е включен (т.е. on / 1). В /etc/sysctl.conf си е установен на 1-ца. Опитах да го ресет-на като го изключа и включва отново но резултата е без промяна - нямам достъп до отдалечения лан, освен пинг и трейсруут (ВинХП машина от моя лан).

Re: lug-bg: VPN route problem

2006-07-31 Thread Stanimir Kabaivanov

И извинения за неграмотното писмо, дано си ме разбрал (note to me, не пиши предида си се събудил...)
Няма проблеми :). Аз не съм спал от 1 седмица  заради проклетия ВПН :). Засега го ползвам от gateway-а но все ме гризе отвътре :-)

Re: lug-bg: VPN route problem

2006-07-31 Thread Kamen Medarski

Защо за всеки случай не пратиш и съдържанието на полиситата?

Re: lug-bg: VPN route problem

2006-07-31 Thread Stanimir Kabaivanov

С удоволствие:/etc/racoon.conf# Racoon IKE daemon configuration file.# See 'man racoon.conf' for a description of the format and entries.path include /etc/racoon;path pre_shared_key /etc/racoon/psk.txt;
path certificate /etc/racoon/certs;timer{ counter 5; # maximum trying count to send. interval 30 sec; # maximum interval to resend. persend 1; # the number of packets per a send.
 phase1 80 sec; phase2 85 sec;}#ZyWallremote q.w.e.r{ exchange_mode main,aggressive,base; lifetime time 24 hour; proposal_check=obey; nat_traversal on;
 esp_frag 552; proposal { encryption_algorithm 3des; hash_algorithm sha1; authentication_method pre_shared_key; dh_group 1; }}#net-to-netsainfo address 192.168.y.0
/24 any address 192.168.x.0/23 any{ lifetime time 1 hour; encryption_algorithm 3des; authentication_algorithm hmac_sha1,hmac_md5; compression_algorithm deflate;}sainfo anonymous
{ lifetime time 1 hour ; encryption_algorithm 3des, blowfish 448, rijndael ; authentication_algorithm hmac_sha1,hmac_md5 ; compression_algorithm deflate ;}и съответно setkey.sh
:#/sbin/setkey -f#flushsetkey -FPsetkey -F#LOCAL_EXT_IP - Internet IP of eth0 - my gatewayLOCAL_EXT_IP=a.b.c.d#REMOTE_EXT_IP - Internet IP of remote VPN gatewayREMOTE_EXT_IP=q.w.e.r
LOCAL_LAN=192.168.y.0LOCAL_SUBNET_MASK=24REMOTE_LAN=192.168.x.0REMOTE_SUBNET_MASK=23#Linux-racoon - MyZwall and MyZwall - Linux-racoonsetkey -c  ENDspdadd $REMOTE_EXT_IP $LOCAL_EXT_IP any -P in ipsec esp/tunnel/$REMOTE_EXT_IP-$LOCAL_EXT_IP/unique;
spdadd $REMOTE_LAN/$REMOTE_SUBNET_MASK $LOCAL_LAN/$LOCAL_SUBNET_MASK any -P in ipsec esp/tunnel/$REMOTE_EXT_IP-$LOCAL_EXT_IP/unique;spdadd $LOCAL_EXT_IP $REMOTE_EXT_IP any -P out ipsec esp/tunnel/$LOCAL_EXT_IP-$REMOTE_EXT_IP/unique;
spdadd $LOCAL_LAN/$LOCAL_SUBNET_MASK $REMOTE_LAN/$REMOTE_SUBNET_MASK any -P out ipsec esp/tunnel/$LOCAL_EXT_IP-$REMOTE_EXT_IP/unique;END#here comes the shitty part with iptablesiptables -A INPUT -p udp -s $REMOTE_EXT_IP -d $LOCAL_EXT_IP --dport 500 --j ACCEPT
iptables -A INPUT -p udp -s $REMOTE_EXT_IP -d $LOCAL_EXT_IP --dport 4500 --j ACCEPTiptables -A INPUT -p esp -s $REMOTE_EXT_IP -d $LOCAL_EXT_IP -j ACCEPTiptables -A INPUT -p ah -s $REMOTE_EXT_IP -d $LOCAL_EXT_IP -j ACCEPT
iptables -A INPUT -p udp -s $REMOTE_EXT_IP -d $LOCAL_EXT_IP --dport 50 --j ACCEPTiptables -A INPUT -p tcp -s $REMOTE_EXT_IP -d $LOCAL_EXT_IP --dport 50 --j ACCEPTiptables -A INPUT -p tcp -s $REMOTE_EXT_IP -d $LOCAL_EXT_IP --dport 80 --j ACCEPT
#now the same with outputiptables -A OUTPUT -p udp -d $REMOTE_EXT_IP -s $LOCAL_EXT_IP --sport 500 --j ACCEPTiptables -A OUTPUT -p udp -d $REMOTE_EXT_IP -s $LOCAL_EXT_IP --sport 4500 --j ACCEPTiptables -A OUTPUT -p esp -d $REMOTE_EXT_IP -s $LOCAL_EXT_IP -j ACCEPT
iptables -A OUTPUT -p ah -d $REMOTE_EXT_IP -s $LOCAL_EXT_IP -j ACCEPTiptables -A OUTPUT -p udp -d $REMOTE_EXT_IP -s $LOCAL_EXT_IP --sport 50 --j ACCEPTiptables -A OUTPUT -p tcp -d $REMOTE_EXT_IP -s $LOCAL_EXT_IP --sport 50 --j ACCEPT
iptables -A OUTPUT -p tcp -d $REMOVE_EXT_IP -s $LOCAL_EXT_IP --sport 80 --j ACCEPT#if we use masqueradeiptables -t nat -I POSTROUTING 1 -p 50 -j ACCEPTip route add 192.168.x.0/23 via $LOCAL_EXT_IP src 
192.168.y.1Този последния скрипт, за момента го пускам ръчно (все пак съм в период на тестване) преди да пусна самия ракуун с racoon -F -v.T.e. пълната последователност за установяване на тунела е:
$/etc/racoon/setkey.sh$racoon -F -vOn 7/31/06, Kamen Medarski [EMAIL PROTECTED] wrote:
Защо за всеки случай не пратиш и съдържанието на полиситата?

Re: lug-bg: VPN route problem

2006-07-31 Thread Kamen Medarski

Малко е много информацията която си пратил и ще трябва време за да се прегледа .. но да попитам на двете машини командата setkey -D i stekey -DP дали съвпадат със зададените от теб правила?

Re: lug-bg: VPN route problem

2006-07-31 Thread Stanimir Kabaivanov

Здравейте,Гледах да е възможно по-пълна :). Дано не е много и страничния боклук, покрай ценната информация.Проблема е, че отсрещната страна е IPSec съвместимо устройство на ZyWall и не мога директно да лист-на setkey -D(P). Но от това което се вижда от уеб базираните му настройки правилата са идентични.
А всъщност цялата работа не опира ли до липсващ път? Поне от tcpdump-a оставам с впечатление, че умирам още на вътрешната eth1 и не стигам до тунела изобщоOn 7/31/06, 
Kamen Medarski [EMAIL PROTECTED] wrote:
Малко е много информацията която си пратил и ще трябва време за да се прегледа .. но да попитам на двете машини командата setkey -D i stekey -DP дали съвпадат със зададените от теб правила?

Re: lug-bg: VPN route problem

2006-07-31 Thread Kamen Medarski

On 7/31/06, Stanimir Kabaivanov [EMAIL PROTECTED] wrote:
Здравейте,Гледах да е възможно по-пълна :). Дано не е много и страничния боклук, покрай ценната информация.Проблема е, че отсрещната страна е IPSec съвместимо устройство на ZyWall и не мога директно да лист-на setkey -D(P). Но от това което се вижда от уеб базираните му настройки правилата са идентични.
А всъщност цялата работа не опира ли до липсващ път? Поне от tcpdump-a оставам с впечатление, че умирам още на вътрешната eth1 и не стигам до тунела изобщо
On 7/31/06, 
Kamen Medarski [EMAIL PROTECTED] wrote:

Малко е много информацията която си пратил и ще трябва време за да се прегледа .. но да попитам на двете машини командата setkey -D i stekey -DP дали съвпадат със зададените от теб правила?

Ами липсващия път може да се получи при неправилно описани полици на тунела. А нещо необичайно из логовете да има? Питам защото си мисля че тунела не се инициализира коректно, ти се опитваш да пуснеш конфигурация road-worrior обаче до колкото си спомням там в конфигурационния файл би трябвало да има само anonymous police в sa database и клауза generate police=on, обаче при теб виждам описан и отаделчен хост зададен статично. Така, че те съветвам да попрегедаш МАНУЕЛА :-) на това устройство отностно конфигурацията, или още един източник на примери може да е /usr/share/racoon там, мисля че има примерни конфигурационни файлове които може да ти бъдат от полза.

Re: lug-bg: VPN route problem

2006-07-31 Thread Nickola Kolev

Здравей,

On Mon, 31 Jul 2006 11:21:26 +0300
Stanimir Kabaivanov [EMAIL PROTECTED] wrote:

[ кръц ]
 #Linux-racoon - MyZwall and MyZwall - Linux-racoon
 setkey -c  END
 spdadd $REMOTE_EXT_IP $LOCAL_EXT_IP any -P in ipsec
 esp/tunnel/$REMOTE_EXT_IP-$LOCAL_EXT_IP/unique;
 spdadd $REMOTE_LAN/$REMOTE_SUBNET_MASK $LOCAL_LAN/$LOCAL_SUBNET_MASK
 any -P in ipsec esp/tunnel/$REMOTE_EXT_IP-$LOCAL_EXT_IP/unique;
 spdadd $LOCAL_EXT_IP $REMOTE_EXT_IP any -P out ipsec
 esp/tunnel/$LOCAL_EXT_IP-$REMOTE_EXT_IP/unique;
 spdadd $LOCAL_LAN/$LOCAL_SUBNET_MASK $REMOTE_LAN/$REMOTE_SUBNET_MASK
 any -P out ipsec esp/tunnel/$LOCAL_EXT_IP-$REMOTE_EXT_IP/unique;
 END
[ кръц ]

Тук би ли могъл да добавиш нещо от сорта на:

spdadd $LOCAL_LAN/$LOCAL_SUBNET_MASK $REMOTE_LAN/$REMOTE_SUBNET_MASK
any -P fwd ipsec esp/tunnel/$LOCAL_EXT_IP-$REMOTE_EXT_IP/require;


[ кръц ]
 iptables -t nat -I POSTROUTING 1 -p 50 -j ACCEPT
 ip route add 192.168.x.0/23 via $LOCAL_EXT_IP src 192.168.y.1
[ кръц ]

Тук наистина ли искаш да маскираш всичко, което минава през тунела, с
локален IP адрес?

-- 
Поздрави,
Никола


pgpEzZXCFY3di.pgp
Description: PGP signature

Re: lug-bg: VPN route problem

2006-07-31 Thread Stanimir Kabaivanov

Здравей,Тук би ли могъл да добавиш нещо от сорта на:spdadd $LOCAL_LAN/$LOCAL_SUBNET_MASK $REMOTE_LAN/$REMOTE_SUBNET_MASK
any -P fwd ipsec esp/tunnel/$LOCAL_EXT_IP-$REMOTE_EXT_IP/require;След като го добавя това губя всякаква връзка между ПС-тата от локалната ЛАН и отдалечената ЛАН. Дори пинг и трейс спряха да работят.
Аналогична е сигуацията когато горното правило е:а) добавено към останалитеб) out в ЛАН/ЛАН правилото е заменено с fwd
[ кръц ] iptables -t nat -I POSTROUTING 1 -p 50 -j ACCEPT ip route add 192.168.x.0/23 via $LOCAL_EXT_IP src 192.168.y.1[ кръц ]Тук наистина ли искаш да маскираш всичко, което минава през тунела, с
локален IP адрес?Ами ако не го направя няма как да изпращам по тунела.

Re: lug-bg: VPN Routing

2006-01-20 Thread Kamen Medarski

За съжаление и мен тези подробност ме притесняваха ... но си мислех, че все 
има начин.
А вие как мислите ... дали има вероятност през такъв ipsec тунел да се прекара 
GRE или ip-ip или подобен тунел, през който вече да се рутира подбна схема?

lug-bg: VPN Routing

2006-01-18 Thread Kamen Medarski

Здравийте група, имам една ситуация в която малко съм се оплел и немога да 
намеря подходящ метод за решаването й, така  че моля за малко помощ. Става 
въпрос за VPN tunnels изградени на базата на Racoon i IPSec. Полоситата които 
съм задал на на машините са например следните:
Тунел 1:
remote eth1 192.168.1.0/24-192.168.0.0/24  vlan_vpn
Тунел 2:
remote eth1 192.168.2.0/24-192.168.0.0/24 vlan_vpn
Тунел3:
remote eth1 192.168.3.0/24-192.168.0.0/24  vlan_vpn

Идеята е следната, на сървъра има още един интерфейс, например eth2 
10.0.0.1/24, от машина в тази локална за сървъра мрежа е необходимо да се 
рутира трафика през ВПН-а до машина от всяка една от отдалечените мрежи. т.е. 
машина с ip 10.0.0.2 да пинг-ва 192.168.1.2, 192.168.2.2 и 192.168.3.2, 
например. 

Пробвах следното нещо:

ip r a 192.168.1.0/24 via 192.168.0.1 dev vlan_vpn
също и:
echo 3 VPN /etc/iproute2/rt_tables
ip rule add from 10.0.0.2 table VPN

ip r a 192.168.1.0/24 via 192.168.0.1 dev vlan_vpn table VPN

резултата от тези няколко реда е, че от сървъра пинга достига до отдалечената 
машина, но от 10.0.0.2 не!

Моля Ви за предложение, а то се подразбира че ако проработи ще почерпя :)

Салют!

Re: lug-bg: VPN Routing

2006-01-18 Thread Nickola Kolev

Здрасти,

Трябва да включиш в политиките си и мрежата 10.0.0.0/24. Нормално е през
ipsec тунелите да не минава нищо друго, освен мрежите, които си описал.

Поздрави,
Никола

Kamen Medarski wrote:
[ кръц ]

 
 Моля Ви за предложение, а то се подразбира че ако проработи ще почерпя :)
 
 Салют!

Re: lug-bg: VPN Routing

2006-01-18 Thread Nickola Kolev

Здрасти,

Бих опитал, ако не бях толкова зле запознат с теорията зад IPSec като
цяло. Това с рутинга и липсата на създаване на интерфейси между другото,
е една от причините, които Весо Колев изтъкна като недостатъци на тази
имплементация (говоря за нативно включената в linux 2.6).
При strong/openswan си има ipsec0/1/2 и т.н. Там обаче също важи
политиката, че ако не си описал нещо, което искаш да минава през даден
тунел, то просто няма да мине от там, без значение какъв е рутинга. Ако
ти трябват интерфейси, CRL функционалности и още доста неща, май това е
пътят.

Поздрави,
Никола

На Wed, Jan 18, 2006 at 09:41:50PM +0200, Vasil Kolev писа:
[ кръц ]
 : Някой добър човек ще даде ли добро обяснение за тия ipsec тунели, че по
 : принцип с нормалните инструменти ни routing-а им се вижда, ни нищо, та е
 : ужасно объркващо..




signature.asc
Description: Digital signature

Re: lug-bg: VPN with LinkSys WRV54G and Linux

2005-09-19 Thread Yulian Stefanov

Не беше ли с PPTP (mppe/mppc), или се бъркам модела???

 - Писмо от [EMAIL PROTECTED] -
 Дата: Wed, 14 Sep 2005 13:48:17 +0300
  Подател: [EMAIL PROTECTED]
 Отговор-До:lug-bg@linux-bulgaria.org
  Относно: lug-bg: VPN with LinkSys WRV54G and Linux
 Получател:lug-bg lug-bg@linux-bulgaria.org



 Здравейте,
 някой правил ли е VPN тунел между 2 мрежи с 2 рутъра
 - от едната страна на тунела LinkSys WRV54G  и Линукс от
 другата?
 Ако да - интересува ме какво може да се използва на Линукс
 рутъра.

 Доколкото подразбрах в LinkSys WRV54G за VPN се използва
 FreeSwan та се чудя ако сложа и на линукса FreeSwan дали ще
 мога да организирам VPN тунела между мрежите.
 До колкото знам обаче freeSwan вече не се разработва и не
 знам дали не мога да го заместя с нещо друго. Проблема е,
 че тоя WRV54G не е при мене за да го пробвам и затова питам
 за менение...
 Благодаря предварително.
 Митко



 --
 Безплатната поща в mail.bg вече е 1GB!




 - Край на писмото от [EMAIL PROTECTED] -



--
Best Regards,
Yulian Stefanov
[EMAIL PROTECTED]
+359885161535



--
Безплатната поща в mail.bg вече е 1GB!

Re: lug-bg: VPN with LinkSys WRV54G and Linux

2005-09-15 Thread Vladimir Gerdjikov

Не съм правил такова нещо (точно с LynkSys), но лебеда не е умрял :)
Има http://www.openswan.org/ и http://www.strongswan.org/
Материали в мрежта има колкото щеш...

[EMAIL PROTECTED] wrote:

Здравейте,
някой правил ли е VPN тунел между 2 мрежи с 2 рутъра
- от едната страна на тунела LinkSys WRV54G  и Линукс от
другата?
Ако да - интересува ме какво може да се използва на Линукс
рутъра.

Доколкото подразбрах в LinkSys WRV54G за VPN се използва
FreeSwan та се чудя ако сложа и на линукса FreeSwan дали ще
мога да организирам VPN тунела между мрежите.
До колкото знам обаче freeSwan вече не се разработва и не
знам дали не мога да го заместя с нещо друго. Проблема е,
че тоя WRV54G не е при мене за да го пробвам и затова питам
за менение...
Благодаря предварително.
Митко

  

-- 
Best regards,

Vladimir Gerdjikov
 ... and may the source be with you ...

lug-bg: VPN with LinkSys WRV54G and Linux

2005-09-14 Thread xm4o



Здравейте,
някой правил ли е VPN тунел между 2 мрежи с 2 рутъра
- от едната страна на тунела LinkSys WRV54G  и Линукс от
другата?
Ако да - интересува ме какво може да се използва на Линукс
рутъра.

Доколкото подразбрах в LinkSys WRV54G за VPN се използва
FreeSwan та се чудя ако сложа и на линукса FreeSwan дали ще
мога да организирам VPN тунела между мрежите.
До колкото знам обаче freeSwan вече не се разработва и не
знам дали не мога да го заместя с нещо друго. Проблема е,
че тоя WRV54G не е при мене за да го пробвам и затова питам
за менение...
Благодаря предварително.
Митко



--
Безплатната поща в mail.bg вече е 1GB!

lug-bg: vpn and ipchains masquerade

2005-06-03 Thread Martin Kolev

,

( ) 
  VPN  Ipchains.

 ,   
 Debian, Kernel 2.2.19  VPN
 .

 (  
, -  )

  :
   VPN  ()IP ,
Ipchains (ipchans -I forward -i eth1
-s 192.168.0.3 -j MASQ).


Jun  1 23:45:31 pptpd[22881]: MGR: Manager process started
Jun  1 23:45:54 pptpd[22889]: MGR: Launching /usr/sbin/pptpctrl to handle
client
Jun  1 23:45:54 pptpd[22889]: CTRL: local address = 192.168.1.253
Jun  1 23:45:54 pptpd[22889]: CTRL: remote address = 192.168.1.1
Jun  1 23:45:54 pptpd[22889]: CTRL: pppd speed = 115200
Jun  1 23:45:54 pptpd[22889]: CTRL: pppd options file =
/etc/ppp/pptpd-options
Jun  1 23:45:54 pptpd[22889]: CTRL: Client 84.43.XXX.XXX control connection
started
Jun  1 23:45:54 pptpd[22889]: CTRL: Received PPTP Control Message (type: 1)
Jun  1 23:45:54 pptpd[22889]: CTRL: Made a START CTRL CONN RPLY packet
Jun  1 23:45:54 pptpd[22889]: CTRL: I wrote 156 bytes to the client.
Jun  1 23:45:54 pptpd[22889]: CTRL: Sent packet to client
Jun  1 23:45:54 pptpd[22889]: CTRL: Received PPTP Control Message (type: 7)
Jun  1 23:45:54 pptpd[22889]: CTRL: 0 min_bps, 1525 max_bps, 32 window size
Jun  1 23:45:54 pptpd[22889]: CTRL: Made a OUT CALL RPLY packet
Jun  1 23:45:54 pptpd[22889]: CTRL: Starting call (launching pppd, opening
GRE)
Jun  1 23:45:54 pptpd[22889]: CTRL: pty_fd = 5
Jun  1 23:45:54 pptpd[22889]: CTRL: tty_fd = 6
Jun  1 23:45:54 pptpd[22889]: CTRL: I wrote 32 bytes to the client.
Jun  1 23:45:54 pptpd[22890]: CTRL (PPPD Launcher): Connection speed =
115200
Jun  1 23:45:54 pptpd[22890]: CTRL (PPPD Launcher): local address =
192.168.1.253
Jun  1 23:45:54 pptpd[22890]: CTRL (PPPD Launcher): remote address =
192.168.1.1
Jun  1 23:45:54 pptpd[22889]: CTRL: Sent packet to client
Jun  1 23:45:54 pppd[22890]: pppd 2.4.1 started by root, uid 0
Jun  1 23:45:54 pppd[22890]: Using interface ppp1
Jun  1 23:45:54 pppd[22890]: Connect: ppp1 -- /dev/pts/2
Jun  1 23:45:54 pptpd[22889]: CTRL: Received PPTP Control Message (type: 15)
Jun  1 23:45:54 pptpd[22889]: CTRL: Got a SET LINK INFO packet with standard
ACCMs
Jun  1 23:45:54 pptpd[22889]: Missing 12 consecutive packets; got 1728 after
4294967295
Jun  1 23:46:24 pptpd[22881]: MGR: Reaped child 22889
Jun  1 23:46:24 pptpd[22889]: Error reading from pppd: Input/output error
Jun  1 23:46:24 pptpd[22889]: CTRL: GRE read or PTY write failed
(gre,pty)=(6,5)
Jun  1 23:46:24 pptpd[22889]: CTRL: Client 84.43.XXX.XXX control connection
finished
Jun  1 23:46:24 pptpd[22889]: CTRL: Exiting now
Jun  1 23:46:24 pppd[22890]: LCP: timeout sending Config-Requests
Jun  1 23:46:24 pppd[22890]: Connection terminated.
Jun  1 23:46:24 pppd[22890]: Exit.




   .
 

 




A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers).
http://www.linux-bulgaria.org - Hosted by Internet Group Ltd. - Stara Zagora
To unsubscribe: http://www.linux-bulgaria.org/public/mail_list.html

91 matches

Mail list logo