[Решено] Два сетевых интерфейса и программы

kurych	# 12 лет, 6 месяцев назад
Темы: 0 Сообщения: 1395 Участник с: 06 ноября 2011	2domov0y: немного неясно, что имеете в виду. “Роутеры” во множественном числе наталкивают на мысль, что каждый роутер подключен к своему провайдеру. Тогда каждый роутер можно считать частью канала, предосталяемого провайдером, и, упрощая картину, приходим к исходному варианту компа, подключенного к двум провайдерам по двум интерфейсам. Natrio же показал не просто академический пример решения, а практический. Почему бы не осмыслить (опционально) и просто воспользоваться?

# 12 лет, 6 месяцев назад

Сообщения: 1395

Участник с: 06 ноября 2011

2domov0y: немного неясно, что имеете в виду. “Роутеры” во множественном числе наталкивают на мысль, что каждый роутер подключен к своему провайдеру. Тогда каждый роутер можно считать частью канала, предосталяемого провайдером, и, упрощая картину, приходим к исходному варианту компа, подключенного к двум провайдерам по двум интерфейсам.
Natrio же показал не просто академический пример решения, а практический. Почему бы не осмыслить (опционально) и просто воспользоваться?

domov0y	# 12 лет, 6 месяцев назад
Темы: 5 Сообщения: 819 Участник с: 09 июля 2011	Если когда нибудь доживу до белого адреса в интернет, поеду на поклон к Natrio с свежей ряженкой и пирогом :-) А предыдущий вопрос снят. Понял что не учел наличия шлюза во второй сети. Да пребудет с вами знание ip адреса

sleepycat	# 12 лет, 6 месяцев назад
Темы: 98 Сообщения: 3291 Участник с: 19 июля 2011	да нет шанец есть у вопроса, тогда надо ставить хорошую шелезяку с двумя внешними “дырами” и с функцией балансировки…но один фиг внутри все тоже самое только впрофиль….пускай делают люди так как считают верным..я просто счел что необходимо уточнить, так ксли спросили про фаервол, то ответить да/нет через три дня появится пост, “а все сделал как выше, кроме iptables но не работает”. И все , никакого заднего смысла, просто чтобы человек немного проникся духом сетей и съэкономил себе нервы. Лозунг у них был такой: "Познание бесконечности требует бесконечного времени". С этим я не спорил, но они делали из этого неожиданный вывод: "А потому работай не работай — все едино". И в интересах неувеличения энтропии Вселенной они не работали. (с)

sleepycat

# 12 лет, 6 месяцев назад

Темы: 98

Сообщения: 3291

Участник с: 19 июля 2011

да нет шанец есть у вопроса, тогда надо ставить хорошую шелезяку с двумя внешними “дырами” и с функцией балансировки…но один фиг внутри все тоже самое только впрофиль….пускай делают люди так как считают верным..я просто счел что необходимо уточнить, так ксли спросили про фаервол, то ответить да/нет через три дня появится пост, “а все сделал как выше, кроме iptables но не работает”. И все , никакого заднего смысла, просто чтобы человек немного проникся духом сетей и съэкономил себе нервы.

Лозунг у них был такой: "Познание бесконечности требует бесконечного времени". С этим я не спорил, но они делали из этого неожиданный вывод: "А потому работай не работай — все едино". И в интересах неувеличения энтропии Вселенной они не работали. (с)

kurych	# 12 лет, 6 месяцев назад
Темы: 0 Сообщения: 1395 Участник с: 06 ноября 2011	PS: я, честно говоря, не совсем понял, чем Natrio не понравилось решение из Linux Advanced Routing & Traffic Control HOWTO. В общем-то вполне логичное. И, кстати, как раз без iptables. Но так как на практике не приходилось им воспользоваться, а собирать тестовый макет нет ни времени, ни, главным образом (пока), желания, то нет аргументов для дискуссии. Тем более, что стопудово работающее решение вопроса - само по себе веский аргумент. Тем более, сделанное грамотно и без лишних наворотов.

kurych

# 12 лет, 6 месяцев назад

Темы: 0

Сообщения: 1395

Участник с: 06 ноября 2011

