= Kan peer på LAN till VPS/molnserver tunnel all input från två andra LAN-system? =
Kan jag göra detta?
Dedikerad WG-box på LAN-tunnlar till VPS/cloud WG-server. Denna lokala WG-box har flera Ethernet-gränssnitt. Kan den ta untunneled input från två andra LAN-boxar och vidarebefordra den genom WG-tunneln till VPS/molnservern? Plus, kan en av dessa andra LAN-boxar SSH till WG-boxen med en annan Ethernet-anslutning?
Sammanfattning av trådbundna gränssnitt för LAN WG-box:
1: till LAN-sidan av routern, för WAN-åtkomst och för SSH med en Mac;
2. Mac via routern, för trafik som ska tunnlas;
3. den andra LAN-boxen, för trafik som ska tunnlas.
Mac-datorn matar ut sin trafik som ska tunnlas till gränssnitt 2 och SSH-trafik på gränssnitt 1; båda dessa gränssnitt ansluter till routern. Gränssnitt 3 ansluts direkt till den andra LAN-boxen. Alla LAN-adresser finns på samma subnät och är statiska adresser.
Problem jag ser hittills: Jag tror att WG-boxen måste NAT trafiken sin tunnel (utöver VPS-servern igen); i så fall något problem där? Och hur kan SSH-trafiken isoleras från tunneln?
Alla LAN-adresser finns på samma subnät och är statiska adresser.
Att ha flera LAN med samma subnät är en dålig idé. Varje LAN bör använda sitt eget subnät. Och WG-boxen ska inte ha flera gränssnitt anslutna till samma subnät.
Du ska inte behöva använda NAT på WG-boxen, istället bör du konfigurera LAN-subnäten i tillåtna-ips på molnet WG-servern.
Edit: ersätts av mitt nästa svar
OK, så här tänker jag nu när du har tänt glödlampan för flera undernät Just nu finns det bara ett undernät, 192.16816. Det finns många lådor/värdar/enheter på den -- telefoner, termostater, datorer, hemmabiokomponenter etc. -- förutom de tre som nämns i min OP (som jag nu kommer att kalla 1_LAN_WG_box, 2_ Mac, och 3_other_LAN_box).
Låt oss säga att 2_Mac blir 172.16.0.6 och 3_other_LAN_box blir 172.17.0.7. LAN WG-boxens ETH1-kontakt finns kvar på 192.16816. Dess ETH2-kontakt blir 172.16.0.2 (2_Macs subnät), och dess ETH3-kontakt blir 172.17.0.1 (gateway på 3_other_LAN_box:s subnät). Det tar bort problemet med lokal NAT.
Jag vill inte ha Mac på VPN hela tiden utan bara ibland som webbklient. Jag tänkte slå på proxyserverns webbläsarfunktion, med LAN WG-rutan som proxy, bara när jag vill använda VPN. Jag tror att jag inte har nämnt ännu att LAN WG-boxen är huvudlös; Jag vill använda Mac för att styra och konfigurera den via SSH. Detsamma gäller för 3_other_LAN_box.
Macen, 172.16.0.6, kommer att SSH till LAN WG-boxen på den senares 192.16816-adress. Jag ska ge huvudroutern en statisk rutt för det. Mac-webbläsaren, när jag vill att den ska använda VPN, kommer att använda LAN WG-boxens ETH2 172.16.0.2-adress som webbläsarproxy.
3_other_LAN_har bara en RJ45-kontakt. Den kommer att använda LAN WG-boxen som en gateway. Om 3_other_LAN_box ansluter till en switch kan Mac-datorn SSH till 3_other_LAN_boxen via en statisk huvudrouter.
Jag antar att detta är min första nätverksdesign! Ett återstående problem är att isolera LAN WG-boxens SSH-trafik från tunneln. Jag har några tankar om det, men om svaret på min övergripande fråga, "Kan det här fungera?"är ja, jag lämnar den frågan till ett annat inlägg. Också för ett annat inlägg kommer WG conf-filernas innehåll att rymma denna LAN-design -- om inte allt fungerar på mitt första försök!
(Jag har försökt göra den här kommentaren tydlig men jag förstår att den innehåller mycket detaljer. Jag uppskattar din hjälp!)
Det finns några aspekter av mitt tidigare svar på 13 timmar. sedan som jag tror troligen inte kommer att fungera, så jag börjar om. Du kan ignorera det svaret om du vill.
Stor bild: Jag har en huvudlös Ubuntu-box ("WGbox") som jag vill använda för att ansluta två lokala enheter, en Mac och en huvudlös dataserver ("DS") till den lokala änden av en WG-tunnel till en WG-server på en moln VPS. DS kommer att tunnlas 24/7, men Macen bara ibland. Både WGbox och DS, eftersom de är huvudlösa, behöver SSH-åtkomst från Mac.
WGbox har fyra RJ45-kontakter. Just nu har jag ett LAN-subnät, 192.168.1.0/24. På grund av WG:s behov av virtuell routing behöver jag minst ett extra subnät för att kunna tunnla två enheter (Mac och DS).
Med tanke på Mac först vill jag ibland tunnla webbtrafik via WGbox och kunna SSH till WGbox när jag inte tunnlar webbtrafik. För närvarande är WGBox:s enda trådbundna gränssnitt som används tilldelat 198.168.1.10 och I SSH till det från Mac som är 198.168.1.200.
Vad sägs om att jag lägger till ett subnät för Mac, med gateway som 172.16.0.1/24 och tilldelar det till ett andra trådbundet gränssnitt på WGbox. När jag vill tunnla Macen ändrar jag Macens IP/gateway till 172.16.0.1/172.16.0.1. Eftersom huvudroutern finns på 192.168-subnätet, skulle jag normalt sett behöva sätta en brygga i dess iptables för att dirigera till en 172.16.0.1. Men eftersom Mac och WGbox är kopplade till samma switch tror jag att jag kan undvika bryggan.
Tycker du att detta fungerar? I så fall går jag vidare till tunnling och SSH-åtkomst för DS-enheten. Om inte, låt mig veta några tankar om hur man åtgärdar det.
"WG-boxen ska inte ha flera gränssnitt anslutna till samma subnät."Varför? Jag bråkar inte, bara gnäller, eftersom jag tror att ett brott mot den regeln skulle förenkla min uppgift och jag skulle vilja veta orsaken bakom det.
Jag kanske tolkar detta fel (lång dag), men vad hindrar dig från att:
- använda WGbox som LAN-gateway för alla enheter som du vill ha permanent dirigerad genom tunneln (du skulle behöva ställa in detta på respektive enheter och antingen ge upp eller komplicera din DHCP-inställning från standard-LAN-gatewayen)?
- ställa in en proxy på WGbox som du kan slå på och av som du vill, på de enheter som du
*vill inte* dirigeras permanent?
Inget behov (IMHO och på en snabb läsning) att bråka med olika subnät, flera nätverksanslutningar etc. Såvida jag inte missar något. Utan koppling till detta skulle jag varmt föreslå att du separerar "IoT"-enheterna (åtminstone) i ett annat nätverk.
Ett problem med att ha alla enheter på samma subnät är kravet på att WGbox ska NAT tunneltrafiken. Jag antar att det inte nödvändigtvis är dödligt, men det verkar slösaktigt i ljuset av att molnets VPS-ände av tunneln också måste NAT. Det komplicerar också WGbox-konfigurationen. Men det undviker komplikationer från att konfigurera de extra subnäten och binda dem i min huvudrouter.
När det gäller att slå på/av tunnling efter behag för webbsurfning från min Mac, så hade jag tänkt sätta upp ett av WGbox-gränssnitten som proxy i min webbläsare (är det det du menar?) Kortfattat självutbildning genom internetsökning. upptäck att för HTTPS utfärdar webbläsaren en CONNECT till proxyservern för att upprätta en tunnel till målwebbservern. Jag är inte säker på vad WGbox kommer att göra med CONNECT. Mer generellt tror jag att det skulle behövas en viss brandväggskonfiguration för att undvika att WGbox tappar eller avvisar Macens webbtrafik innan WireGuard. Eller så kanske AllowedIPs 0.0.0.0/0 för Peer-sektionerna automatiskt skulle konfigurera tillåten åtkomstkontroll.
Det visar sig att det bara finns en enhet (hittills), den huvudlösa dataservern, som jag skulle vilja ha tunnlad för sin kärnfunktion. Jag säger "kärnfunktion"eftersom jag, eftersom jag är huvudlös, behöver SSH-åtkomst till den från en Mac. Det, inte DHCP (som jag kan hantera lätt), är det som komplicerar att ställa in WGbox som dess gateway. Under SSH-sessioner behöver den också helst un-tunnelerad WAN-åtkomst för OS-uppdateringar, etc.
== ÃÂÃÂber diese Community ==
Mittglieder
Uppkopplad
Reddit
