[iptables -t nat -A POSTROUTING -s 172.16.0.0/12 -o eth0 -j MASQUERADEiptables -t mangle -A PREROUTING -i eth0 -j TTL --ttl-inc 1iptables -t mangle -A POSTROUTING -s 172.16.0.0/12 -o eth0 -j TTL --ttl-set 64]

Изглежда ми странен начинът, по който го правиш. Ето аз как успях да го напрaвя, две правила са нужни, третото е за да не изтече информация на доставчика за деянието '>. Подразбирам, че eth0 е външната карта и вътрешните компютри ползват адреси за частно ползване 172.16.0.0/12 от RFC 1918 :

iptables -t nat -A POSTROUTING -s 172.16.0.0/12 -o eth0 -j MASQUERADE
iptables -t mangle -A PREROUTING -i eth0 -j TTL --ttl-inc 1
iptables -t mangle -A POSTROUTING -s 172.16.0.0/12 -o eth0 -j TTL --ttl-set 64

Разбира се, трябва да имаш компилиран модула ipt_TTL.ko. Fedora Core 4 с приложени актуализации го има включен този модул. И не забравяй в /etc/sysctl.conf: net.ipv4.ip_forward = 1, след което #sysctl -p.

По въпроса относно разликата между политиката SNAT и MASQUERADE. По принцип няма проблем да се използва винаги MASQUERADE, но ако имаш статичен IP адрес е по-добре да се ползва SNAT --to-source 1.2.3.4, където 1.2.3.4 е примерният статичен IP адрес. При динамичен обаче използвай MASQUERADE.

А иначе машина с такива параметри е достатъчно квалифицирана за рутер. '> Вероятно и Х ще работи, но не особено задоволително.

[net.ipv4.ip_forward = 1]

По-добре да се редактира файлът /etc/sysctl.conf, така че да има ред:

net.ipv4.ip_forward = 1.

След което просто #syctl -p.

[yum groupinstall XFCE]

Аз го инсталирах с yum groupinstall XFCE и автоматично се добави към наличните графични среди след това.

"ve" и "we" са изродите на чатърския език според мен. Ако някой ми говори така го отрязвам директно. То бива бива простотия, ама чак толкоз...  

Моят пък си работи не само без видеокарта, но и без твърд диск. Добре, че не спира токът често.  '>

Без да звуча укорително, само ти напомням: нали си наясно, че доставчиците никак не биха били доволни, ако разберат, че се изнася локалното съдържание навън. '> Знам за подобни случаи тук, в Люлин, където потребители бяха отворили проксита, в услуга на приятелите си в чужбина, след което са били засечени от доставчика и са били изключени. Не, че е проблем, пълно е с доставчици, но все пак едва ли е приятно. Тъй че, умната. '>

[-destination {IP}:{port}]

Ами ако не се лъжа не може да се ползва --dport, ако не се напише преди това -d. '> Нямам възможност да го тествам в момента, но мисля, че беше така. Както и -DNAT --to-destination {IP}:{port}

[iptables -t nat -A POSTROUTING -p tcp -d 0/0 --dport 80 -o eth1 -j SNAT --to-source 213.91.214.35iptables -t nat -A POSTROUTING -p tcp -d 0/0 --dport 25 -o eth1 -j SNAT --to-source 213.91.214.35iptables -t nat -A POSTROUTING -p tcp -d 0/0 --dport 110 -o eth1 -j SNAT --to-source 213.91.214.35]

Хубаво е сам да погледнеш ръководствата, но мисля, че би трябвало да стане по следния начин (ако картата с 213.91.214.35 е eth1):

iptables -t nat -A POSTROUTING -p tcp -d 0/0 --dport 80 -o eth1 -j SNAT --to-source 213.91.214.35
iptables -t nat -A POSTROUTING -p tcp -d 0/0 --dport 25 -o eth1 -j SNAT --to-source 213.91.214.35
iptables -t nat -A POSTROUTING -p tcp -d 0/0 --dport 110 -o eth1 -j SNAT --to-source 213.91.214.35

Аз бих ти препоръчал да оставиш и това:

iptables -t nat -A POSTROUTING -p udp -d 0/0 --dport 53 -o eth1 -j SNAT --to-source 213.91.214.35,

