= Pode emparelhar na LAN para VPS/servidor em nuvem encapsular todas as entradas de dois outros sistemas LAN? =
Posso fazer isso?
Caixa WG dedicada em túneis LAN para servidor WG VPS/nuvem. Esta caixa WG local possui várias interfaces ethernet. Ele pode receber entrada sem túnel de duas outras caixas LAN e encaminhá-la através do túnel WG para o servidor VPS/nuvem? Além disso, uma dessas outras caixas LAN pode SSH para a caixa WG com outra conexão ethernet?
Resumo das interfaces com fio da caixa LAN WG:
1: para o lado LAN do roteador, para acesso WAN e para SSH com um Mac;
2. o Mac via roteador, para tráfego a ser encapsulado;
3. a outra caixa LAN, para tráfego a ser encapsulado.
O Mac enviaria seu tráfego a ser encapsulado para a interface 2 e o tráfego SSH na interface 1; ambas as interfaces se conectam ao roteador. A interface 3 conecta-se diretamente à outra caixa LAN. Todos os endereços LAN estão na mesma sub-rede e são endereços estáticos.
Problemas que vejo até agora: acho que a caixa WG tem que NAT o tráfego seu tunelamento (além do servidor VPS de novo); se sim, algum problema aí? E como o tráfego SSH pode ser isolado do túnel?
Todos os endereços LAN estão na mesma sub-rede e são endereços estáticos.
Ter várias LANs com a mesma sub-rede é uma má ideia. Cada LAN deve usar sua própria sub-rede. E a caixa WG não deve ter várias interfaces conectadas à mesma sub-rede.
Você não precisa usar NAT na caixa WG, em vez disso, deve configurar as sub-redes LAN em ips permitidos no servidor WG em nuvem.
Editar: substituído pela minha próxima resposta
OK, aqui está o meu pensamento agora que você acendeu a lâmpada multi-sub-redes Agora há apenas uma sub-rede, 192.16816. Existem muitas caixas/hosts/dispositivos nele -- telefones, termostatos, computadores, componentes de home theater, etc. -- além dos três mencionados em meu OP (aos quais agora me referirei como 1_LAN_WG_box, 2_Mac e 3_outra_LAN_caixa).
Digamos que 2_Mac se tornará 172.16.0.6 e 3_other_LAN_box será 172.17.0.7. O conector ETH1 da caixa LAN WG permanece em 192.16816.0.1. Seu conector ETH2 se torna 172.16.0.2 (sub-rede 2_Mac) e seu conector ETH3 se torna 172.17.0.1 (gateway na sub-rede 3_other_LAN_box). Isso remove o problema de NAT local.
Não quero o Mac na VPN o tempo todo, mas apenas ocasionalmente como um cliente da web. Eu estava planejando ativar o recurso de navegador do servidor proxy, com a caixa LAN WG como proxy, somente quando eu quiser usar a VPN. Acho que ainda não mencionei que a caixa LAN WG é headless; Quero usar o Mac para controlá-lo e configurá-lo via SSH. O mesmo se aplica a 3_other_LAN_box.
O Mac, 172.16.0.6, fará SSH para a caixa LAN WG no endereço 192.16816 deste último. Vou dar ao roteador principal uma rota estática para isso. O navegador Mac, quando eu quiser usar a VPN, usará o endereço ETH2 172.16.0.2 da caixa LAN WG como um proxy do navegador.
3_other_LAN_possui apenas um conector RJ45. Ele usará a caixa LAN WG como um gateway. Se 3_other_LAN_box se conectar a um switch, o Mac poderá fazer SSH para 3_other_LAN_box por meio de uma rota estática do roteador principal.
Acho que este é o meu primeiro projeto de rede! Um problema remanescente é isolar o tráfego SSH da caixa LAN WG do túnel. Tenho algumas ideias sobre isso, mas se a resposta à minha pergunta geral, "Isso pode funcionar?"é sim, vou deixar esse assunto para outro post. Também para outro post será o conteúdo dos arquivos WG conf acomodando este design de LAN - a menos que tudo funcione na minha primeira tentativa!
(Tentei deixar este comentário claro, mas entendo que contém muitos detalhes. Agradeço sua ajuda!)
Existem alguns aspectos da minha resposta anterior de 13 horas. atrás que acho que provavelmente não vai funcionar, então estou começando de novo. Você pode ignorar essa resposta, se quiser.
Visão geral: tenho uma caixa Ubuntu sem cabeça ("WGbox") que desejo usar para conectar dois dispositivos locais, um Mac e um servidor de dados sem cabeça ("DS") à extremidade local de um túnel WG para um servidor WG em um nuvem VPS. O DS será encapsulado 24 horas por dia, 7 dias por semana, mas o Mac apenas ocasionalmente. Tanto o WGbox quanto o DS, sendo headless, precisam de acesso SSH do Mac.
WGbox tem quatro conectores RJ45. No momento, tenho uma sub-rede LAN, 192.168.1.0/24. Devido às necessidades de roteamento virtual do WG, precisarei de pelo menos uma sub-rede adicional para encapsular dois dispositivos (Mac e DS).
Considerando o Mac primeiro, quero ocasionalmente encapsular o tráfego da web do navegador via WGbox e ser capaz de SSH para WGbox quando não estou encapsulando o tráfego da web. Atualmente, a única interface com fio do WGBox em uso é atribuída a 198.168.1.10 e eu SSH a ela do Mac, que é 198.168.1.200.
Que tal adicionar uma sub-rede para o Mac, com gateway como 172.16.0.1/24 e atribuí-la a uma segunda interface com fio no WGbox. Quando quero encapsular o Mac, mudo o IP/gateway do Mac para 172.16.0.1/172.16.0.1. Como o roteador principal está na sub-rede 192.168, normalmente eu teria que colocar uma ponte em seu iptables para rotear para 172.16.0.1. Mas como o Mac e o WGbox estão conectados ao mesmo switch, acho que posso evitar a ponte.
Você acha que isso funciona? Nesse caso, passarei para o tunelamento e acesso SSH para o dispositivo DS. Se não, por favor, deixe-me saber quaisquer pensamentos sobre como corrigir.
"a caixa WG não deve ter várias interfaces conectadas à mesma sub-rede."Porque? Não estou discutindo, apenas reclamando, pois acho que violar essa regra simplificaria minha tarefa e gostaria de saber o motivo disso.
Posso estar interpretando mal isso (dia longo), mas o que o impede de:
- usar o WGbox como gateway LAN para todos os dispositivos que você deseja rotear permanentemente através do túnel (você precisaria configurar isso nos respectivos dispositivos e desistir ou complicar a configuração do DHCP do gateway LAN padrão)?
- configurar um proxy no WGbox que você pode ligar e desligar quando quiser, nos dispositivos que você
*não quer* permanentemente roteado?
Não há necessidade (IMHO e em uma leitura rápida) de mexer com diferentes sub-redes, várias conexões de rede, etc. A menos que eu esteja perdendo alguma coisa. Não relacionado a isso, sugiro que você separe os dispositivos "IoT"(pelo menos) em uma rede diferente.
Um problema em ter todos os dispositivos na mesma sub-rede é o requisito para o WGbox fazer NAT no tráfego do túnel. Suponho que isso não seja necessariamente fatal, mas parece um desperdício à luz da nuvem VPS no final do túnel, tendo que NAT também. Também complica a configuração do WGbox. Mas evita complicações ao configurar as sub-redes adicionais e ligá-las ao meu roteador principal.
Quanto a ativar/desativar o tunelamento à vontade para navegação na web do meu Mac, pensei em configurar uma das interfaces WGbox como proxy no meu navegador da web (é isso que você quer dizer?) Em breve auto-educação por pesquisa na Internet I descubra que para HTTPS o navegador emite um CONNECT para o servidor proxy para estabelecer um túnel para o servidor web de destino. Não tenho certeza do que o WGbox fará com o CONNECT. De maneira mais geral, acho que seria necessária alguma configuração de firewall para evitar que o WGbox abandonasse ou rejeitasse o tráfego da Web do Mac antes do WireGuard. Ou talvez AllowedIPs 0.0.0.0/0 para as seções Peer configurariam automaticamente o controle de acesso permissivo.
Acontece que há apenas um dispositivo (até agora), o servidor de dados sem cabeça, que eu gostaria de encapsular para sua função principal. Digo "função principal"porque, sendo sem cabeça, preciso de acesso SSH a ela de um Mac. Isso, não o DHCP (que eu posso lidar facilmente), é o que complica a configuração do WGbox para ser seu gateway. Além disso, durante as sessões SSH, ele precisa preferencialmente de acesso WAN sem túnel para atualizações do sistema operacional, etc.
== ÃÂÃÂber diese Community ==
Mitglieder
On-line
Reddit