PS: я, честно говоря, не совсем понял, чем Natrio не понравилось решение из Linux Advanced Routing & Traffic Control HOWTO. В общем-то вполне логичное. И, кстати, как раз без iptables. Но так как на практике не приходилось им воспользоваться, а собирать тестовый макет нет ни времени, ни, главным образом (пока), желания, то нет аргументов для дискуссии. Тем более, что стопудово работающее решение вопроса - само по себе веский аргумент. Тем более, сделанное грамотно и без лишних наворотов.

sleepycat	# 12 лет, 6 месяцев назад
Темы: 98 Сообщения: 3291 Участник с: 19 июля 2011	kurych PS: я, честно говоря, не совсем понял, чем Natrio не понравилось решение из Linux Advanced Routing & Traffic Control HOWTO. В общем-то вполне логичное. И, кстати, как раз без iptables. Но так как на практике не приходилось им воспользоваться, а собирать тестовый макет нет ни времени, ни, главным образом (пока), желания, то нет аргументов для дискуссии. Тем более, что стопудово работающее решение вопроса - само по себе веский аргумент. Тем более, сделанное грамотно и без лишних наворотов. хм читая тут книжку по win serv 2008 автор прибегает к очень умному подходу. Давая комментарии к теме в рубрике “Реальный мир”, давая некоторые продостирежения , касательно того, что не вся теория имеет место в жизни. Пример в статье отличный, вообще ресурс стоит того чтобы в нужде потратить время на перевод. Но в стреднестатистическом случае ..ну громадно имхо, так шлюз без нат как шлюз будет бесполезен, он просто не будет работать,ну если только сам провайдер сделает необходимую работу сам, что граничит или с областью мистики или с областью больших денег. Now, this is just the very basic setup. It will work for all processes running on the router itself, and for the local network, if it is masqueraded. (маскарад тоже яйцо только впрофиль, при диашсипи полезная штука, но жрет больше ресурсов, у меня как правило все шлюзы имеют статику и я предпочитаю нат, если конечо шлюз сам открывает туннель или чтото в этом роде то да, но опять же дело случая и отдаляемся от смысла) Лозунг у них был такой: "Познание бесконечности требует бесконечного времени". С этим я не спорил, но они делали из этого неожиданный вывод: "А потому работай не работай — все едино". И в интересах неувеличения энтропии Вселенной они не работали. (с)

sleepycat

# 12 лет, 6 месяцев назад

Темы: 98

Сообщения: 3291

Участник с: 19 июля 2011

kurych
PS: я, честно говоря, не совсем понял, чем Natrio не понравилось решение из Linux Advanced Routing & Traffic Control HOWTO. В общем-то вполне логичное. И, кстати, как раз без iptables. Но так как на практике не приходилось им воспользоваться, а собирать тестовый макет нет ни времени, ни, главным образом (пока), желания, то нет аргументов для дискуссии. Тем более, что стопудово работающее решение вопроса - само по себе веский аргумент. Тем более, сделанное грамотно и без лишних наворотов.

хм читая тут книжку по win serv 2008 автор прибегает к очень умному подходу. Давая комментарии к теме в рубрике “Реальный мир”, давая некоторые продостирежения , касательно того, что не вся теория имеет место в жизни. Пример в статье отличный, вообще ресурс стоит того чтобы в нужде потратить время на перевод. Но в стреднестатистическом случае ..ну громадно имхо, так шлюз без нат как шлюз будет бесполезен, он просто не будет работать,ну если только сам провайдер сделает необходимую работу сам, что граничит или с областью мистики или с областью больших денег.

Now, this is just the very basic setup. It will work for all processes running on the router itself, and for the local network, if it is masqueraded.

(маскарад тоже яйцо только впрофиль, при диашсипи полезная штука, но жрет больше ресурсов, у меня как правило все шлюзы имеют статику и я предпочитаю нат, если конечо шлюз сам открывает туннель или чтото в этом роде то да, но опять же дело случая и отдаляемся от смысла)

