Jump to content

IPIP тунел от сапунерка с *WRT


NetworkPro

Recommended Posts

Разглеждах сайта на колегите от Плевен и видях два интересни скрийншота.

Според вас какви са предимствата на подобна реализация?

Благодаря.

post-55-0-45108400-1317478674_thumb.png

post-55-0-80430500-1317478676_thumb.png

Адрес на коментара
Сподели в други сайтове

  • Администратор

Тъй като аз съм правил тази конфигурация ще обясня конкретния пример.

Верига магазини, 6 обекта, DOS базиран складов софтуер инсталиран на Windows 98 които само споделят директории.

Създадох шест 192.168.x.x/24 и ги рутнах през ip тунели в мрежата. Разбира се имаше доста неща с които трябваше да се съобразявам за да взема точно това решение като започнем от цената и стигнем до избягването на бриджове заради някакъв вирус който вилнееше по 98-ците в една логическа мрежа.

Адрес на коментара
Сподели в други сайтове

Какво ще кажеш за следната идея: клиента има евтин Интернет и евтин рутер с WRT с вдигнат IPIP тунел до вашето сървърно където има хубав Интернет, QoS и NAT който няма да забие от много конекции? :)

И WRT има втори WAN порт или USB порт - нещо евтино за резервираност с рутиране, така че TCP/IP конекцията да се не губи, когато единия нет падне (без загуба на "транзакция").

Каква трябва да е примерно DD-WRT конфигурацията за такава резервираност?

Редактирано от NetworkPro
Адрес на коментара
Сподели в други сайтове

кво пречи всичко това да се направи с vlan-и? точно 10 пъти по-елегантно ще е

Ами примерно ако мрежата не е твоя и нещеш да плащат за VLAN-и, или ако офисите са ти на няколко доставчика - тогава трябва L3 и нагоре решение

Адрес на коментара
Сподели в други сайтове

Верига магазини ако нема пари да си плати L2 пренос... Да не говорим пък ако са в един град. Колко му е на всеки от isp-тата да преметне на друго някой vlan? 30лв ?

Адрес на коментара
Сподели в други сайтове

IPIP (L3) е по-независимо от VLAN (L2). L3 е По-добрата концепция според мен.

Редактирано от NetworkPro
Адрес на коментара
Сподели в други сайтове

Вероятно е така, но аз бих го направил L2-тунел с бридж. Това с вирусите не е проблем при наличието на iptables/ebtables работещи върху бриджовете. Решения много, всеки си избира :)

Адрес на коментара
Сподели в други сайтове

Ако зависи само от мен бих го напрай на възможно най-нисък Layer - направо влакно в компа :)

Ама идеята ми беше , че всеки всеки го прай както реши за добре и най-вече както му е изгодно и удобно. А колкото на по-горен Layer отиваш толкова повече GUI шитни има и "админите" им е по-лесно така ;)

Примерно аз имах клиент който отказа на 15 лв. за VLAN скъпо му било.... сравнително средна верига магазини за града. За толкова щял да си вземе ADSL City или както там е услугата на БТК.

Адрес на коментара
Сподели в други сайтове

Хех 15 лв ... Да се спасява :) Та идеята ми беше L2-over-L3 и по точно върху TCP конекция. Така всички варианти на преноса се свеждат до това, че само сървъра да е със статично публично ИП. Клиентите (отдалечените VPN точки) могат да бъдат зад НАТ, на ПППоЕ, на PPTP и всякакви други които малко или много намаляват MTU-то което може да бъде пренесено през VPN-a. Този начин гарантира MTU каквото си решите, а не колкото има останало от 1500 надолу. Отделно на това че error-correction ретрансмита на TCP ще спомага ако има някъде минимални загуби от порядъка на 1% да бъдат изчистени за крайния потребител .Това важи за клиент-ВПН във друг доставчик или кофти-среда. А и клиента като реши да си премести единия компютър от единия магазин в другия няма да ми се обажда да ме пита какво ИП да си сложи или да почне да прави глупост след глупост. Та това ми беше мисълта де. :)

Адрес на коментара
Сподели в други сайтове

Хех 15 лв ... Да се спасява :) Та идеята ми беше L2-over-L3 и по точно върху TCP конекция. Така всички варианти на преноса се свеждат до това, че само сървъра да е със статично публично ИП. Клиентите (отдалечените VPN точки) могат да бъдат зад НАТ, на ПППоЕ, на PPTP и всякакви други които малко или много намаляват MTU-то което може да бъде пренесено през VPN-a. Този начин гарантира MTU каквото си решите, а не колкото има останало от 1500 надолу. Отделно на това че error-correction ретрансмита на TCP ще спомага ако има някъде минимални загуби от порядъка на 1% да бъдат изчистени за крайния потребител .Това важи за клиент-ВПН във друг доставчик или кофти-среда. А и клиента като реши да си премести единия компютър от единия магазин в другия няма да ми се обажда да ме пита какво ИП да си сложи или да почне да прави глупост след глупост. Та това ми беше мисълта де. :)

Само не разбрах, мърмота със станиола къде е в цялата работа ?

Нали все пак некой трябва да увива пакетчетата ;D

Адрес на коментара
Сподели в други сайтове

Само не разбрах, мърмота със станиола къде е в цялата работа ?

Нали все пак некой трябва да увива пакетчетата ;D

Не си разбрал, ама аз мога да пренеса цяло прасе върху гърба на взвод мравки :) само е малко трудно да им синхронизирам стъпките, че иначе прасето се пада :) ама а да та вида теб как ще научиш мравки да маршируват без да развалят строя :)

е на за същото нещо говорим :)

Адрес на коментара
Сподели в други сайтове

Не разбирам с L2 как ще си направиш fail-over конфигурацията така че да нямаш загуби на транзакция?

С тунели трябва да се внимава особено с TCP защото целия пърформънс пада значително, затова ми харесва IPIP.

Адрес на коментара
Сподели в други сайтове

Не разбирам с L2 как ще си направиш fail-over конфигурацията така че да нямаш загуби на транзакция?

С тунели трябва да се внимава особено с TCP защото целия пърформънс пада значително, затова ми харесва IPIP.

Не виждам особен проблем. Правилно конфигуриран RSTP :). Да ще изгубиш няколко пакета, но само толкова. А за пърформанса ... TPLINK-XXX 40Мбит/с във посочената от мен конфигурация. Ако иде реч за повече скорост, то тогава си има и други варианти, но първоначалното задание беше за "сапунерка". Аз със скромния ми опит бих го направил така. Въпрос на гледна точка.

Редактирано от Hristo Andreev
Адрес на коментара
Сподели в други сайтове

Създайте нов акаунт или се впишете, за да коментирате

За да коментирате, трябва да имате регистрация

Създайте акаунт

Присъединете се към нашата общност. Регистрацията става бързо!

Регистрация на нов акаунт

Вход

Имате акаунт? Впишете се оттук.

Вписване
  • Потребители разглеждащи страницата   0 потребители

    • No registered users viewing this page.
×
×
  • Създай нов...

Important Information

By using this site, you agree to our Terms of Use.