Изпечатай

[nvd]

Здравейте, трябва да направя рутер с iptables, който да препраща пакетите от eth1 кум eth0 или обратното.
Извинете за тъпия въпрос ама нямам време да го боря. '>
Благодаря за вниманието.

[nvd]

докарах нещата до:
iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -d ! 192.168.0.0/24 ...?'>..../24 -j MASQUERADE
 '>

[neter]

Аз рутирам с подобен ред в /etc/init.d/rc.local файла:
/sbin/iptables -I POSTROUTING 1 -t nat -o eth0 -s 192.168.0.0/24 -j MASQUERADE
където eth0 е картата, която е вързана към Интернет. Не съм сигурен, но не виждам смисъл да слагаш -d ! 192.168.0.0/24, тъй като така и така при заявка от 192.168.0.10 към 192.168.0.20 не се минава през рутера. Не разбирам какво точно имаш предвид с "който да препраща пакетите от eth1 кум eth0 или обратното". Обясни по-подробно.

[voyager]

Човека не е съвсем наясно какво ТОЧНО иска да направи, и ни е оставил малко да гадаеме... Е, хвърлям боба, и...

1) дали само трябва да ги копира пакетите, или да прави някаква транслация? Така както го е обяснил не е ясно нито какво, нито откъде закъде. За описания на мрежа и т.н. въобще да не говорим. Както и да е, обикновенното копиране на пакети от една мрежа в друга, без промяна по хедърите е малко... нетривиална задача. Затова е по-вероятно да е 2)

2) Или иска да си направи някаква мрежичка зад рутера, дето да има интернет. Рецептата в този случай:
iptables -t nat -a POSTROUTING -o $EXT_IF -s $INT_NET -j SNAT --to-source $ROUTER_IP
където съответно:
$EXT_IF - интерфейса в който е забодена жицата, ходеща до доставчика.
$INT_NET - вътрешната мрежа. За да няма неразбории най-добре е да я адресираш като 192.168.0.0/24 да речем.
$ROUTER_IP - това е ясно. IP адреса на рутера.
Ако с тази рецепта не можеш да се справиш, викни познат или плати на някой да ти го направи...

[nvd]

Благодаря ви. Много ми помогнахте.

[gat3way]

Малко оффтопик,

Всъщност нещата стоят малко по-сложно. "Копиране" на пакети е забавно понятие, предполагам щом става въпрос за "пакети" тогава се има предвид layer 3 (мрежов слой) - IP в случая. От гледна точка на линукския мрежов стек, обаче, под "пакет"  се има предвид това, което се капсулира в sk_buff структурата - а то включва и layer 2 (ethernet) информация - src/dst MAC, ethertype, etc - ъм атомарната единица информация, прихваната от драйвера на мрежовата карта при вдигането на IRQ-то за получени данни. Освен ако не става дума за bridging (грубо казано хоста да се държи като switch), няма вариант една машина да "копира" 1:1  какъвто и да било "пакет", преминал през нея. Просто, при преминаване на "пакета" в различен етернет сегмент е нормално source MAC адреса да е различен, т.е да е еквивалентен на този на изходящият интерфейс.

Коректно иначе под "пакет"  се разбира основната layer 3 единица, а под "фрейм" да се разбира основната layer 2 единица. И така, какво става когато един пакет (IP) мине през някакъв рутер? Неизбежно, хедърът се променя. Най-малкото защото TTL стойността се намалява с 1, оттам и checksum-a. Така че дори да няма NAT, дефакто пакетите не се "копират", това което излиза е различно от това което влиза - и това най-вече от гледна точка на хедърите '>

Когато имаме вече и NAT, тогава се задействат и разни механизми, работещи на layer4 ниво. Хостът почва да прави разни фокуси с source port-a и source address-a, което променя и layer4 (TCP/UDP) хедърите в крайна сметка. И е твърде забавно в някои случаи, как connection tracking-a не може да се справи с много голям брой конекции, защото са му изчерпани вариантите за source ports (напоследък не е особено сложно поради масовата употреба на bittorrent). Интересно е как са решили проблема в conntrack кода на лайнукс- с reuse-ване,  ха-ха.

Единственият случай, при който един (от линукска гледна точка) "пакет" се "копира" 1:1, като се замисля е при bridging. Във всички останали случаи, винаги има промяна по някакъв хедър, дали е ethernet, дали е IP, дали е TCP/UDP, без значение. Което съответно се отразява на производителността - ако bridge-ваш интерфейси (l2) - тогава throughput-a е  близък до това което би получил при директна свързаност с crossover кабел между 2 хоста. Ако просто forward-ваш IP пакети (l3), производителността пада с порядък. Ако правиш и connection tracking (заради NAT - l4) - throughput-a осезаемо се насира. Някои ненормалници се захващат да правят и l7 филтри (p2p такива), което доволно много вече осира всичко.