inar	# 12 лет, 6 месяцев назад
Темы: 12 Сообщения: 62 Участник с: 30 сентября 2011	sleepycat да, но если Вам нужен nat (snat) далеко без огнестены не уехать. аппарат не играет роль шлюза или маршутизатора, он просто находится одновременно в двух сетях, и эти сети между собой не пересекаются. Ведь если фтп сервис слушает все адреса и доступен одновременно в обоих сетях, почему он не доступен одновременно в обоих интернетах, не понимаю. мне кажется, что можно как-то обойтись без iptables (чёрт, ну как западло его курить..), и роутинг тут не при чём, раз сети не соединяем. Только Россия, только хардкор..

inar

# 12 лет, 6 месяцев назад

Темы: 12

Сообщения: 62

Участник с: 30 сентября 2011

sleepycat
да, но если Вам нужен nat (snat) далеко без огнестены не уехать.

аппарат не играет роль шлюза или маршутизатора, он просто находится одновременно в двух сетях, и эти сети между собой не пересекаются.
Ведь если фтп сервис слушает все адреса и доступен одновременно в обоих сетях, почему он не доступен одновременно в обоих интернетах, не понимаю.
мне кажется, что можно как-то обойтись без iptables (чёрт, ну как западло его курить..), и роутинг тут не при чём, раз сети не соединяем.

Только Россия, только хардкор..

Natrio	# 12 лет, 6 месяцев назад
Темы: 48 Сообщения: 4771 Участник с: 08 января 2011	Inar а есть возможность решить проблему, не устанавливая iptables? iptables это лишь ОДНА ИЗ утилит для управления встроенными в ядро механизмами обработки пакетов, которые устанавливать не надо, они есть всегда. Если вы хотите более практических советов, покажите ваши конкретные конфиги, параметры сети и т.д. – всё, что есть. kurych PS: я, честно говоря, не совсем понял, чем Natrio не понравилось решение из Linux Advanced Routing & Traffic Control HOWTO. В общем-то вполне логичное. И, кстати, как раз без iptables. Но так как на практике не приходилось им воспользоваться, а собирать тестовый макет нет ни времени, ни, главным образом (пока), желания, то нет аргументов для дискуссии. Тем более, что стопудово работающее решение вопроса - само по себе веский аргумент. Тем более, сделанное грамотно и без лишних наворотов. Когда вы присваиваете интерфейсу айпи и подсеть, в таблице main АВТОМАТИЧЕСКИ создаётся роут на данную подсеть через этот интерфейс и адрес. А вот если вы хотите создать такой же роут в дополнительной таблице, вам придётся делать это отдельно, и единственная причина этого лишнего действия – неправильная расстановка правил выбора таблицы (ip rule) и неуместный дефолтный роут в таблице main. По умолчанию правило для main идёт предпоследним номером перед default 0: from all lookup local 32766: from all lookup main 32767: from all lookup default и вместо того, чтобы перенести обработку main повыше, убрать из неё дефолтный роут, и вставлять новые ПОСЛЕ main, где уже ЕСТЬ необходимые роуты, начинают лепить новые таблицы ПЕРЕД main, и в результате в них приходится дублировать все нужные роуты из main, зачастую вообще бОльшую её часть. Обычно дополнительные правила роутинга требуется применять не к тем пакетам, которые подпадают под обычные роуты по адресу назначения (которые как раз и пишутся в таблицу main), а к остальным, которые идут в дефолтный роут – именно потому, что маршрут для них определяется не таблицами роутов, а дополнительными условиями. А значит, в большинстве случаев в каждую из дополнительных таблиц требуется прописать только дефолтный роут – на каждую свой, а правила для них задать МЕЖДУ main и default. В таблицу dafault попадут пакеты, которые не подошли ни под одно из правил, и в ней должен быть последний дефолтный роут – самый дефолтный из всех :) С ним связано одно скользкое место, которое не описано ни в руководстве по iptables, ни в LARTC – я вообще нигде не нашел его описания, пришлось выяснять экспериментально. Если вы настраиваете маршрутизацию ТРАНЗИТНЫХ пакетов, всё выглядит просто и понятно – на соединения ставятся “метки” mark или connmark (вот для чего нужен iptables – не все условия можно прописать в ip rule, а ответные пакеты надо послать по интерфейсу запроса), по меткам срабатывают правила, по правилам выбираются таблицы роутов. Но если вы вдруг решите настроить маршрутизацию ИСХОДЯЩИХ пакетов непосредственно на машине, которая их порождает, вам ждёт сюрприз, безответные жалобы на который можно в большом количестве найти на просторах интернета. Безответные не в том смысле, что на них не отвечают, а в том, что не отвечают ничего путного – либо “У меня всё работает”, либо “так нельзя сделать, настраивай шлюз”. Проблема заключается в том, что в ядре Linux исходящие пакеты должны получить свой исходящий адрес, а значит они должны пройти маршрутизацию ДО ЭТОГО, иначе будет непонятно, адрес какого из интерфейсов (и адресов) им присваивать в качестве исходящего. В результате пакеты маршрутизируются ещё до того, как пройдут цепочку OUTPUT таблицы mangle в iptables, то есть до того, как получат метку. Дальше ещё страньше – если после первой маршрутизации пакет назначается в многоадресный сетевой интерфейс (eth, ath, wlan и т.д.), то после цепочки OUTPUT он ПРОХОДИТ МАРШРУТИЗАЦИЮ ПОВТОРНО, уже с учётом полученой метки. А вот если после первой маршрутизации пакет определяется в интерфейс “точка-точка” (ppp, tun), где любой пакет уже независимо от адреса попадёт на другой конец туннеля, Linux НЕ БУДЕТ маршрутизировать его во второй раз, и весь наш полиси-роутинг не сработает. Чтобы он сработал, в “главный” дефолтный роут нужно прописать именно один из многоадресных интерфейсов, на худой конец сойдёт даже петля (ip route add default dev lo tab default), при условии, что по правилам полиси-роутинга пакеты туда на самом деле не попадут. Мало того, для таких пакетов надо выполнить ещё и SNAT или маскарадинг, чтобы “вручную” задать для них правильный исходящий адрес. P.S. Не думаю, что в данном случае всё будет так страшно, но для ясности не мешало бы увидеть всё же ваши настройки сети :)

