= È possibile eseguire il peering su LAN verso VPS/server cloud tramite tunneling di tutti gli input provenienti da altri due sistemi LAN? =
Posso farlo?
Box WG dedicato sui tunnel LAN al server VPS/cloud WG. Questa scatola WG locale ha più interfacce Ethernet. Può prendere l'input non tunnelizzato da altri due box LAN e inoltrarlo attraverso il tunnel WG al server VPS/cloud? Inoltre, uno di questi altri box LAN può collegarsi tramite SSH al box WG con un'altra connessione Ethernet?
Riepilogo delle interfacce cablate della scatola LAN WG:
1: lato LAN del router, per accesso WAN e per SSH con un Mac;
2. il Mac tramite il router, per il traffico da tunnelizzare;
3. l'altro box LAN, per il traffico da tunnelizzare.
Il Mac invierebbe il traffico da sottoporre a tunnel all'interfaccia 2 e il traffico SSH all'interfaccia 1; entrambe queste interfacce si connettono al router. L'interfaccia 3 si collega direttamente all'altro box LAN. Tutti gli indirizzi LAN si trovano sulla stessa subnet e sono indirizzi statici.
Problemi che vedo finora: penso che la casella WG debba NAT il traffico il suo tunneling (oltre al server VPS di nuovo); se si, c'è qualche problema? E come si può isolare il traffico SSH dal tunnel?
Tutti gli indirizzi LAN si trovano sulla stessa subnet e sono indirizzi statici.
Avere più LAN con la stessa sottorete è una cattiva idea. Ogni LAN dovrebbe utilizzare la propria sottorete. E la scatola WG non dovrebbe avere più interfacce collegate alla stessa sottorete.
Non dovrebbe essere necessario utilizzare NAT sulla casella WG, invece è necessario configurare le sottoreti LAN in ips consentiti sul server cloud WG.
Modifica: sostituito dalla mia prossima risposta
OK, ecco cosa penso ora che hai acceso la lampadina delle sottoreti multiple In questo momento c'è solo una sottorete, 192.16816. Ci sono molti box/host/dispositivi su di esso - telefoni, termostati, computer, componenti home theater, ecc. - oltre ai tre menzionati nel mio OP (che ora chiamerò 1_LAN_WG_box, 2_ Mac e 3_altro_box_LAN).
Diciamo che 2_Mac diventerà 172.16.0.6 e 3_other_LAN_box sarà 172.17.0.7. Il connettore ETH1 del box LAN WG rimane su 192.16816. Il suo connettore ETH2 diventa 172.16.0.2 (sottorete di 2_Mac) e il suo connettore ETH3 diventa 172.17.0.1 (gateway sulla sottorete di 3_other_LAN_box). Ciò rimuove il problema del NAT locale.
Non voglio il Mac sulla VPN tutto il tempo, ma solo occasionalmente come client web. Avevo intenzione di attivare la funzione browser del server proxy, con la casella LAN WG come proxy, solo quando voglio utilizzare la VPN. Penso di non aver ancora detto che la scatola LAN WG è senza testa; Voglio usare il Mac per controllarlo e configurarlo tramite SSH. Lo stesso vale per 3_other_LAN_box.
Il Mac, 172.16.0.6, invierà SSH alla casella LAN WG all'indirizzo 192.16816 di quest'ultima. Darò al router principale un percorso statico per quello. Il browser Mac, quando voglio che utilizzi la VPN, utilizzerà l'indirizzo ETH2 172.16.0.2 della scatola LAN WG come proxy del browser.
3_other_LAN_ha un solo connettore RJ45. Utilizzerà la scatola LAN WG come gateway. Se 3_other_LAN_box si connette a uno switch, il Mac potrebbe collegarsi tramite SSH a 3_other_LAN_box tramite un percorso statico del router principale.
Immagino che questo sia il mio primo progetto di rete! Un problema rimanente è l'isolamento del traffico SSH della LAN WG box dal tunnel. Ho alcuni pensieri su questo, ma se la risposta alla mia domanda generale, "Può funzionare?"è sì, lascerò questo problema per un altro post. Anche per un altro post ci sarà il contenuto dei file di configurazione WG che si adatta a questo progetto LAN, a meno che non funzioni tutto al mio primo tentativo!
(Ho cercato di chiarire questo commento ma capisco che contiene molti dettagli. Apprezzo il tuo aiuto!)
Ci sono alcuni aspetti della mia precedente risposta di 13 ore. fa che penso che probabilmente non funzionerà, quindi ricomincio da capo. Puoi ignorare quella risposta se vuoi.
Immagine generale: ho una scatola Ubuntu senza testa ("WGbox") che voglio utilizzare per connettere due dispositivi locali, un Mac e un server dati senza testa ("DS") all'estremità locale di un tunnel WG a un server WG su un VPS cloud. Il DS sarà sottoposto a tunneling 24 ore su 24, 7 giorni su 7, ma il Mac solo occasionalmente. Sia WGbox che DS, essendo senza testa, necessitano dell'accesso SSH dal Mac.
WGbox ha quattro connettori RJ45. In questo momento ho una sottorete LAN, 192.168.1.0/24. A causa delle esigenze di routing virtuale di WG, avrò bisogno di almeno una sottorete aggiuntiva per eseguire il tunneling di due dispositivi (Mac e DS).
Considerando prima il Mac, voglio occasionalmente eseguire il tunneling del traffico web del browser tramite WGbox ed essere in grado di eseguire SSH su WGbox quando non sto eseguendo il tunneling del traffico web. Attualmente l'unica interfaccia cablata del WGBox in uso è assegnata a 198.168.1.10 e I SSH ad essa dal Mac che è 198.168.1.200.
Che ne dici di aggiungere una sottorete per il Mac, con gateway come 172.16.0.1/24 e assegnarla a una seconda interfaccia cablata sul WGbox. Quando voglio eseguire il tunneling del Mac, cambio l'IP/gateway del Mac in 172.16.0.1/172.16.0.1. Poiché il router principale si trova sulla sottorete 192.168, normalmente dovrei inserire un bridge nel suo iptables per indirizzare a un indirizzo 172.16.0.1. Ma poiché il Mac e il WGbox sono collegati allo stesso switch, penso di poter evitare il bridge.
Pensi che funzioni? In tal caso, passerò al tunneling e all'accesso SSH per il dispositivo DS. In caso contrario, fatemi sapere eventuali pensieri su come risolvere.
"la scatola WG non dovrebbe avere più interfacce connesse alla stessa sottorete."Perché? Non sto litigando, sto solo piagnucolando, perché penso che violare quella regola semplificherebbe il mio compito e vorrei sapere il motivo.
Potrei interpretare male questo (lunga giornata), ma cosa ti impedisce di:
- utilizzando la WGbox come gateway LAN per tutti i dispositivi che si desidera instradare in modo permanente attraverso il tunnel (dovresti configurarlo sui rispettivi dispositivi e rinunciare o complicare la configurazione DHCP dal gateway LAN predefinito)?
- impostare un proxy sulla WGbox che puoi attivare e disattivare a tuo piacimento, sui dispositivi che desideri
*non vuoi* essere indirizzato in modo permanente?
Non c'è bisogno (IMHO e su una lettura veloce) di scherzare con diverse sottoreti, più connessioni di rete ecc. A meno che non mi manchi qualcosa. Non correlato a questo, ti suggerirei caldamente di separare i dispositivi "IoT"(almeno) in una rete diversa.
Un problema con l'avere tutti i dispositivi sulla stessa sottorete è il requisito per il WGbox di NAT il traffico del tunnel. Suppongo che non sia necessariamente fatale, ma sembra uno spreco alla luce della fine del tunnel VPS cloud che deve anche NAT. Inoltre complica la configurazione di WGbox. Ma evita complicazioni derivanti dall'impostazione delle sottoreti aggiuntive e dal loro legame nel mio router principale.
Per quanto riguarda l'attivazione/disattivazione del tunneling a piacimento per la navigazione Web dal mio Mac, avevo pensato di configurare una delle interfacce WGbox come proxy nel mio browser Web (è questo che intendi?) In breve autoeducazione tramite la ricerca su Internet I scopri che per HTTPS il browser invia un CONNECT al server proxy per stabilire un tunnel verso il server web di destinazione. Non sono sicuro di cosa farà il WGbox con il CONNECT. Più in generale, penso che sarebbe necessaria una configurazione del firewall per evitare che WGbox cada o rifiuti il traffico web del Mac prima di WireGuard. O forse AllowedIPs 0.0.0.0/0 per le sezioni Peer configurerebbe automaticamente il controllo di accesso permissivo.
Si scopre che c'è solo un dispositivo (finora), il server di dati senza testa, che vorrei tunneling per la sua funzione principale. Dico "funzione principale"perché, essendo senza testa, ho bisogno dell'accesso SSH da un Mac. Quello, non DHCP (che posso gestire facilmente), è ciò che complica l'impostazione di WGbox come gateway. Inoltre, durante le sessioni SSH, necessita preferibilmente di un accesso WAN senza tunnel per gli aggiornamenti del sistema operativo, ecc.
== ÃÂÃÂber diese Community ==
Mitglider
in linea
Reddit
