2

У меня есть Mac mini, который я использую в качестве медиа-сервера, на котором работает XBMC и который передает медиафайлы с моего NAS на стереосистему и телевизор (который был откалиброван с помощью Spyder3Express, радует). Mac работает под управлением OSX 10.8.2, а интернет-соединение туннелируется для обеспечения общей конфиденциальности через OpenVPN через Tunnelblick. Я полагаю, что мой анонимный VPN-провайдер отправляет "redirect_gateway" в OpenVPN/Tunnelblick, потому что когда он эффективно туннелирует весь входящий и исходящий трафик вне локальной сети. Как нежелательный побочный эффект, который также открывает порты сервера коробки незащищенными от внешнего мира и обходит мой межсетевой экран-маршрутизатор (Netgear SRX5308). Я запустил nmap из-за пределов локальной сети на VPN-IP, и порты сервера на мини четко видны и подключаемы.

В mini открыты следующие порты: ssh/22, ARD/5900 и 8080+9090 для клиента XBMC iOS Constellation.

У меня также есть NAS-устройство Synology, которое, кроме файлов локальной сети, обслуживающих через AFP и WebDAV, обслуживает только сервер OpenVPN/1194 и сервер PPTP/1732 в глобальной сети. Вне локальной сети я подключаюсь к этому со своего ноутбука через OpenVPN и через PPTP с моего iPhone. Я только хочу подключить через AFP/548 от мини до NAS.

Пограничный межсетевой экран (SRX5308) просто отлично работает, стабилен и обладает очень высокой пропускной способностью при потоковой передаче из различных служб VOD. Мое соединение 100/10 с максимальной теоретической пропускной способностью. Набор правил выглядит следующим образом

Inbound:
PPTP/1723        Allow always to 10.0.0.40 (NAS/VPN server)
                 from a restricted IP range matching the cell phone provider range
OpenVPN/1194     Allow always to 10.0.0.40 (NAS/VPN server) from any

Outbound: Default outbound policy: Allow Always
OpenVPN/1194     TCP Allow always from 10.0.0.30 (mini) to a.b.8.1-a.b.8.254 (VPN provider)
OpenVPN/1194     UDP Allow always to 10.0.0.30 (mini) to a.b.8.1-a.b.8.254 (VPN provider)
Block always from 10.0.0.30 (mini) to any

На Mini я отключил брандмауэр OSX Application Level Firewall, потому что он выдает всплывающие окна, которые не запоминают мой выбор, один раз в другой, и это раздражает на медиа-сервере. Вместо этого я запускаю Little Snitch, который хорошо контролирует исходящие соединения на уровне приложения. Я настроил отличный встроенный брандмауэр OSX pf (из BSD) следующим образом

pf.conf (связи с брандмауэром приложения Apple удалены)

### macro names for external interface.
eth_if = "en0"
vpn_if = "tap0"
### wifi_if = "en1"
### %usb_if = "en3"

ext_if = $eth_if

LAN="{10.0.0.0/24}"

### General housekeeping rules ###
### Drop all blocked packets silently
set block-policy drop

### all incoming traffic on external interface is normalized and fragmented
### packets are reassembled.
scrub in on $ext_if all fragment reassemble
scrub in on $vpn_if all fragment reassemble

scrub out all

### exercise antispoofing on the external interface, but add the local
### loopback interface as an exception, to prevent services utilizing the
### local loop from being blocked accidentally.
### set skip on lo0
antispoof for $ext_if inet
antispoof for $vpn_if inet

### spoofing protection for all interfaces
block in quick from urpf-failed

#############################

block all

### Access to the mini server over ssh/22 and remote desktop/5900 from LAN/en0 only
pass in on $eth_if proto tcp from $LAN to any port {22, 5900, 8080, 9090} 

### Allow all udp and icmp also, necessary for Constellation. Could be tightened.
pass on $eth_if proto {udp, icmp} from $LAN to any

### Allow AFP to 10.0.0.40 (NAS)
pass out on $eth_if proto tcp from any to 10.0.0.40 port 548

### Allow OpenVPN tunnel setup over unprotected link (en0) only to VPN provider IPs
### and port ranges
pass on $eth_if proto tcp from any to a.b.8.0/24 port 1194:1201 

### OpenVPN Tunnel rules. All traffic allowed out, only in to ports 4100-4110 (rtorrent)
### Outgoing pings ok
pass in on $vpn_if proto {tcp, udp} from any to any port 4100:4110
pass out on $vpn_if proto {tcp, udp, icmp} from any to any 

Итак, каковы мои цели и чего достигают вышеуказанные настройки? (пока ты мне не скажешь :)

1) Полный доступ по локальной сети к указанным портам на мини / медиа-сервере (в том числе через мой собственный VPN-сервер) 2) Весь интернет-трафик с мини-медиа-сервера анонимизируется и туннелируется через VPN