Natrio

# 12 лет, 6 месяцев назад

Темы: 48

Сообщения: 4771

Участник с: 08 января 2011

Inar
а есть возможность решить проблему, не устанавливая iptables?

iptables это лишь ОДНА ИЗ утилит для управления встроенными в ядро механизмами обработки пакетов, которые устанавливать не надо, они есть всегда.

Если вы хотите более практических советов, покажите ваши конкретные конфиги, параметры сети и т.д. – всё, что есть.

kurych
PS: я, честно говоря, не совсем понял, чем Natrio не понравилось решение из Linux Advanced Routing & Traffic Control HOWTO. В общем-то вполне логичное. И, кстати, как раз без iptables. Но так как на практике не приходилось им воспользоваться, а собирать тестовый макет нет ни времени, ни, главным образом (пока), желания, то нет аргументов для дискуссии. Тем более, что стопудово работающее решение вопроса - само по себе веский аргумент. Тем более, сделанное грамотно и без лишних наворотов.

Когда вы присваиваете интерфейсу айпи и подсеть, в таблице main АВТОМАТИЧЕСКИ создаётся роут на данную подсеть через этот интерфейс и адрес. А вот если вы хотите создать такой же роут в дополнительной таблице, вам придётся делать это отдельно, и единственная причина этого лишнего действия – неправильная расстановка правил выбора таблицы (ip rule) и неуместный дефолтный роут в таблице main.
По умолчанию правило для main идёт предпоследним номером перед default

0:      from all lookup local 
32766:  from all lookup main 
32767:  from all lookup default

и вместо того, чтобы перенести обработку main повыше, убрать из неё дефолтный роут, и вставлять новые ПОСЛЕ main, где уже ЕСТЬ необходимые роуты, начинают лепить новые таблицы ПЕРЕД main, и в результате в них приходится дублировать все нужные роуты из main, зачастую вообще бОльшую её часть.

Обычно дополнительные правила роутинга требуется применять не к тем пакетам, которые подпадают под обычные роуты по адресу назначения (которые как раз и пишутся в таблицу main), а к остальным, которые идут в дефолтный роут – именно потому, что маршрут для них определяется не таблицами роутов, а дополнительными условиями. А значит, в большинстве случаев в каждую из дополнительных таблиц требуется прописать только дефолтный роут – на каждую свой, а правила для них задать МЕЖДУ main и default.

