Como abrir uma porta do servidor fora de um túnel OpenVPN com um firewall pf no OSX (BSD)

2

Eu tenho um Mac mini que eu uso como um servidor de mídia rodando o XBMC e que serve mídia do meu NAS para o meu aparelho de som e TV (que foi calibrado por cores com um Spyder3Express, feliz). O Mac executa o OSX 10.8.2 e a conexão à Internet é encapsulada para privacidade geral sobre o OpenVPN através do Tunnelblick. Acredito que o meu provedor de VPN anônimo envia "redirect_gateway" para o OpenVPN / Tunnelblick porque, quando ele está efetivamente, encapsula todos os tráfegos de entrada e saída que não são da LAN. Como um efeito colateral indesejado que também abre as portas de servidor de caixas desprotegidas para o mundo exterior e ignora meu roteador de firewall (Netgear SRX5308). Eu executei o nmap de fora da LAN no IP da VPN e as portas do servidor no mini são claramente visíveis e conectáveis.

O mini tem as seguintes portas abertas: ssh / 22, ARD / 5900 e 8080 + 9090 para o cliente XBMC iOS Constellation.

Eu também tenho um Synology NAS que, além do arquivo de LAN que serve através do AFP, e o WebDAV só oferece um OpenVPN / 1194 e um servidor PPTP / 1732 para WAN. Quando fora da LAN eu me conecto com isso do meu laptop sobre o OpenVPN e sobre o PPTP do meu iPhone. Eu só quero conectar através de AFP / 548 a partir do mini para o NAS.

O firewall de borda (SRX5308) apenas funciona de maneira excelente, estável e com um throughput muito alto ao transmitir de vários serviços VOD. Minha conexão é 100/10 com uma taxa de transferência máxima quase teórica. O conjunto de regras é o seguinte

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

No Mini eu desabilitei o Firewall de Nível de Aplicação OSX porque ele lança popups que não lembram minhas escolhas de uma vez para outra e isso é chato em um servidor de mídia. Em vez disso, eu corro o Little Snitch, que controla as conexões de saída bem em um nível de aplicativo. Eu configurei o excelente OSX builtin firewall pf (do BSD) como segue

pf.conf (os tie-ins do Apple app firewall foram removidos)

### 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 

Então quais são meus objetivos e o que a configuração acima consegue? (até que você diga o contrário):

1) Acesso total à LAN às portas acima no servidor mini / media (incluindo através do meu próprio servidor VPN) 2) Todo o tráfego de internet do servidor mini / media é anonimizado e encapsulado através de VPN

3) Se OpenVPN / Tunnelblick no mini cai a conexão, nada é vazado tanto por causa de pf e do conjunto de regras de saída do roteador. Não é possível fazer uma pesquisa de DNS pelo roteador.

Então o que eu tenho que esconder com tudo isso? Nada muito, eu apenas me empolguei tentando parar as varreduras de portas através do túnel VPN:)

Em qualquer caso, esta configuração funciona perfeitamente e é muito estável.

O problema finalmente!

Gostaria de executar um servidor de minecraft e instalei-o em uma conta de usuário separada no mini-servidor (user = mc) para manter as coisas particionadas. Eu não quero este servidor acessível através do túnel VPN anonimizado porque há muito mais varreduras de porta e tentativas de hackers através do que sobre o meu IP regular e então eu não confio em java em geral. Então eu adicionei a seguinte regra pf no mini:

### 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)

Isso funciona bem, mas apenas quando o túnel OpenVPN / Tunnelblick está inativo. Quando não há conexão possível com o servidor de minecraft de fora da LAN, o acesso dentro da LAN é sempre OK. Tudo o resto funciona como pretendido. Acredito que o redirecionamento de redirecionamento pode estar próximo da raiz do problema, mas quero manter esse provedor específico de VPN por causa da taxa de transferência, preço e serviço fantásticos.

A solução?

Como posso abrir a porta do servidor de minecraft fora do túnel para que ela esteja disponível apenas em en0 e não no túnel da VPN?

Devo eu usar uma rota estática? Mas eu não sei quais IPs WAN serão conectados ... tropeça

Quão seguro você estimaria essa configuração e você tem outras melhorias para compartilhar?

    
por Timbo 23.10.2012 / 00:34

1 resposta

-1

Este artigo - Parece responder à sua questão principal. Explica como você pode ignorar o Redirect_Gateway Push do seu ISP.

Ignorando o gateway de redirecionamento

Se você estiver executando o OpenVPN como um cliente, e o servidor usado estiver usando o push " redirect-gateway ", seu cliente redirecionará todo o tráfego da Internet pela VPN. Às vezes, os clientes não querem isso, mas não podem alterar a configuração do servidor. Esta página explica como sobrescrever o gateway de redirecionamento para que o cliente não precise redirecionar a internet, mesmo que o servidor diga.

Método 1: ignore

Existem duas opções que podem ser usadas para ignorar rotas enviadas pelo servidor:

--route-noexec

Não adicione ou remova rotas automaticamente. Em vez disso, passe as rotas para o script --route-up usando variáveis ambientais.

 --route-nopull

Quando usado com --client ou --pull , aceite as opções enviadas pelo servidor EXCETO para rotas e opções de DHCP, como servidores DNS.  Quando usada no cliente, essa opção impede que o servidor adicione rotas à tabela de roteamento do cliente, mas observe que essa opção ainda permite que o servidor defina as propriedades TCP / IP da interface TUN / TAP do cliente.

Método 2: substituir

Aqui, adicionaremos rotas que substituem --redirect-gateway . Isso funcionará como o def1 flag para --redirect-gateway works. Isso pode ser diferente se o servidor usar a opção def1 na opção --redirect-gateway ou não (verificando o log durante a conexão). Note que net_gateway é uma variável interna para openvpn e não precisa ser alterada para nada. Se você não souber se o seu servidor usa def1 e não deseja verificar os logs para descobrir, apenas assuma que eles usam def1 e usam as 4 rotas. Isso vai funcionar, não importa o quê.

def1 - Use esse sinalizador para substituir o gateway padrão usando 0.0.0.0/1 e 128.0.0.0/1 em vez de 0.0.0.0/0 . Isso tem o benefício de substituir, mas não extinguir o gateway padrão original. Se o servidor NÃO usar def1 , inclua as seguintes opções na configuração do cliente:

route 0.0.0.0 128.0.0.0 net_gateway
route 128.0.0.0 128.0.0.0 net_gateway

Se o servidor usar def1 ou se você não souber, adicione as seguintes opções à configuração do cliente:

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
    
por 28.02.2017 / 20:10