= Czy peer w sieci LAN do VPS/serwera w chmurze może tunelować wszystkie dane wejściowe z dwóch innych systemów LAN? =
Mogę to zrobić?
Dedykowana skrzynka WG w tunelach LAN do serwera VPS/cloud WG. Ta lokalna skrzynka WG ma wiele interfejsów Ethernet. Czy może pobrać nietunelowane dane wejściowe z dwóch innych urządzeń LAN i przesłać je przez tunel WG do serwera VPS/chmury? Ponadto, czy jedno z tych innych urządzeń LAN może SSH połączyć się z urządzeniem WG z innym połączeniem ethernetowym?
Podsumowanie interfejsów przewodowych skrzynki LAN WG:
1: po stronie LAN routera, dla dostępu WAN i SSH z komputerem Mac;
2. Mac przez router, dla ruchu, który ma być tunelowany;
3. druga skrzynka LAN, dla ruchu, który ma być tunelowany.
Mac wyprowadzałby swój ruch, który ma być tunelowany, do interfejsu 2, a ruch SSH do interfejsu 1; oba te interfejsy łączą się z routerem. Interfejs 3 łączy się bezpośrednio z drugim urządzeniem LAN. Wszystkie adresy LAN znajdują się w tej samej podsieci i są adresami statycznymi.
Problemy, które do tej pory zauważyłem: Myślę, że WG box musi NATować ruch podczas tunelowania (oprócz VPS serverit ponownie); jeśli tak, czy jest jakiś problem? I jak można odizolować ruch SSH od tunelu?
Wszystkie adresy LAN znajdują się w tej samej podsieci i są adresami statycznymi.
Posiadanie wielu sieci LAN z tą samą podsiecią to zły pomysł. Każda sieć LAN powinna korzystać z własnej podsieci. A skrzynka WG nie powinna mieć wielu interfejsów podłączonych do tej samej podsieci.
Nie powinieneś używać NAT na urządzeniu WG, zamiast tego powinieneś skonfigurować podsieci LAN w dozwolonych adresach IP na serwerze WG w chmurze.
Edycja: zastąpiona moją następną odpowiedzią
OK, oto moje przemyślenia teraz, gdy zapaliłeś żarówkę wielu podsieci W tej chwili jest tylko jedna podsieć, 192.16816. Jest na nim wiele skrzynek/hostów/urządzeń - telefony, termostaty, komputery, komponenty kina domowego itp. - oprócz trzech wymienionych w moim OP (które będę teraz nazywać 1_LAN_WG_box, 2_ Mac i 3_inna_skrzynka_LAN).
Powiedzmy, że 2_Mac zmieni się na 172.16.0.6, a 3_other_LAN_box na 172.17.0.7. Złącze ETH1 urządzenia LAN WG pozostaje na adresie 192.16816. Jego złącze ETH2 zmienia się na 172.16.0.2 (podsieć 2_Mac), a złącze ETH3 na 172.17.0.1 (brama w podsieci 3_other_LAN_box). To eliminuje problem z lokalnym NAT.
Nie chcę, aby Mac był cały czas podłączony do VPN, ale tylko od czasu do czasu jako klient sieciowy. Planowałem włączyć funkcję przeglądarki serwera proxy, z urządzeniem LAN WG jako proxy, tylko wtedy, gdy chcę korzystać z VPN. Chyba jeszcze nie wspomniałem, że LAN WG box jest bezgłowy; Chcę używać komputera Mac do sterowania i konfigurowania go przez SSH. To samo dotyczy 3_other_LAN_box.
Mac, 172.16.0.6, połączy się przez SSH z urządzeniem LAN WG pod jego adresem 192.16816. W tym celu dam głównemu routerowi statyczną trasę. Przeglądarka Mac, kiedy chcę, aby korzystała z VPN, użyje adresu ETH2 172.16.0.2 urządzenia LAN WG jako serwera proxy przeglądarki.
3_other_LAN_ma tylko jedno złącze RJ45. Użyje urządzenia LAN WG jako bramy. Jeśli 3_other_LAN_box łączy się z przełącznikiem, komputer Mac może SSH połączyć się z 3_other_LAN_box przez główną trasę statyczną routera.
To chyba mój pierwszy projekt sieciowy! Pozostałym problemem jest odizolowanie ruchu SSH skrzynki LAN WG od tunelu. Mam kilka przemyśleń na ten temat, ale jeśli odpowiedź na moje ogólne pytanie: „Czy to zadziała?” jest tak, zostawię ten problem na inny post. Również w innym poście będzie zawartość plików konfiguracyjnych WG obsługujących ten projekt sieci LAN - chyba że wszystko zadziała przy mojej pierwszej próbie!
(Starałem się, aby ten komentarz był jasny, ale rozumiem, że zawiera on wiele szczegółów. Doceniam twoją pomoc!)
Jest kilka aspektów mojej poprzedniej odpowiedzi z 13 godzin. temu, które moim zdaniem prawdopodobnie nie zadziałają, więc zaczynam od nowa. Możesz zignorować tę odpowiedź, jeśli chcesz.
Pełny obraz: Mam bezgłowe urządzenie Ubuntu („WGbox”), którego chcę użyć do połączenia dwóch lokalnych urządzeń, komputera Mac i bezgłowego serwera danych („DS”) z lokalnym końcem tunelu WG do serwera WG na VPS w chmurze. DS będzie tunelowany 24 godziny na dobę, 7 dni w tygodniu, ale Mac tylko okazjonalnie. Zarówno WGbox, jak i DS, jako bezgłowe, potrzebują dostępu SSH z komputera Mac.
WGbox posiada cztery złącza RJ45. W tej chwili mam jedną podsieć LAN, 192.168.1.0/24. Ze względu na potrzeby WG w zakresie routingu wirtualnego będę potrzebował co najmniej jednej dodatkowej podsieci, aby tunelować dwa urządzenia (Mac i DS).
Biorąc pod uwagę Maca, chcę od czasu do czasu tunelować ruch internetowy przeglądarki przez WGbox i mieć możliwość SSH do WGbox, gdy nie tuneluję ruchu internetowego. Obecnie jedyny używany przewodowy interfejs WGBox jest przypisany do 198.168.1.10 i I SSH do niego z komputera Mac, który jest 198.168.1.200.
A może dodam podsieć dla Maca, z bramą taką jak 172.16.0.1/24 i przypiszę to do drugiego przewodowego interfejsu na WGbox. Kiedy chcę tunelować komputer Mac, zmieniam adres IP/bramę komputera Mac na 172.16.0.1/172.16.0.1. Ponieważ główny router znajduje się w podsieci 192.168, normalnie musiałbym umieścić most w jego iptables, aby przekierować do 172.16.0.1. Ale ponieważ Mac i WGbox są podłączone do tego samego przełącznika, myślę, że mogę uniknąć mostka.
Czy myślisz, że to działa? Jeśli tak, przejdę do tunelowania i dostępu SSH dla urządzenia DS. Jeśli nie, daj mi znać, jak to naprawić.
„skrzynka WG nie powinna mieć wielu interfejsów podłączonych do tej samej podsieci”. Czemu? Nie kłócę się, tylko marudzę, ponieważ uważam, że naruszenie tej zasady uprościłoby mi zadanie i chciałbym poznać przyczynę.
Być może źle to odczytuję (długi dzień), ale co powstrzymuje Cię przed:
- używanie WGbox jako bramki LAN dla wszystkich urządzeń, które chcesz na stałe kierować przez tunel (musisz to ustawić na odpowiednich urządzeniach i albo zrezygnować, albo skomplikować konfigurację DHCP z domyślnej bramki LAN)?
- konfigurowanie proxy na WGbox, które możesz włączać i wyłączać według własnego uznania na urządzeniach, które chcesz
*nie chce* trwale przekierowany?
Nie ma potrzeby (IMHO i szybkiego czytania) bałaganu z różnymi podsieciami, wieloma połączeniami sieciowymi itp. Chyba że czegoś mi brakuje. Niezwiązane z tym gorąco sugerowałbym oddzielenie urządzeń „IoT” (przynajmniej) w innej sieci.
Problem z posiadaniem wszystkich urządzeń w tej samej podsieci polega na tym, że WGbox wymaga NAT ruchu tunelowego. Przypuszczam, że niekoniecznie jest to śmiertelne, ale wydaje się marnotrawstwem w świetle końca tunelu VPS w chmurze, który również wymaga NAT. To również komplikuje konfigurację WGbox. Pozwala to jednak uniknąć komplikacji związanych z konfiguracją dodatkowych podsieci i łączeniem ich w moim głównym routerze.
Jeśli chodzi o włączanie/wyłączanie tunelowania do przeglądania stron internetowych z mojego komputera Mac, pomyślałem o skonfigurowaniu jednego z interfejsów WGbox jako proxy w mojej przeglądarce internetowej (czy to masz na myśli?). znajdź, że dla HTTPS przeglądarka wysyła CONNECT do serwera proxy, aby ustanowić tunel do docelowego serwera WWW. Nie jestem pewien, co WGbox zrobi z CONNECT. Mówiąc bardziej ogólnie, myślę, że wymagana byłaby konfiguracja zapory ogniowej, aby uniknąć odrzucania lub odrzucania ruchu internetowego komputera Mac przez WGbox przed WireGuard. A może AllowedIPs 0.0.0.0/0 dla sekcji Peer automatycznie skonfigurowałoby permisywną kontrolę dostępu.
Okazuje się, że jest tylko jedno urządzenie (jak dotąd), bezgłowy serwer danych, który chciałbym tunelować pod kątem jego podstawowej funkcji. Mówię „podstawowa funkcja”, ponieważ będąc bez głowy, potrzebuję dostępu SSH do niej z komputera Mac. To, a nie DHCP (z którym mogę sobie łatwo poradzić), jest tym, co komplikuje ustawienie WGbox jako jego bramy. Ponadto podczas sesji SSH potrzebuje nietunelowanego dostępu do sieci WAN w celu aktualizacji systemu operacyjnego itp.
== ÃÂÃÂber diese Community ==
Mitglieder
online
Reddit
