Як відкрити порт сервера поза тунелем OpenVPN з брандмауером pf на OSX (BSD)


2

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

У міні є наступні порти: ssh / 22, ARD / 5900 та 8080 + 9090 для клієнта XBMC iOS Constellation.

У мене також є Synology NAS, який крім файлів локальної мережі, що обслуговуються через AFP та WebDAV, подає в WAN лише сервер 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, оскільки він перекидає спливаючі вікна, які не пам’ятають мого вибору один раз до іншого, і це дратує на медіа-сервері. Натомість я запускаю 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 з-за меж локальної мережі неможливе, доступ у локальну мережу завжди в порядку. Все інше функціонує за призначенням. Я вважаю, що поштовх redirect_gateway може бути близьким до кореня проблеми, але я хочу зберегти цього конкретного постачальника VPN через фантастичну пропускну здатність, ціну та сервіс.

Рішення?

Як я можу відкрити порт сервера Minecraft за межами тунелю, щоб він був доступний лише через en0, а не тунель VPN?

Чи повинен я статичний маршрут? Але я не знаю, які IP-адреси WAN будуть підключати ... спотикається

Наскільки безпечним ви б оцінили цю настройку та чи маєте інші вдосконалення?

Відповіді:


-1

Ця стаття - з'являється, щоб відповісти на ваше основне запитання. Це пояснює , як ви можете ігноруватиRedirect_Gateway Push від вашого провайдера.

Ігнорування перенаправлення-шлюзу

Якщо ви використовуєте OpenVPN як клієнт, а сервер, який ви використовуєте, використовує push " redirect-gateway", то ваш клієнт перенаправляє весь інтернет-трафік через VPN. Іноді клієнти цього не хочуть, але вони не можуть змінити конфігурацію сервера. На цій сторінці пояснюється, як перекрити шлюз для переадресації, щоб клієнту не потрібно було перенаправляти Інтернет, навіть якщо сервер каже.

Спосіб 1: ігнорування

Є два варіанти, які можна використовувати для ігнорування маршрутів, що надсилаються сервером:

--route-noexec

Не додавати та не видаляти маршрути автоматично. Замість цього передайте маршрути до сценарію - збільшення, використовуючи змінні середовища.

 --route-nopull

При використанні з --client або --pull, прийміть параметри, надіслані сервером EXCEPT для маршрутів та параметрів dhcp, таких як DNS-сервери. При використанні на клієнті ця опція ефективно забороняє сервер додавати маршрути до таблиці маршрутизації клієнта, однак зауважте, що ця опція все ще дозволяє серверу встановлювати властивості TCP / IP інтерфейсу TUN / TAP клієнта.

Спосіб 2: перевизначення

Тут ми просто додамо маршрути, які перекривають --redirect-gateway. Це працюватиме так само, як працює 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

Будь ласка, цитуйте та цитуйте інформацію за відповідним посиланням Ваша відповідь сама по собі не відповідає на запитання автора. Інформація у надісланому вами посиланні життєво важлива для вашої відповіді.
Рамхаунд
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.