Назад | Перейти на главную страницу

Маршрутизация моего домашнего трафика на другой сервер вместо маршрутов ISP по умолчанию

Я подозреваю, что у моего интернет-провайдера довольно плохие механизмы пиринга, что приводит к медленному доступу к нескольким сайтам, которые я регулярно посещаю. Я определил этот факт, перенаправив свой веб-трафик на сервер, который я разместил в центре обработки данных где-то поблизости, и увидел огромное улучшение моего опыта серфинга. Так что я почти уверен, что моя последняя миля относительно чиста, что дает мне столько, сколько рекламируется, в то время как исходящие ссылки от моего интернет-провайдера вызывают проблемы.

Я хотел бы сделать прокси еще один шаг вперед и направить весь мой домашний трафик через мой сервер, так как пиринговые механизмы в центре обработки данных кажутся намного лучше. Как мне этого добиться? Я придумал 2 возможных способа:

  1. Настройте статический маршрут от моего домашнего маршрутизатора до сервера. Полагаю, мне придется настроить стек IPTable сервера, чтобы он также работал как маршрутизатор?
  2. Настройте OpenVPN на моем сервере и настройте клиентов OpenVPN на всех ПК в моем доме.

Я хотел бы получить отзывы о том, какой подход будет лучше. На моем сервере работает Debian, на моем домашнем маршрутизаторе установлена ​​прошивка Tomato поверх Linksys WRT54GL, а на домашних ПК установлены варианты Ubuntu.

Спасибо! Вонг

Вариант 1 исключен, нет способа (который будет работать) указать вашему провайдеру маршрутизировать ваши пакеты иначе.

Вариант 2 подойдет. Просто установите соединение openvpn, установите статический маршрут на свой сервер через шлюз по умолчанию провайдера (тот, который у вас обычно есть для всего трафика), затем установите шлюз по умолчанию на IP-адрес конечной точки openvpn вашего сервера. Возможно, вы захотите отключить некоторые службы (например, DNS-серверы), добавив дополнительные статические маршруты к целевым IP-адресам (DNS-серверам) через шлюз вашего интернет-провайдера.

Вам понадобится какой-то IP-туннель, чтобы гарантировать, что трафик заканчивается на вашем совмещенном сервере, это МОЖЕТ быть проще с использованием OpenVPN или аналогичного.

Если между вашим домашним маршрутизатором и центром обработки данных есть маршрутизаторы (наиболее вероятно), просто установка шлюза по умолчанию на домашнем маршрутизаторе в качестве сервера центра обработки данных приведет к тому, что ваш домашний маршрутизатор не сможет отправлять ЛЮБОЙ трафик (как «следующий переход "не будет подключаться локально).

РЕДАКТИРОВАТЬ:

Необходимость в некоторой инкапсуляции заключается в том, что промежуточные маршрутизаторы не будут знать, что вы хотите, чтобы пакет прошел через ваш сервер. Используя любую туннельную инкапсуляцию (IP-in-IP, GRE, полноценный IPSEC VPN, SOCKS или что-то еще), самый внешний пакет предназначен для вашего сервера, где инкапсулированный фрейм затем может быть извлечен и отправлен.

Вам может потребоваться NAT для пакетов на вашем сервере, чтобы гарантировать, что возвращаемые пакеты идут по одному и тому же маршруту, минуя пиринговые механизмы вашего интернет-провайдера (здесь я предполагал, что у вас есть приличная пропускная способность для вашего совместно расположенного сервера).

При использовании вашего сервера в качестве веб-прокси устанавливается два сеанса TCP. Один - от вашей рабочей станции к вашему серверу, второй - от вашего сервера к веб-серверу.

Прошивка Tomato, вероятно, лучше, но обычные дрянные прошивки маршрутизатора часто не позволяют правильно настроить маршрутизацию. И иногда, когда кажется, что они делают это, они этого не делают, потому что они вставляют свои маршруты по умолчанию в места, которые вы не можете изменить, и, следовательно, не имеют никакого контроля.

Однако, помимо этого, я думаю, вам следует просто установить свой сервер в качестве шлюза по умолчанию на вашем маршрутизаторе и включить переадресацию IP на сервере (/etc/sysctl.conf). Использование OpenVPN в основном такое же, за исключением того, что он также шифрует его; openVPN изменяет вашу таблицу маршрутизации так же, как вы делаете это вручную.

Одна из причин, по которой я бы не выбрал OpenVPN, заключается в том, что когда вы настраиваете его так, чтобы весь интернет-трафик маршрутизировался через него (с помощью push 'redirect-gateway def1' и push «dhcp-option DNS xxxx»), это то, что он создает некоторые неудобства. Например, локальные DHCP-серверы больше недоступны, поэтому по окончании срока аренды ваше соединение не будет установлено.

Кроме того, создается специальный маршрут для перенаправления всего трафика на IP-адрес вашего сервера, чтобы проходить через устройство TUNx. Это означает, что ваш сервер больше не доступен по исходному IP-адресу. Обычно это не проблема, потому что вы можете использовать свой VPN-адрес для доступа к нему (VPN-сервер доступен по специальному адресу), но если у вас есть работающий на нем веб-сервер, он должен быть доступен по IP-адресу в вашем DNS A записи, иначе виртуальные хосты не будут работать.