Всех приветствую.

Сразу скажу цель всего моего деяния: хочу подключаться к VPS по VPN, а далее трафик который идет к VPS пусть по второму VPN (сервера Cloudflare, конфиг к которому сгенерен через wgcf). У меня было несколько фундаментально разных попыток сделать это.

Попытка 1:
У меня есть VPS, у нее есть три интерефейса: wg0, wg1, eth0.

К VPS я подключаюсь через wg0, а wg1 - это WireGuard подключаемый к серверам Cloudflare.

То есть я хочу сделать цепочку вида:

Local PC (connects with wg0) → VPS → (connects with wg1) → Cloudflare → Destination.

Мой VPS выступает как будто в роли proxy, но хочу я это сделать через VPNы. Единственная проблема - я могу настроить, только Local PC и VPS.

Когда включаю оба интерфейса wg1 и wg0, то wg0 может совершать хендшейки, но перенаправлять трафик между ними я не осилил. Я каким-то образом видимо должен nat правильно настроить?..

Для настройки интерфейсов, использую я iptables и wg-quick, иногда ip. Если не использовать wg1 и использовать настройку рода iptables -t nat -A POSTROUTING -j MASQUERADE -o eth0, то цепочка становится рабочей и выглядит так:

Local PC (connects with wg0) → VPS (connects with eth0) → Destination.

Возможно ли сделать, то что я хочу (перенаправить трафик далее на второй vpn)? Ну и повторяю проблему - нет доступа к настройкам сервера cloudflare.

Попытка 2:
Вместо того, чтобы поддерживать 2 интерфейса с VPN - я объединил их в один. То есть взял конфиг с wg1 (который к cloudflare подключается), и напихал туда своих пиров, и пирам раскидал публичный ключ этого интерфейса, который легко восстанавливается из приватного.

Тогда конфиг для сервера выглядит следующим образом:

[Interface]
PrivateKey = <key>
Address = 172.16.0.2/32
Address = 2606:4700:110:8f92:848e:9ae:5e1f:db28/128
ListenPort = 33333
DNS = 1.1.1.1
MTU = 1280
#Table = 123

#PostUp = sysctl -w net.ipv4.ip_forward=1
#PostUp = ip rule add iif wg1 table 123 priority 456
#PostDown = ip rule del iif wg1 table 123 priority 456
#PostUp = sysctl -w net.ipv6.conf.all.forwarding=1
#PostUp = ip -6 rule add iif wg1 table 123 priority 456
#PostDown = ip -6 rule del iif wg1 table 123 priority 456

[Peer]
PublicKey = <key>
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = engage.cloudflareclient.com:<port>

[Peer]
PublicKey = <key>
AllowedIPs = 172.16.0.3/32
Endpoint = <ip>:<port>

Конфиг для клиента остался тем же (только публичный ключ у пира поменялся):

[Interface]
Address = 172.16.0.3/24
ListenPort = 33333
PrivateKey = <key>

[Peer]
PublicKey = <key>
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = <ip>:33333

Теперь даже хендшейков не происходит. Пытался делать в аналогии с Multi-Hop WireGuard | Pro Custodibus, но моя проблема естественно, что я не могу настроить что-то на серверах cloudflare. То есть сервер cloudflare для меня черный ящик…
Некоторые настройки закоментированы, потому что, что с ними что без не работает, хотя поведение разное…

====================================

Я не пробовал жестко дебагать, потому что не умею в это, с сетями слаб, если кто-то что может посоветовать буду рад. Про дебагать я имею ввиду следующее: возможно мне хотелось бы уметь полностью отследить пришел ли пакет, прошел ли он через routing table, перешел ли в другой интерфейс, в корректном состоянии он или нет и т.д.

Ну и в целом вопрос можно ли реализовать то, что я хочу? Может я вообще фигню пытаюсь сделать…

Короче нужна ваша помощь. Сам уже не справлюсь, силы на исходе)

