Eu tenho uma configuração espalhada para lidar com: 3 edifícios externos com roteadores baseados no Tomato Firmware, conectando-se a outro roteador baseado no Tomato como uma configuração de VPN. O roteador do servidor também está em nossa rede LAN privada (como um dispositivo de borda).
Em nossa LAN principal, temos um servidor DHCP em execução em um servidor Linux, oferecendo 192.168.0.0/19 (sim, a máscara de sub-rede é 255.255.224.0!), com o octeto 192.168.2.x / 24 sendo excluído. Em cada site, cada Tomato VPN Client (os roteadores daqui em diante) devem oferecer IPs em um determinado intervalo para seus clientes dentro da sub-rede 192.168.2.x. SiteA é 192.168.2.2-29 (roteador é .1), SiteB é 192.168.2.31-50 (roteador é .30) e SiteC é 192.168.2.52-80 (.51 é o roteador). Os computadores podem se conectar ao nosso servidor sem problemas.
O que está acontecendo, porém, é que, de repente (quando isso funcionou perfeitamente bem antes), eu tenho o roteador do SiteA oferecendo concessões para clientes em outros sites. Como eles estão na mesma rede final (192.168.0.0/19), eles podem acessar servidores em nossa LAN, mas não na Internet.
Como uma correção temporária, eu poderia procurar remotamente os computadores no SiteB e SiteC, e atribuir o gateway padrão para ser os roteadores em cada local. Esta não é uma boa solução, já que impede que outros funcionários visitem o site com seus laptops ou tablets e possam se conectar imediatamente.
Os roteadores não são compilados com suporte para ebtables
, conforme recomendado em alguns outros threads. O objetivo final é que os servidores DHCP ofereçam apenas concessões no lado da LAN de seus próprios roteadores.
Configuração do Cliente VPN do Roteador B
ConfiguraçãodoClienteVPNdoRoteadorA(ORedirecionamentodoTráfegodaInternetfoioriginalmentedesativado;elefoiativadoacimaapenasparatestes)