У меня проблемы с доступом к удаленным ресурсам с помощью клиента Cato VPN. Подсеть, к которой я подключаюсь через VPN, выглядит как
192.168.1.0/24
192.168.2.0/24
...
, а мой домашний сетевой интерфейс / сеть выглядит как
wlp58s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.98 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fe80::e306:14d0:1888:c6b7 prefixlen 64 scopeid 0x20<link>
inet6 2604:2000:12c1:c42a:0:a0c3:8dc2:729c prefixlen 128 scopeid 0x0<global>
inet6 2604:2000:12c1:c42a:14a4:c462:d46a:8396 prefixlen 64 scopeid 0x0<global>
inet6 2604:2000:12c1:c42a:8c06:b847:efda:159a prefixlen 64 scopeid 0x0<global>
ether 9c:b6:d0:d5:24:05 txqueuelen 1000 (Ethernet)
RX packets 1382636 bytes 1411037937 (1.4 GB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 354583 bytes 73040708 (73.0 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
, когда я пытаюсь выйти 192.168.1.11
, я получаю IP-адрес сервера не может быть найдена ошибка. Я считаю, что проблема в том, что 192.168.1.11
ищется локально в моей домашней сети, а не через VPN. Одним из решений было бы изменить мою домашнюю сеть на что-то похожее на 192.168.7.0/24
, но мне интересно, есть ли другие варианты?
Выходные данные для ip route
с активным клиентом -
default dev tun0
default via 192.168.1.1 dev wlp58s0 proto dhcp metric 600
45.62.183.62 via 192.168.1.1 dev wlp58s0
169.254.0.0/16 dev wlp58s0 scope link metric 1000
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.1.0/24 dev wlp58s0 proto kernel scope link src 192.168.1.98 metric 600
192.168.1.4 dev tun0
Без vpn ip route
показывает
default via 192.168.1.1 dev wlp58s0 proto dhcp metric 600
169.254.0.0/16 dev wlp58s0 scope link metric 1000
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.1.0/24 dev wlp58s0 proto kernel scope link src 192.168.1.98 metric 600
Вы можете увидеть проблему в ip route
. Номер 6 говорит, что маршрут ко всем 192.168.1.0/24
IP-адресам находится на устройстве wlp58s0
. Это имеет приоритет над правилом 1, которое говорит, что шлюзом по умолчанию является tun0
(VPN). Похоже, вы правильно диагностировали проблему.
Обычно VPN не использует подсеть, которая является настолько распространенной, потому что она будет подвержена таким проблемам. Если вы когда-либо находитесь в сети, где вы не контролируете IP-адреса, такие как общедоступный Wi-Fi, вы не сможете использовать VPN.
Лучшим решением, вероятно, было бы изменить подсеть VPN на нечто более уникальное, например 10.X.Y.0/24
, и настроить правила брандмауэра таким образом, чтобы эта подсеть имела доступ к удаленной подсети 192.168.1.0/24
.
Если это не вариант, вы можете изменить свою домашнюю подсеть, но это не переносимое решение.
Наконец, вы можете удалить правило:
192.168.1.0/24 dev wlp58s0 proto kernel scope link src 192.168.1.98 metric 600
Это решит вашу проблему, но вам будет стоить доступ к вашей локальной подсети. Кроме того, связываться с таблицами маршрутизации вручную рискованно, если вы плохо разбираетесь в сетях.