3) Если OpenVPN/Tunnelblick на мини разрывает соединение, ничто не просочилось из-за pf и исходящего набора правил маршрутизатора. Он даже не может выполнить поиск DNS через маршрутизатор.

Так что я должен скрывать со всем этим? Ничего особенного, я просто увлекся, пытаясь остановить сканирование портов через VPN-туннель :)

В любом случае эта настройка работает отлично и она очень стабильна.

Проблема наконец-то!

Я хотел бы запустить сервер minecraft, и я установил его на отдельную учетную запись пользователя на мини-сервере (user = mc), чтобы разделить разделы. Я не хочу, чтобы этот сервер был доступен через анонимный VPN-туннель, потому что через него гораздо больше сканирований портов и попыток взлома, чем через мой обычный IP, и тогда я не доверяю java в целом. Поэтому я добавил следующее правило pf на мини:

### Allow Minecraft public through user mc
pass in on $eth_if proto {tcp,udp} from any to any port 24983 user mc
pass out on $eth_if proto {tcp, udp} from any to any user mc

And these additions on the border firewall:
Inbound: Allow always TCP/UDP from any to 10.0.0.30 (mini with mc server)
Outbound: Allow always TCP port 80 from 10.0.0.30 to any (needed for online account checkups)

Это работает нормально, но только когда туннель OpenVPN/Tunnelblick не работает. Если подключение к серверу minecraft из-за пределов локальной сети невозможно, доступ к локальной сети всегда в порядке. Все остальное работает как задумано. Я полагаю, что push redirect_gateway может быть близок к корню проблемы, но я хочу сохранить этого конкретного провайдера VPN из-за фантастической пропускной способности, цены и обслуживания.

Решение?

Как я могу открыть порт сервера Minecraft за пределами туннеля, чтобы он был доступен только через en0, а не через VPN-туннель?

Должен ли я использовать статический маршрут? Но я не знаю, какие IP-адреса WAN будут подключаться ... спотыкается

Насколько безопасным вы оцениваете эту настройку и хотите ли вы поделиться другими улучшениями?

1 ответ1

-1

Эта статья - Похоже, чтобы ответить на ваш основной вопрос. Это объясняет, как вы можете игнорировать Redirect_Gateway Push от вашего интернет-провайдера.

Игнорирование перенаправления-шлюза

Если вы используете OpenVPN в качестве клиента, а используемый вами сервер использует push « redirect-gateway », тогда ваш клиент перенаправляет весь интернет-трафик через VPN. Иногда клиенты не хотят этого, но они не могут изменить конфигурацию сервера. На этой странице объясняется, как переопределить шлюз перенаправления, чтобы клиенту не нужно было перенаправлять Интернет, даже если сервер говорит об этом.

Способ 1: игнорировать

Есть 2 варианта, которые можно использовать для игнорирования маршрутов, выдвигаемых сервером:

--route-noexec

Не добавляйте и не удаляйте маршруты автоматически. Вместо этого передайте маршруты скрипту --route-up, используя переменные среды.

 --route-nopull

При использовании с --client или --pull принимать параметры, выдвигаемые сервером, ИСКЛЮЧИТЬ для маршрутов, и параметры dhcp, такие как DNS-серверы. При использовании на клиенте этот параметр эффективно запрещает серверу добавлять маршруты в таблицу маршрутизации клиента, однако следует помнить, что этот параметр по-прежнему позволяет серверу устанавливать свойства TCP/IP интерфейса клиента TUN/TAP.

Способ 2: переопределить

Здесь мы просто добавим маршруты, которые переопределяют --redirect-gateway . Это будет работать так же, как def1 флаг def1 для --redirect-gateway . Это может отличаться, если сервер использует флаг def1 для параметра --redirect-gateway или нет (проверяя журнал при подключении). Обратите внимание, что net_gateway является внутренней переменной для openvpn и не требует каких- либо изменений. Если вы не знаете, использует ли ваш сервер def1 и не хотите проверять журналы, чтобы выяснить это, просто предположите, что они действительно используют def1 и используют 4 маршрута. Это будет работать, несмотря ни на что.

def1 - Используйте этот флаг для переопределения шлюза по умолчанию, используя 0.0.0.0/1 и 128.0.0.0/1 а не 0.0.0.0/0 . Это имеет преимущество переопределения, но не уничтожения исходного шлюза по умолчанию. Если сервер НЕ использует def1 добавьте следующие параметры в конфигурацию клиента:

route 0.0.0.0 128.0.0.0 net_gateway
route 128.0.0.0 128.0.0.0 net_gateway

Если сервер использует def1 или вы не знаете, добавьте следующие параметры в конфигурацию клиента:

route 0.0.0.0 192.0.0.0 net_gateway
route 64.0.0.0 192.0.0.0 net_gateway
route 128.0.0.0 192.0.0.0 net_gateway
route 192.0.0.0 192.0.0.0 net_gateway

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .