= Может ли одноранговый доступ в локальной сети к VPS/облачному серверу туннелировать все входные данные из двух других систем локальной сети? знак равно
Я могу сделать это?
Выделенный блок WG в LAN-туннелях к VPS/облачному серверу WG. Этот локальный блок WG имеет несколько интерфейсов Ethernet. Может ли он принимать нетуннелированные входные данные от двух других блоков локальной сети и перенаправлять их через туннель WG на сервер VPS/облачный сервер? Кроме того, может ли один из этих других блоков LAN подключиться по SSH к блоку WG с другим подключением к сети Ethernet?
Краткое описание проводных интерфейсов блока LAN WG:
1: к локальной сети маршрутизатора, для доступа к глобальной сети и для SSH с Mac;
2. Mac через роутер для туннелируемого трафика;
3. другой блок LAN для туннелируемого трафика.
Mac будет выводить свой подлежащий туннелированию трафик на интерфейс 2, а трафик SSH — на интерфейс 1; оба этих интерфейса подключаются к маршрутизатору. Интерфейс 3 подключается напрямую к другому блоку локальной сети. Все адреса LAN находятся в одной подсети и являются статическими адресами.
Проблемы, которые я вижу до сих пор: я думаю, что WG-бокс должен NAT-трафик для своего туннелирования (в дополнение к серверу VPS снова); если да, то какие проблемы? И как можно изолировать SSH-трафик от туннеля?
Все адреса LAN находятся в одной подсети и являются статическими адресами.
Наличие нескольких локальных сетей с одной и той же подсетью — плохая идея. Каждая локальная сеть должна использовать свою собственную подсеть. И коробка WG не должна иметь несколько интерфейсов, подключенных к одной и той же подсети.
Вам не нужно использовать NAT на поле WG, вместо этого вы должны настроить подсети LAN в разрешенных IP-адресах на облачном сервере WG.
Изменить: заменено моим следующим ответом
Хорошо, вот что я думаю теперь, когда вы зажгли лампочку с несколькими подсетями. Прямо сейчас есть только одна подсеть, 192.16816. На нем есть много ящиков/хостов/устройств — телефоны, термостаты, компьютеры, компоненты домашнего кинотеатра и т. д. — в дополнение к трем, упомянутым в моем OP (которые я теперь буду называть 1_LAN_WG_box, 2_ Mac и 3_other_LAN_box).
Допустим, 2_Mac станет 172.16.0.6, а 3_other_LAN_box станет 172.17.0.7. Разъем ETH1 блока LAN WG остается на 192.16816. Его разъем ETH2 становится 172.16.0.2 (подсеть 2_Mac), а его разъем ETH3 становится 172.17.0.1 (шлюз в подсети 3_other_LAN_box). Это устраняет проблему локального NAT.
Я не хочу, чтобы Mac был подключен к VPN все время, а только изредка в качестве веб-клиента. Я планировал включить функцию браузера прокси-сервера с полем LAN WG в качестве прокси-сервера только тогда, когда я хочу использовать VPN. Кажется, я еще не упомянул, что коробка LAN WG безголовая; Я хочу использовать Mac для управления и настройки через SSH. То же самое относится к 3_other_LAN_box.
Mac, 172.16.0.6, подключится по SSH к ящику LAN WG по адресу последнего 192.16816. Для этого я дам основному маршрутизатору статический маршрут. Браузер Mac, когда я хочу, чтобы он использовал VPN, будет использовать адрес ETH2 172.16.0.2 блока LAN WG в качестве прокси-сервера браузера.
3_other_LAN_имеет только один разъем RJ45. Он будет использовать блок LAN WG в качестве шлюза. Если 3_other_LAN_box подключается к коммутатору, то Mac может подключиться к 3_other_LAN_box по SSH через статический маршрут основного маршрутизатора.
Я предполагаю, что это мой первый сетевой дизайн! Остается проблема изоляции SSH-трафика LAN WG box от туннеля. У меня есть некоторые мысли по этому поводу, но если ответить на мой общий вопрос: «Может ли это сработать?» да, я оставлю этот вопрос для другого поста. Также для другого поста будет содержимое файлов WG conf, вмещающее этот дизайн локальной сети - если все это не сработает с моей первой попытки!
(Я пытался сделать этот комментарий понятным, но я понимаю, что он содержит много деталей. Я ценю вашу помощь!)
Есть некоторые аспекты моего предыдущего ответа 13 часов. назад, что, я думаю, скорее всего, не сработает, поэтому я начинаю сначала. Вы можете игнорировать этот ответ, если хотите.
Общая картина: у меня есть безголовая коробка Ubuntu («WGbox»), которую я хочу использовать для подключения двух локальных устройств, Mac и безголового сервера данных («DS») к локальному концу туннеля WG к серверу WG на облачный впс. DS будет туннелироваться круглосуточно и без выходных, а Mac — лишь изредка. И WGbox, и DS, будучи безголовыми, нуждаются в SSH-доступе с Mac.
WGbox имеет четыре разъема RJ45. Сейчас у меня есть одна подсеть LAN, 192.168.1.0/24. Из-за потребностей виртуальной маршрутизации WG мне понадобится как минимум одна дополнительная подсеть для туннелирования двух устройств (Mac и DS).
Принимая во внимание Mac в первую очередь, я хочу иногда туннелировать веб-трафик браузера через WGbox и иметь возможность использовать SSH для WGbox, когда я не туннелирую веб-трафик. В настоящее время единственный используемый проводной интерфейс WGBox назначен 198.168.1.10, и я подключаюсь к нему по SSH с Mac, который равен 198.168.1.200.
Как насчет того, чтобы добавить подсеть для Mac со шлюзом, например 172.16.0.1/24, и назначить его второму проводному интерфейсу на WGbox. Когда я хочу туннелировать Mac, я меняю IP-адрес/шлюз Mac на 172.16.0.1/172.16.0.1. Поскольку основной маршрутизатор находится в подсети 192.168, обычно мне приходится подключать мост к его iptables для маршрутизации на 172.16.0.1. Но поскольку Mac и WGbox подключены к одному и тому же коммутатору, я думаю, что моста можно избежать.
Как вы думаете, это работает? Если это так, я перейду к туннелированию и доступу по SSH для устройства DS. Если нет, пожалуйста, дайте мне знать любые мысли о том, как исправить.
«бокс WG не должен иметь несколько интерфейсов, подключенных к одной и той же подсети». Почему? Я не спорю, а ною, так как считаю, что нарушение этого правила упростило бы мне задачу, и хотелось бы знать причину этого.
Я могу неправильно понять это (долгий день), но что мешает вам:
- использовать WGbox в качестве шлюза локальной сети для всех устройств, которые вы хотите постоянно маршрутизировать через туннель (вам нужно будет настроить это на соответствующих устройствах и либо отказаться, либо усложнить настройку DHCP со шлюза локальной сети по умолчанию)?
- настройка прокси на WGbox, который вы можете включать и выключать по своему усмотрению, на тех устройствах, которые вы
*не хотите* постоянно маршрутизироваться?
Нет необходимости (ИМХО и при быстром прочтении) возиться с разными подсетями, несколькими сетевыми подключениями и т. Д. Если я что-то не упустил. Независимо от этого, я настоятельно рекомендую вам разделить устройства «IoT» (по крайней мере) в другую сеть.
Проблема с наличием всех устройств в одной подсети заключается в том, что WGbox должен выполнять NAT для туннельного трафика. Я предполагаю, что это не обязательно фатально, но кажется расточительным в свете того, что конец туннеля облачного VPS также имеет NAT. Это также усложняет настройку WGbox. Но это позволяет избежать сложностей с настройкой дополнительных подсетей и подключением их к моему основному маршрутизатору.
Что касается включения / выключения туннелирования по желанию для просмотра веб-страниц с моего Mac, я подумал о настройке одного из интерфейсов WGbox в качестве прокси в моем веб-браузере (вы это имеете в виду?). обнаружите, что для HTTPS браузер выдает CONNECT к прокси-серверу, чтобы установить туннель к целевому веб-серверу. Я не уверен, что WGbox будет делать с CONNECT. В более общем плане я думаю, что потребуется некоторая настройка брандмауэра, чтобы избежать сброса или отклонения веб-трафика Mac WGbox до WireGuard. Или, может быть, AllowedIPs 0.0.0.0/0 для разделов Peer автоматически настроит разрешающий контроль доступа.
Оказывается, есть только одно устройство (пока что), безголовый сервер данных, который я хотел бы туннелировать для его основной функции. Я говорю «основная функция», потому что, будучи безголовым, мне нужен SSH-доступ к ней с Mac. Именно это, а не DHCP (с которым я легко справлюсь), усложняет настройку WGbox в качестве шлюза. Кроме того, во время сеансов SSH желательно иметь нетуннелируемый доступ к глобальной сети для обновлений ОС и т. д.
== Сообщество ÃÂÃÂber diese ==
Митглиедер
онлайн
Реддит