Заранее спасибо!

в секцию interface в wgcf.conf добавь table=100. запускай оба конфига через wg-quick, затем

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -j MASQUERADE
ip rule add from wg0_subnet/24 table 100

wg0_subnet нужно заменить на своё

или вместо всего этого просто пробрось порт

если не вышло то пиши дс или тг

Я уже слишком долго долблюсь с этим, поэтому я уже хронологию событий не помню, но насколько помню мне эта настройка наконец разрешила делать и хендшейки для wg0 и заставить работать инет для wg1 одновременно. И мне оказывается маскарадинг надо было на все интерфейсы навесить, чтобы добиться того же результата.

Теперь у меня встала проблема, что если в wg1 прописать AllowedIPs = 0.0.0.0/0, то видимо происходит проблема рода: представим что надо отправить ack к хендшейку, но этот пакет отправляется не ко мне, а обратно на VPN из-за того что туда весь трафик идет.
В итоге у меня выходит, что то в роде симплексного канала связи, лол)

В итоге я весь день провозился с тем, чтобы понять что нужно поставить в AllowedIPs. То есть я как будто бы должен разрешить все КРОМЕ адресов моих локальных компьютеров и адресов wg0.

Так и сделал, зашел на данный замечательный сайт WireGuard AllowedIPs Calculator | Pro Custodibus, и разрешил все айпишники кроме моего (под моим имею ввиду не VPS), и адреса wg0. Сеть намертво умирает. Никуда не могу подключиться. Пытался только wg0 заблокировать, или только свой - тоже нет результата.

Попробовал, вбить айпишники сервера ifconfig.co и о магия когда я туда захожу через локальный пк, я действительно захожу через cloudflare.

Я в каком-то смысле могу реализовать таким образом что-то рода split tunneling, явно избирая какие айпишники пойдут через cloudflare а какие нет. Для интереса я через cloudflare все айпи гугла забил

AllowedIPs = 8.8.4.0/24, 8.8.8.0/24, 8.34.208.0/20, 8.35.192.0/20, 23.236.48.0/20, 23.251.128.0/19, 34.0.0.0/15, 34.2.0.0/16, 34.3.0.0/23, 34.3.3.0/24, 34.3.4.0/24, 34.3.8.0/21, 34.3.16.0/20, 34.3.32.0/19, 34.3.64.0/18, 34.4.0.0/14, 34.8.0.0/13, 34.16.0.0/12, 34.32.0.0/11, 34.64.0.0/10, 34.128.0.0/10, 35.184.0.0/13, 35.192.0.0/14, 35.196.0.0/15, 35.198.0.0/16, 35.199.0.0/17, 35.199.128.0/18, 35.200.0.0/13, 35.208.0.0/12, 35.224.0.0/12, 35.240.0.0/13, 57.140.192.0/18, 64.15.112.0/20, 64.233.160.0/19, 66.22.228.0/23, 66.102.0.0/20, 66.249.64.0/19, 70.32.128.0/19, 72.14.192.0/18, 74.125.0.0/16, 104.154.0.0/15, 104.196.0.0/14, 104.237.160.0/19, 107.167.160.0/19, 107.178.192.0/18, 108.59.80.0/20, 108.170.192.0/18, 108.177.0.0/17, 130.211.0.0/16, 136.22.160.0/20, 136.22.176.0/21, 136.22.184.0/23, 136.22.186.0/24, 136.124.0.0/15, 142.250.0.0/15, 146.148.0.0/17, 152.65.208.0/22, 152.65.214.0/23, 152.65.218.0/23, 152.65.222.0/23, 152.65.224.0/19, 162.120.128.0/17, 162.216.148.0/22, 162.222.176.0/21, 172.110.32.0/21, 172.217.0.0/16, 172.253.0.0/16, 173.194.0.0/16, 173.255.112.0/20, 192.158.28.0/22, 192.178.0.0/15, 193.186.4.0/24, 199.36.154.0/23, 199.36.156.0/24, 199.192.112.0/22, 199.223.232.0/21, 207.223.160.0/20, 208.65.152.0/22, 208.68.108.0/22, 208.81.188.0/22, 208.117.224.0/19, 209.85.128.0/17, 216.58.192.0/19, 216.73.80.0/20, 216.239.32.0/19

