После использования openVPN у меня есть новое устройство TUN. Я также выполнил несколько шагов в Интернете, чтобы разрешить входящие передачи на мой сервер, однако я не понимаю, как это работает.
IP-адрес:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether b8:27:eb:e2:97:22 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.129/24 brd 192.168.0.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::de8d:8f16:39a0:8bb9/64 scope link
valid_lft forever preferred_lft forever
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
link/ether b8:27:eb:b7:c2:77 brd ff:ff:ff:ff:ff:ff
inet6 fe80::6877:4a6e:7067:da26/64 scope link tentative
valid_lft forever preferred_lft forever
4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
link/none
inet 10.8.8.118 peer 10.8.8.117/32 scope global tun0
valid_lft forever preferred_lft forever
правила ip:
0: from all lookup local
32765: from 192.168.0.129 lookup 128
32766: from all lookup main
32767: from all lookup default
128 таблица:
default via 192.168.0.1 dev eth0
10.8.8.117 dev eth0 scope link
основная таблица:
0.0.0.0/1 via 10.8.8.117 dev tun0
default via 192.168.0.1 dev eth0 metric 202
10.8.8.1 via 10.8.8.117 dev tun0
10.8.8.117 dev tun0 proto kernel scope link src 10.8.8.118
128.0.0.0/1 via 10.8.8.117 dev tun0
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.129 metric 202
198.148.86.170 via 192.168.0.1 dev eth0
локальный стол:
local 10.8.8.118 dev tun0 proto kernel scope host src 10.8.8.118
broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1
local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1
broadcast 192.168.0.0 dev eth0 proto kernel scope link src 192.168.0.129
local 192.168.0.129 dev eth0 proto kernel scope host src 192.168.0.129
broadcast 192.168.0.255 dev eth0 proto kernel scope link src 192.168.0.129
Может кто-нибудь объяснить, по какому маршруту будет проходить пакет? В основном меня смущает таблица 128. Без этого правила и таблицы я не могу подключиться к серверу на моем компьютере по SSH или подключиться к нему из-за пределов нашей сети, когда работает VPN. Каким образом добавление этих двух правил позволяет мне это делать? Что они говорят?
В мире без NAT, без межсетевых экранов с отслеживанием состояния и с каждым интерфейсом, имеющим адреса с общедоступными IP-адресами, в этом нет необходимости. Но мы не живем в этом мире. Мы живем в мире, где обычное соединение обычно проходит через несколько брандмауэров и устройств NAT.
В основном у вас проблема асимметричной маршрутизации.
Асимметричная маршрутизация не является проблемой сама по себе, но вызовет проблемы, когда в маршрутизируемом пути используются трансляция сетевых адресов (NAT) или межсетевые экраны.
Когда клиентское устройство устанавливает ssh-соединение с вашим хостом, оно будет иметь src ip / port destination ip / port в заголовках tcp / ip. Ответные пакеты будут иметь src ip / порт интерфейса ssh, который будет использоваться для ответа, и адрес / порт назначения удаленного хоста. В приведенном здесь примере у вас есть два пути, по которым входящие пакеты могут попасть к вам, и исходящий маршрут по умолчанию отличается от входящего адреса, который будет использоваться. Без ваших добавленных правил отправляется ответный пакет, у него будет другой src ip / порт, который ожидал брандмауэр ssh-клиента в зависимости от того, что было отправлено с исходящим пакетом. Поскольку пункт назначения в исходящем пакете не совпадает с источником в ответе, он может быть отклонен брандмауэром или может не соответствовать чему-то в вашей таблице состояний NAT.
Правила, которые вы устанавливаете, в основном заставляют входящую систему отвечать с интерфейса, на котором она получила запрос, что означает, что все адреса будут правильно совпадать, и пакеты будут разрешены через любые брандмауэры.