за да могат да се изпращат DNS заявките (освен ако на рутера не работи DNS).

А иначе добро ръководство за iptables може да се намери на този адрес.

Вместо SNAT --to-source 213.91.214.35 може да използваш MASQUERADE, обаче ако този IP адрес е статичен е по-добре SNAT, защото ползва по-малко ресурси на машината.

По принцип никой не би бил доволен. Обаче фактът, че са се обадили и са казали "скрийте си картата", а не са изключили достъпа е показателен, че хората са наясно, въпросът е да не им преча на работата, общо взето такъв е принципът.

На нула са. Единици са ми само forwarding, send_redirects и accept_redirects.

Дава следното:

[root@nat-router ~]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
84.238.133.0    0.0.0.0         255.255.255.0   U     0      0        0 eth1
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth1
0.0.0.0         84.238.133.1    0.0.0.0         UG    0      0        0 eth1

Това е, когато рутерът е свързан с интернет, вътрешната карта съм я забранил за момента. След като вдигна интерфейс eth0 и рутерът започва да маршрутизира (има достъп от вътрешната мрежа), изходът от route -n е следният:

[root@nat-router etc]# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
84.238.133.0    *               255.255.255.0   U     0      0        0 eth1
192.168.0.0     *               255.255.255.0   U     0      0        0 eth0
169.254.0.0     *               255.255.0.0     U     0      0        0 eth0
0.0.0.0         84.238.133.1 0.0.0.0         UG    0      0        0 eth1

Между другото проблемите, които това създавало на администратора били свързани с arping-a. При всички случаи не е нормално тази карта да се вижда отвън.  

[iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -d 0/0 -o eth1 -j MASQUERADEiptables -t mangle -A PREROUTING -i eth1 -j TTL --ttl-set 64iptables -t nat -A PREROUTING -p tcp -d EXT_IP --dport 6112 -j DNAT --to-destination INT_IP:6112]

Здравейте. Инсталирах един Линукс маршрутизатор под Fedora Core 3, като използвах TTL пача от Patch-o-matic кък ядрото и всичко си заработи както трябва. Но след това администраторът на мрежата се обади и каза, че виждал вътрешната карта 192.168.0.1 и това му правело проблеми. Това беше много изненадващо за мен и сега се чудя къде е причината, поради която този адрес се вижда отвън. Ето конфигурацията:

eth1 - външен интерфейс, получава реален статичен ИП адрес EXT_IP по DHCP
eth0 - вътрешен интерфейс, статичен ИП адрес 192.168.0.1

Използвам три правила, едното от които незадължително:

iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -d 0/0 -o eth1 -j MASQUERADE
iptables -t mangle -A PREROUTING -i eth1 -j TTL --ttl-set 64
iptables -t nat -A PREROUTING -p tcp -d EXT_IP --dport 6112 -j DNAT --to-destination INT_IP:6112


Къде греша?  '> Предварително благодаря.

Благодаря, това бяха отговорите, които очаквах. Ще се опитам отново да прекомпилирам само модулите. Това предполага, че след като изпълня make modules и make modules_install, после и depmod вече ще имам поддръжка на TTL смяна.

Здрасти, мерси за напътствията. Аз ползвам следното кратко обяснение (на немски е, но и да не разбираш се виждат какви команди се изпълняват), там човекът е инсталирал някакъв друг пач от Patch-o-matic, но би трябвало нещата да стават по същия начин. Чудех се просто дали е възможно когато поддръжката на ТТЛ промяна в хедъра на пакета се постави като модул, а не директно в ядрото, то само да компилирам модулите, е не цялото ядро наново. Човекът в горното ръководство е изпълнил:
tux@erde:# make dep
tux@erde:# make
tux@erde:# make modules bzImage modules_install

Трябва ли същото да направя и аз? Това, от което се притеснявам е да  не трябва после при make menuconfig да избирам от абсолютно всички секции нещата, които ще трябват, проблемът е, че не знам кои трябват. Искам само да избера от  "Networking Options" --> "IP Netfilter Configuration"--> TTL... и това е.

Един приятел ме помоли за помощ като каза, че доставчикът му е сложил TTL=1, аз знам, че се лъже с този пач, тъй като в iptables по подразбиране го няма. Отново благодаря предварително за евентуална помощ. '>