Хз кому это пригодится, но не суть.

Я все же не умею абсолютно весь трафик перенаправлять. Поковырялся с wireshark’ом и смотрел на разницу между рабочей и нерабочей версией. В итоге пришлось банить айпишники cloudflare еще, потому что в рабочей версии запрос идет на eth0, а в нерабочей на wg1. Тоже не помогло.

Эту опцию не использовал, потому что не супер понимаю, что она делает. Еще не добрался до этого, но пока что хоть какой-то прогресс.

А контакты где можно найти?)

в лс свой пиши

в дсе ник как и на форуме Fanarill

жду приема

Текста много, читал не очень внимательно, но что могу сказать:

1. Нужно проверить, что хост готов форвардить пакеты

cat /proc/sys/net/ipv4/ip_forward

2. Нужно проверить, что хост точно готов форвардить пакеты

sudo nft list ruleset
sudo iptables -L

И посмотреть, чтобы FORWARD либо по умолчанию, либо по специальному правилу для wg0 принимало
3. Это впн, значит надо чтобы адрес переписывался по дороге, об этом позаботится

iptables -t nat -A POSTROUTING -j MASQUERADE -o wg1

что, как я понял, уже делается
4. И последнее, но самое главное, надо чтобы все пакеты отсылались в какой нужно интерфейс.
Если используется wg или wg-quick, то он сам пытается угадать, куда что посылать, но, например, systemd-networkd этого не делает, и надо прописывать отдельно
Но даже с wg*, на двух интерфейсах он может не угадать, что куда надо:

• default в wg1
• wg0_subnet/24 в wg0
• И, о чём я выше не увидел упоминания, домашнюю сеть и эндпоинт варпа в eth0

Чтобы посмотреть подробнее присылай

ip route

Это необязательно. Тут довольно простой роутинг, можно обойтись без правил.

Это не обязательно. Более точные адреса (например 8.8.4.0/24) и так будут с более высоким приоритетом, чем общий 0.0.0.0/0

а как? мы уже сделали как я писал

Да я там в середине описал

Как видно, чтобы определить, куда посылать пакет, хватает только адреса назначения, а с этим справится и обычный ip route.

Это, естественно, подразумевая, что мы не против, чтобы вся vps в интернет ходила через wg1.

Если нужно только из wg0 в wg1, то да, либо ip rule, либо через iptables руководить пакетами.
Хотя мне в таком случае нравится запихнуть это всё хозяйство в network namespace, и там по первому сценарию (без третьего пункта, это остаётся в главном неймспейсе). Мне кажется это проще пониманием объять, чем комплексные правила роутинга/фаервола; заодно и killswitch бесплатный.

если вы хотите default route на wg1 в основной таблице то без ip rule не обойтись, default route на wg1 как минимум убьёт ssh на vps

должен об этом позаботиться.
Ещё можно к ssh через wg0 подключаться. кроме всяких резервных-каналов-связи, вроде ssh over tor.
Если уж совсем пожар и wg0 отлетел совсем, то хостерский vnc есть.

ничего не понял

Когда мы подключаемся к впс по ссш, мы, предположительно, делаем это со своего пк из домашней сети. То есть роутинг там аналогичный ваергарду, который создаёт wg0:
домашняя сеть → впс
Соответственно, роутинг для такого маршрута у нас уже уже должен быть (иначе wg0 не будет работать) и впс знает, что пакеты с ответами (для ссш сессии или исходящего трафика домашнего ваергарда), предназначеные в домашнюю сеть, нужно отправлять в интерфейс eth0.