Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Há alguma outra máquina Ubuntu na sua rede, que possa ser usada pra testes?
No servidor VPN, como eu disse.
Então reativa o NAT no servidor VPN:
iptables -t nat -A POSTROUTING -s 10.0.2.0/24 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -j MASQUERADE
Observa que vc tem que adicionar as duas faixas no NAT.
Você tem duas alternativas: ou adiciona essas faixas no firewall do Windows, no servidor que vai ser acessado, ou faz NAT pras duas faixas, enganando teu servidor.
Pq não funciona agora? Pq vc só fazia NAT pra uma das faixas, e na minha orientação, eu pedi pra você parar de fazer.
isso é visto no próprio servidor, principalmente se ele for um servidor windows.
a regra de NAT também resolve isso, pois retira o IP de origem vindo das redes 10.0.2.0/24 ou 192.168.1.0/24, mas precisa ser mais completa. Daí vc decide, se quer corrigir por roteamento e configuração do firewall do servidor, ou pelo NAT.
O firewall do servidor de destino está configurado pra aceitar conexões das redes 10.0.2.0/24 e 192.168.1.0/24 ?
Se você pinga é porque conectou na VPN, não?
Ou é conexão no sistema de destino?
Enviado do meu smartphone
A regra não é necessária se você ajustar as rotas corretamente .
Os clientes que conectam a partir de redes avulsas recebem IP da rede 10.0.2.0/24, e as máquinas de sua rede não sabem como alcançar essa rede, por isso entregam o pacote de retorno ao proxy, que é o gateway da sua rede.
Assim, bastaria que o seu proxy fosse também o servidor OpenVPN, ou pelo menos, que tivesse rota para a rede 10.0.2.0/24, pra funcionar. Como ele não tem, ele manda esses pacotes pro gateway dele (a Internet), onde eles se perdem.
A função do NAT é remendar esse erro de roteamento, substituindo o endereço de rota desconhecida por outro roteável. Mas deve ser visto assim, como um remendo, um quebra-galho, não como solução definitiva.
O que acontece com os clientes na filial é ainda um pouco pior: sua regra de NAT não os leva em conta, pois apesar de entrarem pela VPN, esses pacotes não se originam na rede 10.0.2.0/24, mas sim na rede 192.168.1.0/24, assim eles não sofrem NAT. Por isso em disse antes que sua regra de NAT está errada. Agora, com um pouco mais de informação, vejo que ela não está errada, e sim incompleta.
Estes dois comandos no seu servidor proxy devem resolver seu problema:
sudo route add -net 10.0.2.0/24 gw 192.168.100.70
sudo route add -net 192.168.1.0/24 gw 192.168.100.70
Enviado do meu smartphone
Essa regra não é necessária se você setar as rotas corretamente.Não posso remover a regra por que também possuo vendedores externos que se conectam via notebook e sempre estão em um hotel diferente.
Então, os clientes da filial estão na faixa 192.168.1.0/24, certo?
Enviado do meu smartphone
Então, será MUITO mais fácil fazer isso, se o OpenVPN ficar junto com o serviço de gateway da sua rede.
Prosseguindo... não está claro pra mim se a rede dos clientes da filial é a 192.168.1.0/24 ou a 192.168.88.0/24. Isso fará muita diferença, pois você precisa adicionar uma rota ao seu proxy, direcionando pacotes destinados a eles de volta ao seu servidor OpenVPN (se fosse uma máquina só, isso seria desnecessário).
Outra coisa, me parece que essas regras de NAT no firewall da matriz, além de errada, é desnecessária. A regra de NAT é necessária quando você tem um tráfego com um endereço de origem que não é alcançável pelo destino (p.ex. quando vc quer acessar a internet a partir de uma máquina que usa IP de rede privada).
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -s 10.0.2.0/24 -A POSTROUTING -o eth0 -j MASQUERADEExplique pra mim, pq na matriz você não adicionou o OpenVPN diretamente ao servidor proxy?Simplesmente pelo fato de não utilizar muitos serviços em uma só maquina. Parando a VPN não paro a internet ou a rede local da matriz.
Aliás, qual é o sistema que roda nesse proxy?Proxy rodando Ubuntu Server 14.04 LTS com Squid Proxy transparente.
Qual nível de acesso você tem a ele?Acesso root, local e remoto.
Citar...Ubuntu 14.10...O Ubuntu 14.10 já está sem suporte há um bom tempo. Sugiro fortemente que você atualize seu servidor e seus clientes para uma versão LTS (16.04 ou, se você tiver coragem, o 18.04 que está pra sair do forno).
Como esse tipo de problema pode estar relacionado com a versão do Ubuntu, eu peço que você confirme se escreveu corretamente a versão, antes da gente prosseguir com qualquer tentativa de solução.
Mikrotik > 192.168.88.1
Client Openvpn eth0 > 192.168.88.2
Client Openvpn eth1 > 192.168.1.1 >> Gateway da rede cliente
Cliente Openvpn tun0 > 10.0.2.2
Mikrotik > 192.168.0.1
Servidor proxy eth0 > 192.168.0.2
Servidor proxy eth1 > 192.168.100.1 > Gateway rede matriz
Servidor OpenVPN eth0 > 192.168.100.70
Servidor OpenVpn tun0 > 10.0.2.1
route add -net 192.168.88.0/24 gw 10.0.2.1
route add -net 192.168.100.0/24 gw 10.0.2.2
#Dispositivo usado pela VPN
dev tun
#Porta usada para conexão
port 2222
#Protocolo de conexão
proto udp
#Certificado da CA
ca keys/ca.crt
#Certificado do Servidor de VPN
cert keys/vpnserver.crt
#Chave usada pela matriz
key keys/vpnserver.key
#Chave Diffie-Hellman
dh keys/dh2048.pem
#Rede usada pela VPN (Matriz 10.0.2.1 e os clientes a partir de 10.0.2.2)
server 10.0.2.0 255.255.255.0
#
client-to-client
#
#Client Config
client-config-dir /etc/openvpn/ccd
#
#Route server-side traffic bound for the client network
route 192.168.88.0 255.255.255.0
#
topology subnet
#Rota usada pelos clientes para acessar a rede da matriz
push "route 192.168.100.0 255.255.255.0"
push "route 192.168.88.0 255.255.255.0"
#
tls-server
#Envia um ping a cada 10 segundos e cancela a conexão se não houver resposta em 120 segundos
keepalive 10 120
#Máximo de clientes conectados simultaneamente
max-clients 100
#
float
#Compressão usando lzma
comp-lzo
#Medodo de codificacao
cipher AES-256-CBC
#Usuário e grupo que o openvpn usará para ser executado
user nobody
group nogroup
#Manter a chave e os túneis persistentes
persist-key
persist-tun
#NÃvel de Log.
verb 3
#Caminho do log
status /var/log/openvpn.stats
iroute 192.168.88.0 255.255.255.0
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -s 10.0.2.0/24 -A POSTROUTING -o eth0 -j MASQUERADE
#esses 3 comandos compartilham a internet
modprobe iptable_nat
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE1) Quantas estações de trabalho estão vinculadas a esse servidor?ao total são 63 estações de trabalho quando em horário de pico.
A lentidão ocorre mesmo com apenas duas ou três estações clientes trabalhando?
2) Qual é a tipologia dessa rede (forneça uma ideia desse cenário), isto é:
a) cabeamento ou wireless?
b) existem switches e roteadores no caminho?
3) as estações clientes possuem placas de rede compatíveis e sem gargalo (10/100/1000 Mbps)?Shitchs GB e placas de rede também GB.
4) Antes de partir para análises mais sofisticadas, fez a análise mais simples de todas que é a mensuração pelo ping?Ping < 1ms
colisão em excessoEstas não verifiquei, vou verificar.
broadcast em excesso
Uplink estreito
Switches em loop
cpu de switches esgotado
Você está usando o The Dude pra acompanhar a memória do hospedeiro, ou da VM Linux? Se é do hospedeiro, tudo bem, vale; mas a VM Linux, como já dissemos, não tem nenhum problema dela estar em 99% de RAM, o Linux sempre faz isso.
Quanto ao disco virtual, há um aplicativo que converte VHD em VHDX, que vai te dar algumas vantagens.
Vou aproveitar pra bater em outra questão: o próprio Firebird. Cara, a menos que tua aplicação realmente exija o Firebird, ele não é, de forma nenhuma, a melhor solução de SGBD. Eu recomendo fortemente que você use outra solução, como o MySQL, o MariaSQL (que basicamente é o MySQL GPL), ou mesmo o Oracle, que se dá muito bem com aplicações ERP.