В таблицу dafault попадут пакеты, которые не подошли ни под одно из правил, и в ней должен быть последний дефолтный роут – самый дефолтный из всех :)
С ним связано одно скользкое место, которое не описано ни в руководстве по iptables, ни в LARTC – я вообще нигде не нашел его описания, пришлось выяснять экспериментально.

Если вы настраиваете маршрутизацию ТРАНЗИТНЫХ пакетов, всё выглядит просто и понятно – на соединения ставятся “метки” mark или connmark (вот для чего нужен iptables – не все условия можно прописать в ip rule, а ответные пакеты надо послать по интерфейсу запроса), по меткам срабатывают правила, по правилам выбираются таблицы роутов. Но если вы вдруг решите настроить маршрутизацию ИСХОДЯЩИХ пакетов непосредственно на машине, которая их порождает, вам ждёт сюрприз, безответные жалобы на который можно в большом количестве найти на просторах интернета. Безответные не в том смысле, что на них не отвечают, а в том, что не отвечают ничего путного – либо “У меня всё работает”, либо “так нельзя сделать, настраивай шлюз”.

Проблема заключается в том, что в ядре Linux исходящие пакеты должны получить свой исходящий адрес, а значит они должны пройти маршрутизацию ДО ЭТОГО, иначе будет непонятно, адрес какого из интерфейсов (и адресов) им присваивать в качестве исходящего. В результате пакеты маршрутизируются ещё до того, как пройдут цепочку OUTPUT таблицы mangle в iptables, то есть до того, как получат метку. Дальше ещё страньше – если после первой маршрутизации пакет назначается в многоадресный сетевой интерфейс (eth, ath, wlan и т.д.), то после цепочки OUTPUT он ПРОХОДИТ МАРШРУТИЗАЦИЮ ПОВТОРНО, уже с учётом полученой метки. А вот если после первой маршрутизации пакет определяется в интерфейс “точка-точка” (ppp, tun), где любой пакет уже независимо от адреса попадёт на другой конец туннеля, Linux НЕ БУДЕТ маршрутизировать его во второй раз, и весь наш полиси-роутинг не сработает. Чтобы он сработал, в “главный” дефолтный роут нужно прописать именно один из многоадресных интерфейсов, на худой конец сойдёт даже петля (ip route add default dev lo tab default), при условии, что по правилам полиси-роутинга пакеты туда на самом деле не попадут. Мало того, для таких пакетов надо выполнить ещё и SNAT или маскарадинг, чтобы “вручную” задать для них правильный исходящий адрес.

P.S.
Не думаю, что в данном случае всё будет так страшно, но для ясности не мешало бы увидеть всё же ваши настройки сети :)

kurych	# 12 лет, 6 месяцев назад
Темы: 0 Сообщения: 1395 Участник с: 06 ноября 2011	Natrio: про p2p и tab default поучительно. Огромное спасибо за такой опыт.

