И сразу хозяйке на заметку: баттхёрт отличается от НЕНАВИСТИ тем, что при устранении причины негативной эмоции баттхёрт проходит, а НЕНАВИСТЬ остаётся. Итак...
Возникла на работе задача: организовать бридж между двумя кусками одной сети через публичный длинный канал от провайдера. Казалось бы, что может быть проще — ставим VPN и тыкаем его шлюзом на обеих сторонах. А хуй бы там. Адресация обоих кусков сети была одинаковая, поэтому шлюз просто не применить, вдобавок, у одной части шлюзом обязан быть хитророутер, стоящий в другой части (там пачка маршрутов и правил, которые пока трогать не хочется во избежание фейлов). Раньше оно работало по вайфаю, но он часто падал, так что было решено переделать канал на наземку. Чтобы соединить одноадресные сети, очевидно, нужно бриджевать физический интерфейс роутера с VPN-интерфейсом для полной прозрачности. Соответствующие статьи были найдены, и дело закипело.
Один роутер я настроил быстро, это был комп с дебианом, который и ранее некоторое время роутил трафик, так что поставил туда openvpn и настроил бридж. Вторым выбрали виртуалку под hyper-v, которая также работала клиентом openvpn в ещё одну сеть. Дебиан, как и остальные дистрибутивы, совершенно лояльно относится к нескольким конфигам openvpn, запуская нужное число демонов, так что клиент стал ещё и сервером. А выделенный комп к нему клиентился, значит. Баттхёрт начался сразу после того, как выяснилось (в лабораторных условиях), что с виртуалки моя машина за выделенным компом пингуется, а с этой машины ничего за виртуалкой (вся сеть) не пингуется, и сеть тоже мою машину не видит, интерфейсы виртуалки отвечают, но не дальше. Т.е. бридж работает только в одну сторону, фактически. Разумеется, ip_forward везде был включен, ведь виртуалка и так роутила трафик в VPN, но то был tun-VPN, а я поднимал tap, который работает на уровне ethernet-кадров.
Long story short: hyper-v не выпускает со своей виртуальной сетевухи arp-ответы в сеть. В себя пропускает, отсылает в VPN, оттуда приходит ответ, достигает виртуальной сетевухи, смотрящей в локалку, и... срубается. Полдня ковыряния tcpdump'ом ушло, чтобы понять, что это не мой косяк, а индусов из Всеми Любимой Компании. После этого я за 20 минут развернул такую же конфигурацию на машине коллеги, и всё заработало точно так, как должно было. Далее, выделили ещё один старый комп, туда раскатали дебиан, поставили openvpn со всеми теми же самыми конфигами, поставили вторую машину с другой стороны канала, и это добро сразу завелось! Шок. Теперь у нас обе части сети видят друг друга так, будто находятся на расстоянии одного хопа, т.е. бридж невозможно задетектить без специального отслеживания.
Литература: http://www.linux.com/learn/tutorials/305...
Вместо скрипта можно сконфигурить интерфейс br0 в /etc/network/interfaces с помощью пакета bridge-utils (man bridge-utils-interfaces) и pre-up openvpn --mktun --dev tap0 и pre-up ifconfig tap0 0.0.0.0 promisc up
Не используйте hyper-v, если вам не угрожают медленно отрезать яйца тупым ржавым ножом, измазанным в какой-то чёрной дряни. Да и в этом случае сто раз подумайте. Баттхёрт от этого куска h(yper)-ovna уже прошёл, а ненависть будет держаться долго. Только KVM, только Debian!
@Kona-chan: Студеная былина. Хозяйке на заметку [x]
and @uzername
Срань господня, я скроллить то это ссанинку устал, не то что б ещё читать её.
> Адресация обоих кусков сети была одинаковая, поэтому шлюз просто не применить
применить то можно, главное чтобы адреса в подсетях не совпадали.
МАРШРУТИЗАЦИЯ ИТТ
Ну я и применил, хуле. Просто новый опыт по созданию tap VPN, бриджей, и, как всегда, спермобляди соснули. Из-за этого я задержался на работе аж на полтора часа!
А вы без учебника не умеете знания получать? Всё надо с ложечки кушать? В вузе, тащемта, именно этому и учат — получать необходимую информацию своими силами. Учебников там минимум, лекции дают лишь половину нужных знаний, остальное — на самостоятельное изучение. Я, скажем, это умел ещё в школе, поэтому и сейчас нахожу всё своими силами, а вместо учебников у меня маны. Чего и вам желаю.
Олифера читай, пёс.
Если перед тобой стоит исключительно прикладные задачи, то ок. В манах теорию тебе никто не будет разжёвывать. То есть получается, что ты как бы решаешь проблемы не понимая самой сути вещей.
Как бы я _всегда_ проникаю в суть вещей. Это мой заёб с детства, терпеть не могу магию высокого уровня. Хотя бы один раз я всегда докапываюсь до сути, но потом, если это не востребовано, просто забываю её. Низкоуровневую магию (типа модуляции электросигналов в витой паре) я воспринимаю спокойно, потому что до неё вряд ли когда-то доберусь. А вот без знания последовательности установления TCP-соединения жить трудновато, уже были случаи, когда по хэндшейку (и его частичному отсутствию) удавалось понять причину проблемы. Недоученность, скорее, характерна для спермарей, ведь у них и без того детали реализации и тонкие технические вопросы скрыты гуем и бинарным кодом без нормальной встроенной документации. Так что я, в некотором роде, опрыщеблядился ещё в те времена, когда сидел за спектрумом, где также активно изучал функции ПЗУ и прерывания. Потом, правда, на долгие годы сдался в анальное рабство, был слаб, признаю.
Да мне похуй как-то. Я спросил как без литературы можно узнавать и понимать низкоуровневые вещи.
По-твоему, эти вещи только в литературе описаны, лол? Полным-полно технической информации на форумах, википедиях и специализированных новостных ресурсах. Просто надо уметь искать. Благодаря этому, я не перегружаюсь ненужным хламом и нахожу своевременно то, что надо (всё равно память ни к чёрту, так что «общее развитие» ко мне неприменимо, забуду, если не буду использовать).
Ок, вместо книг лучше читать форумы и википедии. Лучше бы про RFC упомянул, я бы даже согласился. А я вот про структурированность и последовательность упомяну, присущей литературе, а не хаотичных знаний не пойми чего.
эврекафаг какбе намекаэ, что в книгах много воды, в отличие от.
Спасибо, кэп.
Хотя не согласен. На форумах ещё больше воды из-за постоянных срачей. Впрочем, смотря на него, и видно что это он усвоил лучше всего.
Очевидно, следует искать инфу не на Русских форумах, а во всяких стэковерфлоу и арчевики, где инфы свыше 9000%, вот уж воистину. Но оно и понятно, ведь арчебляди столкнулись со всеми мыслимыми и немыслимыми прыщепроблемами и законспектировали их, спасибочки!
Только сегодня проебал 2 часа, пытаясь подружить pulseaudio и consolekit :coolface:
И при этом ты до сих пор не понял, что костыльный звуковой шервер НЕ НУЖЕН? Вот так отсос.
ну, на самом деле, без него хомячью трудно сделать, чтобы, например, "в скайпе звук с микрофона шёл с вею-камеры, а в жабире — с фронт-панели :)
Шок. Я верю, что есть какие-то задачи типа этих, но сам с таким не сталкивался. Вообще, есть нормальный jack, где можно делать кошерный роутинг и всё такое. Лучше б его развивали, чем это говно.
еврикофаг няша, все правильно сделал. Хотя цискофаги смеются над прыщепроблемами.