IP правила и таблицы путаницы
После использования 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. Как добавление этих двух правил позволяет мне сделать это? Что они говорят?
1 ответ
В мире без NAT, без брандмауэров с сохранением состояния и с каждым интерфейсом, имеющим адреса с публично маршрутизируемыми IP-адресами, это не было бы необходимо. Но мы не живем в этом мире. Мы живем в мире, где типичное соединение обычно проходит через несколько брандмауэров и устройств NAT.
В основном у вас есть проблема асимметричной маршрутизации.
Асимметричная маршрутизация сама по себе не является проблемой, но она вызовет проблемы, когда трансляция сетевых адресов (NAT) или брандмауэры используются в маршрутизируемом пути.
Когда клиентское устройство устанавливает ssh-соединение с вашим хостом, оно будет иметь IP-адрес / порт назначения src ip / port в заголовках tcp / ip. Ответные пакеты будут иметь src ip / port интерфейса ssh, который будет использоваться для ответа, и адрес / порт назначения удаленного хоста. В приведенном здесь примере у вас есть два способа получить входящие пакеты, хотя исходящий маршрут по умолчанию отличается от входящего адреса, который будет использоваться. Без добавленных вами правил, когда отправляется ответный пакет, он будет иметь другой ip / порт src, чем ожидал брандмауэр ssh-клиента на основании того, что было использовано с исходящим пакетом, который был отправлен. Поскольку пункт назначения в исходящем пакете не совпадает с адресом источника в ответе, он может быть отклонен брандмауэром или может не соответствовать чему-либо в вашей таблице состояний NAT.
Правила, которые вы установили, в основном заставляют входящую систему отвечать от интерфейса, на который она получила запрос, то есть все адреса будут совпадать правильно, и пакеты будут разрешены через любые брандмауэры.