Титла: въпрос за iptables
Публикувано от: nvd в Feb 18, 2007, 00:15
Здравейте, трябва да направя рутер с iptables, който да препраща пакетите от eth1 кум eth0 или обратното.
Извинете за тъпия въпрос ама нямам време да го боря.
Благодаря за вниманието.
Извинете за тъпия въпрос ама нямам време да го боря.
Благодаря за вниманието.
Титла: въпрос за iptables
Публикувано от: nvd в Feb 18, 2007, 00:23
докарах нещата до:
iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -d ! 192.168.0.0/24 ...?..../24 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -d ! 192.168.0.0/24 ...?
..../24 -j MASQUERADEТитла: въпрос за iptables
Публикувано от: neter в Feb 18, 2007, 00:44
Аз рутирам с подобен ред в /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 или обратното". Обясни по-подробно.
/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 или обратното". Обясни по-подробно.
Титла: въпрос за iptables
Публикувано от: voyager в Feb 18, 2007, 01:05
Човека не е съвсем наясно какво ТОЧНО иска да направи, и ни е оставил малко да гадаеме... Е, хвърлям боба, и...
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 адреса на рутера.
Ако с тази рецепта не можеш да се справиш, викни познат или плати на някой да ти го направи...
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 адреса на рутера.
Ако с тази рецепта не можеш да се справиш, викни познат или плати на някой да ти го направи...
Титла: въпрос за iptables
Публикувано от: nvd в Feb 18, 2007, 01:12
Благодаря ви. Много ми помогнахте.
Титла: въпрос за iptables
Публикувано от: gat3way в Feb 18, 2007, 03:10
Малко оффтопик,
Всъщност нещата стоят малко по-сложно. "Копиране" на пакети е забавно понятие, предполагам щом става въпрос за "пакети" тогава се има предвид 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 такива), което доволно много вече осира всичко.
Всъщност нещата стоят малко по-сложно. "Копиране" на пакети е забавно понятие, предполагам щом става въпрос за "пакети" тогава се има предвид 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 такива), което доволно много вече осира всичко.