= Est-ce que le peering on LAN to VPS/cloud server tunnel all input from two other LAN systems? =
Puis-je faire ceci?
Boîtier WG dédié sur les tunnels LAN vers le serveur VPS/cloud WG. Cette boîte WG locale dispose de plusieurs interfaces Ethernet. Peut-il prendre une entrée sans tunnel de deux autres boîtiers LAN et la transmettre via le tunnel WG au serveur VPS/cloud ? De plus, l'un de ces autres boîtiers LAN peut-il se connecter en SSH au boîtier WG avec une autre connexion Ethernet ?
Résumé des interfaces filaires du boîtier LAN WG :
1 : vers le côté LAN du routeur, pour l'accès WAN et pour SSH avec un Mac ;
2. le Mac via le routeur, pour le trafic à tunneliser ;
3. l'autre boîtier LAN, pour le trafic à tunneliser.
Le Mac sortirait son trafic à tunneliser sur l'interface 2 et le trafic SSH sur l'interface 1 ; ces deux interfaces se connectent au routeur. L'interface 3 se connecte directement à l'autre boîtier LAN. Toutes les adresses LAN se trouvent sur le même sous-réseau et sont des adresses statiques.
Problèmes que je vois jusqu'à présent : je pense que la boîte WG doit NAT le trafic de son tunneling (en plus du serveur VPS encore ); si oui, y a-t-il un problème? Et comment isoler le trafic SSH du tunnel ?
Toutes les adresses LAN se trouvent sur le même sous-réseau et sont des adresses statiques.
Avoir plusieurs réseaux locaux avec le même sous-réseau est une mauvaise idée. Chaque LAN doit utiliser son propre sous-réseau. Et la boîte WG ne devrait pas avoir plusieurs interfaces connectées au même sous-réseau.
Vous ne devriez pas avoir besoin d'utiliser NAT sur la boîte WG, à la place, vous devez configurer les sous-réseaux LAN dans allow-ips sur le serveur cloud WG.
Edit : remplacé par ma prochaine réponse
OK, voici ma pensée maintenant que vous avez allumé l'ampoule multi-sous-réseaux. Pour le moment, il n'y a qu'un seul sous-réseau, 192.16816. Il y a de nombreux boîtiers/hôtes/appareils dessus - téléphones, thermostats, ordinateurs, composants de cinéma maison, etc. - en plus des trois mentionnés dans mon OP (que j'appellerai maintenant 1_LAN_WG_box, 2_ Mac et 3_other_LAN_box).
Disons que 2_Mac deviendra 172.16.0.6 et 3_other_LAN_box sera 172.17.0.7. Le connecteur ETH1 du boîtier LAN WG reste sur 192.16816. Son connecteur ETH2 devient 172.16.0.2 (sous-réseau de 2_Mac) et son connecteur ETH3 devient 172.17.0.1 (passerelle sur le sous-réseau de 3_other_LAN_box). Cela supprime le problème de NAT local.
Je ne veux pas que le Mac soit constamment sur le VPN, mais seulement occasionnellement en tant que client Web. Je prévoyais d'activer la fonction de navigateur de serveur proxy, avec le boîtier LAN WG comme proxy, uniquement lorsque je souhaite utiliser le VPN. Je pense que je n'ai pas encore mentionné que la boîte LAN WG est sans tête; Je souhaite utiliser le Mac pour le contrôler et le configurer via SSH. Il en va de même pour 3_other_LAN_box.
Le Mac, 172.16.0.6, se connectera en SSH au boîtier LAN WG à l'adresse 192.16816 de ce dernier. Je vais donner au routeur principal une route statique pour cela. Le navigateur Mac, lorsque je veux qu'il utilise le VPN, utilisera l'adresse ETH2 172.16.0.2 de la boîte LAN WG comme proxy de navigateur.
3_other_LAN_n'a qu'un seul connecteur RJ45. Il utilisera le boîtier LAN WG comme passerelle. Si 3_other_LAN_box se connecte à un commutateur, le Mac peut se connecter en SSH à 3_other_LAN_box via une route statique du routeur principal.
Je suppose que c'est ma première conception de réseau ! Un problème restant consiste à isoler le trafic SSH de la boîte LAN WG du tunnel. J'ai quelques réflexions à ce sujet, mais si la réponse à ma question générale, "Est-ce que cela peut fonctionner?"est oui, je vais laisser cette question pour un autre poste. Également pour un autre article, le contenu des fichiers de conf WG s'adaptera à cette conception de réseau local - à moins que tout ne fonctionne lors de ma première tentative !
(J'ai essayé de rendre ce commentaire clair mais je comprends qu'il contient beaucoup de détails. J'apprécie votre aide !)
Il y a certains aspects de ma réponse précédente de 13 h. il y a que je pense susceptible de ne pas fonctionner, donc je recommence. Vous pouvez ignorer cette réponse si vous le souhaitez.
Vue d'ensemble : j'ai une boîte Ubuntu sans tête ("WGbox") que je veux utiliser pour connecter deux appareils locaux, un Mac et un serveur de données sans tête ("DS") à l'extrémité locale d'un tunnel WG vers un serveur WG sur un VPS cloud. DS sera tunnellisé 24h/24 et 7j/7, mais le Mac seulement occasionnellement. La WGbox et la DS, étant sans tête, ont besoin d'un accès SSH depuis le Mac.
WGbox dispose de quatre connecteurs RJ45. En ce moment, j'ai un sous-réseau LAN, 192.168.1.0/24. En raison des besoins de routage virtuel de WG, j'aurai besoin d'au moins un sous-réseau supplémentaire pour tunneler deux appareils (Mac et DS).
Considérant d'abord le Mac, je souhaite tunneliser occasionnellement le trafic Web du navigateur via WGbox et pouvoir utiliser SSH vers WGbox lorsque je ne tunnelise pas le trafic Web. Actuellement, la seule interface câblée de WGBox utilisée est attribuée 198.168.1.10 et I SSH à partir du Mac qui est 198.168.1.200.
Que diriez-vous d'ajouter un sous-réseau pour le Mac, avec une passerelle telle que 172.16.0.1/24 et de l'attribuer à une deuxième interface câblée sur la WGbox. Lorsque je veux tunneliser le Mac, je change l'IP/passerelle du Mac en 172.16.0.1/172.16.0.1. Étant donné que le routeur principal se trouve sur le sous-réseau 192.168, je devrais normalement mettre un pont dans ses iptables pour acheminer vers un 172.16.0.1. Mais comme le Mac et la WGbox sont connectés au même commutateur, je pense que je peux éviter le pont.
Pensez-vous que cela fonctionne? Si c'est le cas, je passerai au tunneling et à l'accès SSH pour le périphérique DS. Si ce n'est pas le cas, n'hésitez pas à me faire part de vos réflexions sur la façon de résoudre le problème.
"La boîte WG ne doit pas avoir plusieurs interfaces connectées au même sous-réseau."Pourquoi? Je ne discute pas, je pleurniche, car je pense que violer cette règle simplifierait ma tâche et j'aimerais en connaître la raison.
J'ai peut-être mal lu (longue journée), mais qu'est-ce qui vous empêche de :
- utiliser la WGbox comme passerelle LAN pour tous les appareils que vous souhaitez acheminer en permanence via le tunnel (vous auriez besoin de le configurer sur les appareils respectifs et d'abandonner ou de compliquer votre configuration DHCP à partir de la passerelle LAN par défaut) ?
- mise en place d'un proxy sur la WGbox que vous pouvez activer et désactiver à votre guise, sur les appareils que vous
*ne veux pas* être routé en permanence ?
Pas besoin (à mon humble avis et sur une lecture rapide) de jouer avec différents sous-réseaux, plusieurs connexions réseau, etc. À moins qu'il ne me manque quelque chose. Sans rapport avec cela, je vous suggérerais chaleureusement de séparer les appareils "IoT"(au moins) dans un réseau différent.
Un problème avec tous les périphériques sur le même sous-réseau est l'exigence pour la WGbox de NAT le trafic du tunnel. Je suppose que ce n'est pas nécessairement fatal, mais cela semble un gaspillage à la lumière de l'extrémité cloud VPS du tunnel devant également NAT. Cela complique également la configuration de WGbox. Mais cela évite les complications liées à la configuration des sous-réseaux supplémentaires et à leur liaison dans mon routeur principal.
Pour ce qui est d'activer/désactiver le tunneling à volonté pour la navigation web depuis mon Mac, j'avais pensé à mettre en place une des interfaces WGbox en tant que proxy dans mon navigateur web (c'est ce que vous voulez dire ?) Bref l'autoformation par la recherche internet j'ai constatez que pour HTTPS, le navigateur émet un CONNECT au serveur proxy pour établir un tunnel vers le serveur Web cible. Je ne sais pas ce que la WGbox fera avec le CONNECT. Plus généralement, je pense qu'il y aurait une configuration de pare-feu nécessaire pour éviter que WGbox ne laisse tomber ou ne rejette le trafic Web du Mac avant WireGuard. Ou peut-être que AllowedIPs 0.0.0.0/0 pour les sections Peer configurerait automatiquement le contrôle d'accès permissif.
Il s'avère qu'il n'y a qu'un seul appareil (jusqu'à présent), le serveur de données sans tête, que j'aimerais tunneliser pour sa fonction principale. Je dis "fonction principale"car, étant sans tête, j'ai besoin d'un accès SSH à partir d'un Mac. C'est cela, et non DHCP (que je peux gérer facilement), qui complique la configuration de WGbox comme passerelle. De plus, pendant les sessions SSH, il a besoin de préférence d'un accès WAN sans tunnel pour les mises à jour du système d'exploitation, etc.
== ÃÂÃÂber diese Community ==
Mitglieder
En ligne
Reddit