inar	# 12 лет, 6 месяцев назад
Темы: 12 Сообщения: 62 Участник с: 30 сентября 2011	Natrio Inar а есть возможность решить проблему, не устанавливая iptables? Если вы хотите более практических советов, покажите ваши конкретные конфиги, параметры сети и т.д. – всё, что есть. конечно, хочу ) /etc/rc.conf NETWORKS=(net1 net2) .. DAEMONS=(... !network ...) /etc/network.d/net1 CONNECTION='ethernet' DESCRIPTION='eth1 connection for 192.168.1.0' INTERFACE='eth1' IP='dhcp' TIMEOUT=60 /etc/network.d/net2 CONNECTION='ethernet' DESCRIPTION='eth2 connection for 192.168.0.0' INTERFACE='eth2' IP='dhcp' TIMEOUT=60 ip route default via 192.168.0.1 dev eth2 metric 203 default via 192.168.1.1 dev eth1 metric 204 192.168.0.0/24 dev eth2 proto kernel scope link src 192.168.0.9 metric 203 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.9 metric 204 ifconfig eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.1.9 netmask 255.255.255.0 broadcast 192.168.1.255 inet6 fe80::21b:21ff:febf:7ad2 prefixlen 64 scopeid 0x20<link> ether 00:1b:21:bf:7a:d2 txqueuelen 1000 (Ethernet) RX packets 52037 bytes 19322155 (18.4 MiB) RX errors 0 dropped 381 overruns 0 frame 0 TX packets 47667 bytes 12367521 (11.7 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 17 memory 0xfd6c0000-fd6e0000 eth2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.0.9 netmask 255.255.255.0 broadcast 192.168.0.255 inet6 fe80::21b:21ff:febf:7ace prefixlen 64 scopeid 0x20<link> ether 00:1b:21:bf:7a:ce txqueuelen 1000 (Ethernet) RX packets 19400356 bytes 6711810189 (6.2 GiB) RX errors 0 dropped 20 overruns 0 frame 0 TX packets 30143206 bytes 37204940905 (34.6 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 19 memory 0xfd2c0000-fd2e0000 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 16436 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 0 (Local Loopback) RX packets 119169 bytes 446884184 (426.1 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 119169 bytes 446884184 (426.1 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 Только Россия, только хардкор..

inar

# 12 лет, 6 месяцев назад

Темы: 12

Сообщения: 62

Участник с: 30 сентября 2011

Natrio
Inar
а есть возможность решить проблему, не устанавливая iptables?
Если вы хотите более практических советов, покажите ваши конкретные конфиги, параметры сети и т.д. – всё, что есть.

конечно, хочу )

/etc/rc.conf

NETWORKS=(net1 net2)
..
DAEMONS=(... !network ...)

/etc/network.d/net1

CONNECTION='ethernet'
DESCRIPTION='eth1 connection for 192.168.1.0'
INTERFACE='eth1'
IP='dhcp'
TIMEOUT=60

/etc/network.d/net2

CONNECTION='ethernet'
DESCRIPTION='eth2 connection for 192.168.0.0'
INTERFACE='eth2'
IP='dhcp'
TIMEOUT=60

ip route

default via 192.168.0.1 dev eth2  metric 203
default via 192.168.1.1 dev eth1  metric 204
192.168.0.0/24 dev eth2  proto kernel  scope link  src 192.168.0.9  metric 203
192.168.1.0/24 dev eth1  proto kernel  scope link  src 192.168.1.9  metric 204

ifconfig

eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.9  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::21b:21ff:febf:7ad2  prefixlen 64  scopeid 0x20<link>
        ether 00:1b:21:bf:7a:d2  txqueuelen 1000  (Ethernet)
        RX packets 52037  bytes 19322155 (18.4 MiB)
        RX errors 0  dropped 381  overruns 0  frame 0
        TX packets 47667  bytes 12367521 (11.7 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 17  memory 0xfd6c0000-fd6e0000
eth2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.9  netmask 255.255.255.0  broadcast 192.168.0.255
        inet6 fe80::21b:21ff:febf:7ace  prefixlen 64  scopeid 0x20<link>
        ether 00:1b:21:bf:7a:ce  txqueuelen 1000  (Ethernet)
        RX packets 19400356  bytes 6711810189 (6.2 GiB)
        RX errors 0  dropped 20  overruns 0  frame 0
        TX packets 30143206  bytes 37204940905 (34.6 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 19  memory 0xfd2c0000-fd2e0000
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 16436
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 0  (Local Loopback)
        RX packets 119169  bytes 446884184 (426.1 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 119169  bytes 446884184 (426.1 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Только Россия, только хардкор..

sleepycat	# 12 лет, 6 месяцев назад
Темы: 98 Сообщения: 3291 Участник с: 19 июля 2011	ну как Натрио и говорил, судя по всему ответы улетают куда получиться, имхо. Лозунг у них был такой: "Познание бесконечности требует бесконечного времени". С этим я не спорил, но они делали из этого неожиданный вывод: "А потому работай не работай — все едино". И в интересах неувеличения энтропии Вселенной они не работали. (с)

sleepycat

# 12 лет, 6 месяцев назад

Темы: 98

Сообщения: 3291

Участник с: 19 июля 2011

ну как Натрио и говорил, судя по всему ответы улетают куда получиться, имхо.