Re: lug-bg: iptables masquerade problem

2005-07-31 Thread Dragomir Zhelev

Здравей,
и въпреки всичко защо не опиташ без -d ! 192.168.0.0/24

тоест в нат да имаш само

iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -j MASQUERADE

аз имах същият ( да абсолютно същият ) проблем. 
Just try it! :)

-- 

=+==+==+==+==+==+==+==+==+==+==+==+=
Dragomir Zhelev

Network Administrator  IT Support
Varna,Bulgaria
[EMAIL PROTECTED]
=+==+==+==+==+==+==+==+==+==+==+==+=


Re: lug-bg: iptables masquerade problem

2005-07-31 Thread Danail Petrov

Dragomir Zhelev wrote:


Здравей,
и въпреки всичко защо не опиташ без -d ! 192.168.0.0/24

тоест в нат да имаш само

iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -j MASQUERADE

аз имах същият ( да абсолютно същият ) проблем. 
Just try it! :)


 


ами да , и това пробвах но не ... не проработи :)

--
Danail Petrov
System Administrator
Internet Group
Stara Zagora
Bulgaria
AS21415
Phone : +359 42 601101  601112
Mobile: +359 888 289232
ICQ UIN: 989677



smime.p7s
Description: S/MIME Cryptographic Signature


RE: lug-bg: iptables masquerade problem

2005-07-29 Thread Georgi Sinapov

 Chain FORWARD (policy ACCEPT 2349 packets, 144K bytes)
  pkts bytes target prot opt in out source
 destination
15   870 ACCEPT all  --  *  *   192.168.0.0/24
 0.0.0.0/0
 
Какво казва lsmod?

Best e-gards,
Georgi Sinapov



smime.p7s
Description: S/MIME cryptographic signature


Re: lug-bg: iptables masquerade problem

2005-07-29 Thread Danail Petrov

Georgi Sinapov wrote:


Chain FORWARD (policy ACCEPT 2349 packets, 144K bytes)
pkts bytes target prot opt in out source
destination
  15   870 ACCEPT all  --  *  *   192.168.0.0/24
0.0.0.0/0

   


Какво казва lsmod?

Best e-gards,
Georgi Sinapov

 

Там всичко е наред. Но явно проблема е или в кернел-а , или в иптаблес 
(въпреки че и двете ги ъпдейтнах)

Сега като workaround ползвам ipchains :)

Явно това ще остане един загадъчен и неразрешен проблем

Благодаря на всички все пак

--
Danail Petrov
System Administrator
Internet Group
Stara Zagora
Bulgaria
AS21415
Phone : +359 42 601101  601112
Mobile: +359 888 289232
ICQ UIN: 989677



smime.p7s
Description: S/MIME Cryptographic Signature


RE: lug-bg: iptables masquerade problem

2005-07-28 Thread Georgi Sinapov
 Chain POSTROUTING (policy ACCEPT 74 packets, 4519 bytes)
  pkts bytes target prot opt in out source
 destination
 0 0 SNAT   all  --  *  *   192.168.0.0/24
 0.0.0.0 to:84.хх.хх.хх
 
 това е в момента правилото 
 и пак нищо ...
 
Може ли да сложиш един подобен FORWARD rule, за да видим дали има hits по
него?

Best e-gards,
Georgi Sinapov


smime.p7s
Description: S/MIME cryptographic signature


Re: lug-bg: iptables masquerade problem

2005-07-28 Thread Danail Petrov

Georgi Sinapov wrote:


Chain POSTROUTING (policy ACCEPT 74 packets, 4519 bytes)
pkts bytes target prot opt in out source
destination
   0 0 SNAT   all  --  *  *   192.168.0.0/24
0.0.0.0 to:84.хх.хх.хх

това е в момента правилото 
и пак нищо ...

   


Може ли да сложиш един подобен FORWARD rule, за да видим дали има hits по
него?

Best e-gards,
Georgi Sinapov
 


Дам ,
на forward отчита

Chain FORWARD (policy ACCEPT 2349 packets, 144K bytes)
pkts bytes target prot opt in out source   
destination
  15   870 ACCEPT all  --  *  *   192.168.0.0/24   
0.0.0.0/0



--
Danail Petrov
System Administrator
Internet Group
Stara Zagora
Bulgaria
AS21415
Phone : +359 42 601101  601112
Mobile: +359 888 289232
ICQ UIN: 989677



smime.p7s
Description: S/MIME Cryptographic Signature


Re: lug-bg: iptables masquerade problem

2005-07-27 Thread Delian Krustev
On Wednesday 27 July 2005 15:08, Danail Petrov wrote:
 Това е работило близо 1 година, но тези дни една от етернет платките на
 сървъра е изгоряла , и вследствие подменена със същата като модел
 платка.

Примерно модулите ти се зареждат в различен ред, това което е било
eth0 ти е станало eth1 ..



Re: lug-bg: iptables masquerade problem

2005-07-27 Thread Danail Petrov

Delian Krustev wrote:


On Wednesday 27 July 2005 15:08, Danail Petrov wrote:
 


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



Примерно модулите ти се зареждат в различен ред, това което е било
eth0 ти е станало eth1 ..

 


Примерно няма смисъл да се пишат излишни неща? :)

--
Danail Petrov
System Administrator
Internet Group
Stara Zagora
Bulgaria
AS21415
Phone : +359 42 601101  601112
Mobile: +359 888 289232
ICQ UIN: 989677



smime.p7s
Description: S/MIME Cryptographic Signature


Re: lug-bg: iptables masquerade problem

2005-07-27 Thread Delian Krustev
On Wednesday 27 July 2005 16:30, Danail Petrov wrote:
 Примерно няма смисъл да се пишат излишни неща? :)

Примерно, хич не са излишни. И пак примерно погледни къде е валиден входния
интерфейс:

-i, --in-interface [!] name
   Name of an interface via which a packet is going to  be  received  (only 
 for  packets
   entering  the  INPUT,  FORWARD  and PREROUTING chains).  When the ! 
argument is used
   before the interface name, the sense is inverted.  If the interface  
name  ends  in  a
   +,  then  any  interface  which begins with this name will match.  If 
this option is
   omitted, any interface name will match.



Re: lug-bg: iptables masquerade problem

2005-07-27 Thread Georgi Alexandrov

Danail Petrov wrote:


Здравейте,
преди малко попаднах на много странен проблем. Накратко схемата:

Линукс (Дебиан sid) , действащ като рутер който се връзва по pppoe , и 
маскира вътрешната мрежа навън.
Проблема е че ,в един момент iptables просто спря да маскира. С 
tcpdump виждам , как линукса не маскира вътрешните адреси , а просто 
ги forward-ва . Така и не успях да разбера защо. кернел-а беше 
2.4.26-х , сега го подмених с 2.6.8 и ефекта е същия. Ето малко аутпут:


tcpdump:
13:53:11.974931 IP (tos 0x0, ttl 128, id 6533, offset 0, flags [none], 
length: 60) 192.168.0.147  212.5.145.17: icmp 40: echo request seq 2051
13:53:17.474713 IP (tos 0x0, ttl 128, id 6534, offset 0, flags [none], 
length: 60) 192.168.0.147  212.5.145.17: icmp 40: echo request seq 2307


iptables:
Chain POSTROUTING (policy ACCEPT 6 packets, 378 bytes)
pkts bytes target prot opt in out source   
destination
   0 0 SNAT   all  --  eth1 *   
192.168.0.0/24   ! 192.168.0.0/24 to:84.xx.xx.xx


примерно -d ! 192.168.0.0/24 е безмислено в случая.



sysctl:
net.ipv4.conf.ppp0.mc_forwarding = 0
net.ipv4.conf.ppp0.forwarding = 1
net.ipv4.conf.eth1.mc_forwarding = 0
net.ipv4.conf.eth1.forwarding = 1
net.ipv4.conf.eth0.mc_forwarding = 0
net.ipv4.conf.eth0.forwarding = 1
net.ipv4.conf.lo.mc_forwarding = 0
net.ipv4.conf.lo.forwarding = 1
net.ipv4.conf.default.mc_forwarding = 0
net.ipv4.conf.default.forwarding = 1
net.ipv4.conf.all.mc_forwarding = 0
net.ipv4.conf.all.forwarding = 1
net.ipv4.ip_forward = 1

proc/net/ip_contract:
icmp 1 24 src=192.168.0.147 dst=212.5.145.17 type=8 code=0 id=512 
[UNREPLIED] src=212.5.145.17 dst=192.168.0.147 type=0 code=0 id=512 use=1


