[MASOCH-L] OpenVPN para acesso aos clientes

Fernando Frediani fhfrediani at gmail.com
Thu May 14 11:04:49 -03 2015


Lembre que o 100.64/10 não foi pensado para isso.
Da mesma forma que pode dar conflito com RFC1918 podem existir clientes 
num futuro próximo que comecem a receber CGNAT e a probabilidade do 
primeiro eu acredito que seja menor de acontecer. Se um CGNAT for bem 
feito ele pode ainda permitir a comunicação fim a fim ao menos entre 
assinantes dentro da rede da operadora.
Se talvez for o caso crie duas instâncias do OpenVPN com endereçamentos 
RFC1918 diferentes.

Fernando

On 14/05/2015 10:33, Vinícius Fontes wrote:
> Ah, e eu tenho alguns clientes que usam subredes de 172.16/12 em suas
> redes, por isso mesmo que resolvi optar pelo 100.64/10.
>
> Em 14 de maio de 2015 10:18, Leonardo Rodrigues <leolistas at solutti.com.br>
> escreveu:
>
>>      Minha experiência é de que quase ninguém usa a rede 172.16/12. Minha
>> VPN hoje usa 172.31.0.0 mas, como uso ifconfig-push por cliente e não jogo
>> nenhuma rota de rede, só ficam nos IPs do ponto a ponto mesmo, posso trocar
>> fácil fácil o IP de um cliente se precisar. A idéia é também que você não
>> precisa 'jogar rota' da sua rede pro seu cliente, deixa só no PtP mesmo e
>> no seu servidor da VPN, o que vai rotear seus acessos pra eles, faça NAT de
>> forma que seu cliente vai ver a conexão chegando do IP PtP.
>>
>>      Mas é isso ai, usando 100.64 a sua chance de ter problema é quase
>> nula. Eu mesmo quando configurei esse sistema, não sabia dessa rede, só
>> fiquei sabendo dela a poucas semanas através das mensagens em uma lista,
>> não lembro se aqui ou na GTER. Mas agora tá tudo montado, tudo funcionando,
>> não vou mexer não hehehe
>>
>>      Você não falou em quantidade de acessos simultâneos ... seriam muitos
>> ? O OpenVPN não é multi thread, em alguns casos de MUITOS acessos, é boa
>> dica rodar um OpenVPN por core da sua máquina e dividir a carga entre as
>> instâncias. O processo de rekey, especialmente, é bem pesado em termos de
>> CPU e, se for muita gente num processo único, pode introduzir lags
>> indesejáveis. No seu caso, que são acessos de servidores, pior ainda, já
>> que o uptime do pessoal deve ser bem alto e todo mundo vai fazer rekey em
>> janelas próximas.
>>
>>
>> On 14/05/15 10:00, Vinícius Fontes wrote:
>>
>>> Ótimas dicas, já tinha implementado a maioria no meu ambiente de teste.
>>>
>>> Outro problema que me ocorreu é caso o cliente utilize em sua rede interna
>>> o mesmo bloco privado que eu atribuí à VPN. Por exemplo, 172.16.2.0/24.
>>> Para evitar isso, estou pensando em usar o bloco 100.64.0.0/10, que é
>>> definido pela RFC 6598 para utilização em CGNAT.
>>>
>>>
>> --
>>
>>
>>          Atenciosamente / Sincerily,
>>          Leonardo Rodrigues
>>          Solutti Tecnologia
>>          http://www.solutti.com.br
>>
>>          Minha armadilha de SPAM, NÃO mandem email
>>          gertrudes at solutti.com.br
>>          My SPAMTRAP, do not email it
>>
>>
>>
>> __
>> masoch-l list
>> https://eng.registro.br/mailman/listinfo/masoch-l
>>
> __
> masoch-l list
> https://eng.registro.br/mailman/listinfo/masoch-l




More information about the masoch-l mailing list