Някои да има идея за какво иде реч?!
Това е работило близо 1 година, но тези дни една от етернет платките 
на сървъра е изгоряла , и вследствие подменена със същата като модел 
платка. В момента от сървъра , имам връзка до машините от вътрешната 
мрежа , т.е. и 2-те Лан карти работят. Защо обаче линукса _НЕ_ маскира 
изходящия трафик , а просто го forward-ва?






Re: lug-bg: iptables masquerade problem

2005-07-27 Thread Danail Petrov

Delian Krustev wrote:


On Wednesday 27 July 2005 16:30, Danail Petrov wrote:
 


Примерно няма смисъл да се пишат излишни неща? :)
   



Примерно, хич не са излишни. И пак примерно погледни къде е валиден входния
интерфейс:

-i, --in-interface [!] name
  Name of an interface via which a packet is going to  be  received  (only  
for  packets
  entering  the  INPUT,  FORWARD  and PREROUTING chains).  When the ! 
argument is used
  before the interface name, the sense is inverted.  If the interface  name 
 ends  in  a
  +,  then  any  interface  which begins with this name will match.  If 
this option is
  omitted, any interface name will match.

 

Добре де , неискам да заформям флейм. Но не е това проблема. Както казах 
, имам връзка с всички у-ва и по двата интерфейса.

Други предложения?

П.с.
(това с -i eth1 беше най-последното нещо което написах за да пробвам 
маскирането , по принцип не го слагам)


--
Danail Petrov
System Administrator
Internet Group
Stara Zagora
Bulgaria
AS21415
Phone : +359 42 601101  601112
Mobile: +359 888 289232
ICQ UIN: 989677



smime.p7s
Description: S/MIME Cryptographic Signature


Re: lug-bg: iptables masquerade problem

2005-07-27 Thread Danail Petrov

Georgi Alexandrov wrote:



примерно -d ! 192.168.0.0/24 е безмислено в случая.


Примерно , е просто така написано. Мислиш че това е проблема ли? :)

П.с.
В случая наистина няма смисал , но при други обстоятелства , ако мрежата 
е разделена на под-мрежи (/30, /29) , тогава не би искал да правиш снат 
на адреси , до които трябва да се достигне просто с рутинг.


Други идеи?

--
Danail Petrov
System Administrator
Internet Group
Stara Zagora
Bulgaria
AS21415
Phone : +359 42 601101  601112
Mobile: +359 888 289232
ICQ UIN: 989677



smime.p7s
Description: S/MIME Cryptographic Signature


RE: lug-bg: iptables masquerade problem

2005-07-27 Thread Georgi Sinapov
 iptables:
 Chain POSTROUTING (policy ACCEPT 6 packets, 378 bytes)
  pkts bytes target prot opt in out source
 destination
 0 0 SNAT   all  --  eth1 *
 192.168.0.0/24   ! 192.168.0.0/24 to:84.xx.xx.xx
 

Аз имам следното питане - как си успял да конфигурираш POSTROUTING rule с
опция -i?

Best e-gards,
Georgi Sinapov


smime.p7s
Description: S/MIME cryptographic signature


Re: lug-bg: iptables masquerade problem

2005-07-27 Thread Danail Petrov

Georgi Sinapov wrote:


iptables:
Chain POSTROUTING (policy ACCEPT 6 packets, 378 bytes)
pkts bytes target prot opt in out source
destination
   0 0 SNAT   all  --  eth1 *
192.168.0.0/24   ! 192.168.0.0/24 to:84.xx.xx.xx

   



Аз имам следното питане - как си успял да конфигурираш POSTROUTING rule с
опция -i?

Best e-gards,
Georgi Sinapov
 

Много добър въпрос убий ме , немога да ти отговоря как е станало 
това?!?!


Chain POSTROUTING (policy ACCEPT 74 packets, 4519 bytes)
pkts bytes target prot opt in out source   
destination
   0 0 SNAT   all  --  *  *   192.168.0.0/24   
0.0.0.0 to:84.хх.хх.хх


това е в момента правилото 
и пак нищо ...

--
Danail Petrov
System Administrator
Internet Group
Stara Zagora
Bulgaria
AS21415
Phone : +359 42 601101  601112
Mobile: +359 888 289232
ICQ UIN: 989677



smime.p7s
Description: S/MIME Cryptographic Signature