История изменений
Исправление Pinkbyte, (текущая версия) :
Машины, куда ты пробрасываешь порт шлют ответы через другой шлюз - а тот скорее всего их не пропускает, или NAT-и в другой IP-адрес, который источник трафика не ожидает увидеть.
Например возьмем такую схему
Интернет Интернет
| |
GW1 GW2
(192.168.0.1) | | (172.16.0.1)
| |
(192.168.0.10) | (10.0.0.2) (10.0.0.1) | (172.16.0.10)
PC1 --------------------------- PC2
За шлюзами GW1 и GW2 - интернет. Для простоты также предположим, что у GW1 и GW2 на линках в сторону Интернета - публичные IP-адреса.
В локалку соответственно у GW1 - 192.168.0.1, у GW2 - 172.16.0.1. PC1 и PC2 - это устройства, между которыми организован туннель. Их адреса можно увидеть на схеме по аналогии. Адреса 10.0.0.1 и 10.0.0.2 - это адреса на туннельном линке.
Трафик(допустим с адреса 1.1.1.1) приходит на GW2, NAT-ится(DNAT) в 10.0.0.2, доходит до него. PC1 смотрит в таблицу маршрутизации, видит что 1.1.1.1 в ней нет, смотрит маршрут по умолчанию - он ведет через GW1 в Интернет, шлет туда ответ.
В результате в лучшем случае ответный трафик приходит на 1.1.1.1 с публичного адреса GW1(а должен - с публичного адреса GW2). Итог: трафик отбрасывается файрволом на 1.1.1.1.
Также, в некоторых случаях, он может быть отброшен еще раньше - если какой-то маршрутизатор по пути дропает INVALID-соединения в conntrack-е или его аналогах. Это может быть даже GW1, ибо с его стороны это выглядит как попытка отправить ответный пакет без запроса(так как запрос через него не проходил)
Сделав SNAT, ты подменил адрес 1.1.1.1 на локальный адрес, в результате чего у тебя и запросы и ответы пошли по туннельному линку. Но ты на сервере куда делаешь DNAT лишился сведений с какого адреса из Интернета пришли запросы. Если тебя это устраивает - можешь так и оставить. Если нет - нужно крутить policy based routing.
Исправление Pinkbyte, :
Машины, куда ты пробрасываешь порт шлют ответы через другой шлюз - а тот скорее всего их не пропускает, или NAT-и в другой IP-адрес, который источник трафика не ожидает увидеть.
Например возьмем такую схему
Интернет Интернет
| |
GW1 GW2
(192.168.0.1) | | (172.16.0.1)
| |
(192.168.0.10) | (10.0.0.2) (10.0.0.1) | (172.16.0.10)
PC1 --------------------------- PC2
За шлюзами GW1 и GW2 - интернет. Для простоты также предположим, что у GW1 и GW2 на линках в сторону Интернета - публичные IP-адреса.
В локалку соответственно у GW1 - 192.168.0.1, у GW2 - 172.16.0.1. PC1 и PC2 - это устройства, между которыми организован туннель. Их адреса можно увидеть на схеме по аналогии. Адреса 10.0.0.1 и 10.0.0.2 - это адреса на туннельном линке.
Трафик(допустим с адреса 1.1.1.1) приходит на GW2, NAT-ится(DNAT) в 10.0.0.2, доходит до него. PC1 смотрит в таблицу маршрутизации, видит что 1.1.1.1 в ней нет, смотрит маршрут по умолчанию - он ведет через GW1 в Интернет, шлет туда ответ.
В результате в лучшем случае ответный трафик приходит на 1.1.1.1 с публичного адреса GW1(а должен - с публичного адреса GW2). Итог: трафик отбрасывается файрволом на 1.1.1.1.
Также, в некоторых случаях, он может быть отброшен еще раньше - если какой-то маршрутизатор по пути дропает INVALID-соединения в conntrack-е или его аналогах. Это может быть даже GW1, ибо с его стороны это выглядит как попытка отправить ответный пакет без запроса(так как запрос через него не проходил)
Сделав SNAT, ты подменил адрес 1.1.1.1 на локальный адрес, в результате чего у тебя и запросы и ответы пошли по туннельному линку. Но ты на сервере куда делаешь DNAT лишился сведений с какого адреса из Интернета пришли запросы. Если тебя это устраивает - можешь так и оставить. Если нет - нужно крутить policy based routing.
Исправление Pinkbyte, :
Машины, куда ты пробрасываешь порт шлют ответы через другой шлюз - а тот скорее всего их не пропускает, или NAT-и в другой IP-адрес, который источник трафика не ожидает увидеть.
Например возьмем такую схему
Интернет Интернет
| |
GW1 GW2
(192.168.0.1) | | (172.16.0.1)
| |
(192.168.0.10) | (10.0.0.2) (10.0.0.1) | (172.16.0.10)
PC1 --------------------------- PC1
За шлюзами GW1 и GW2 - интернет. Для простоты также предположим, что у GW1 и GW2 на линках в сторону Интернета - публичные IP-адреса.
В локалку соответственно у GW1 - 192.168.0.1, у GW2 - 172.16.0.1. PC1 и PC2 - это устройства, между которыми организован туннель. Их адреса можно увидеть на схеме по аналогии. Адреса 10.0.0.1 и 10.0.0.2 - это адреса на туннельном линке.
Трафик(допустим с адреса 1.1.1.1) приходит на GW2, NAT-ится(DNAT) в 10.0.0.2, доходит до него. PC1 смотрит в таблицу маршрутизации, видит что 1.1.1.1 в ней нет, смотрит маршрут по умолчанию - он ведет через GW1 в Интернет, шлет туда ответ.
В результате в лучшем случае ответный трафик приходит на 1.1.1.1 с публичного адреса GW1(а должен - с публичного адреса GW2). Итог: трафик отбрасывается файрволом на 1.1.1.1.
Также, в некоторых случаях, он может быть отброшен еще раньше - если какой-то маршрутизатор по пути дропает INVALID-соединения в conntrack-е или его аналогах. Это может быть даже GW1, ибо с его стороны это выглядит как попытка отправить ответный пакет без запроса(так как запрос через него не проходил)
Сделав SNAT, ты подменил адрес 1.1.1.1 на локальный адрес, в результате чего у тебя и запросы и ответы пошли по туннельному линку. Но ты на сервере куда делаешь DNAT лишился сведений с какого адреса из Интернета пришли запросы. Если тебя это устраивает - можешь так и оставить. Если нет - нужно крутить policy based routing.
Исправление Pinkbyte, :
Машины, куда ты пробрасываешь порт шлют ответы через другой шлюз - а тот скорее всего их не пропускает, или NAT-и в другой IP-адрес, который источник трафика не ожидает увидеть.
Например возьмем такую схему
Интернет Интернет
| |
GW1 GW2
(192.168.0.1) | | (172.16.0.1)
| |
(192.168.0.10) | (10.0.0.2) (10.0.0.1) | (172.16.0.10
PC1 --------------------------PC1
За шлюзами GW1 и GW2 - интернет. Для простоты также предположим, что у GW1 и GW2 на линках в сторону Интернета - публичные IP-адреса.
В локалку соответственно у GW1 - 192.168.0.1, у GW2 - 172.16.0.1. PC1 и PC2 - это устройства, между которыми организован туннель. Их адреса можно увидеть на схеме по аналогии. Адреса 10.0.0.1 и 10.0.0.2 - это адреса на туннельном линке.
Трафик(допустим с адреса 1.1.1.1) приходит на GW2, NAT-ится(DNAT) в 10.0.0.2, доходит до него. PC1 смотрит в таблицу маршрутизации, видит что 1.1.1.1 в ней нет, смотрит маршрут по умолчанию - он ведет через GW1 в Интернет, шлет туда ответ.
В результате в лучшем случае ответный трафик приходит на 1.1.1.1 с публичного адреса GW1(а должен - с публичного адреса GW2). Итог: трафик отбрасывается файрволом на 1.1.1.1.
Также, в некоторых случаях, он может быть отброшен еще раньше - если какой-то маршрутизатор по пути дропает INVALID-соединения в conntrack-е или его аналогах. Это может быть даже GW1, ибо с его стороны это выглядит как попытка отправить ответный пакет без запроса(так как запрос через него не проходил)
Сделав SNAT, ты подменил адрес 1.1.1.1 на локальный адрес, в результате чего у тебя и запросы и ответы пошли по туннельному линку. Но ты на сервере куда делаешь DNAT лишился сведений с какого адреса из Интернета пришли запросы. Если тебя это устраивает - можешь так и оставить. Если нет - нужно крутить policy based routing.
Исправление Pinkbyte, :
Машины, куда ты пробрасываешь порт шлют ответы через другой шлюз - а то скорее всего их не пропускает, или NAT-и в другой IP-адрес.
Например возьмем такую схему
Интернет Интернет
| |
GW1 GW2
(192.168.0.1) | | (172.16.0.1)
| |
(192.168.0.10) | (10.0.0.2) (10.0.0.1) | (172.16.0.10
PC1 --------------------------PC1
За шлюзами GW1 и GW2 - интернет. Для простоты также предположим, что у GW1 и GW2 на линках в сторону Интернета - публичные IP-адреса.
В локалку соответственно у GW1 - 192.168.0.1, у GW2 - 172.16.0.1. PC1 и PC2 - это устройства, между которыми организован туннель. Их адреса можно увидеть на схеме по аналогии. Адреса 10.0.0.1 и 10.0.0.2 - это адреса на туннельном линке.
Трафик(допустим с адреса 1.1.1.1) приходит на GW2, NAT-ится(DNAT) в 10.0.0.2, доходит до него. PC1 смотрит в таблицу маршрутизации, видит что 1.1.1.1 в ней нет, смотрит маршрут по умолчанию - он ведет через GW1 в Интернет, шлет туда ответ.
В результате в лучшем случае ответный трафик приходит на 1.1.1.1 с публичного адреса GW1(а должен - с публичного адреса GW2). Итог: трафик отбрасывается файрволом на 1.1.1.1.
Также, в некоторых случаях, он может быть отброшен еще раньше - если какой-то маршрутизатор по пути дропает INVALID-соединения в conntrack-е или его аналогах. Это может быть даже GW1, ибо с его стороны это выглядит как попытка отправить ответный пакет без запроса(так как запрос через него не проходил)
Сделав SNAT, ты подменил адрес 1.1.1.1 на локальный адрес, в результате чего у тебя и запросы и ответы пошли по туннельному линку. Но ты на сервере куда делаешь DNAT лишился сведений с какого адреса из Интернета пришли запросы. Если тебя это устраивает - можешь так и оставить. Если нет - нужно крутить policy based routing.
Исправление Pinkbyte, :
Машины, куда ты пробрасываешь порт шлют ответы через другой шлюз - а то скорее всего их не пропускает, или NAT-и в другой IP-адрес.
Например возьмем такую схему
Интернет Интернет
| |
GW1 GW2
(192.168.0.1) | | (172.16.0.1)
| |
(192.168.0.10) | (10.0.0.2) (10.0.0.1) | (172.16.0.10
PC1 --------------------------PC1
За шлюзами GW1 и GW2 - интернет. Для простоты также предположим, что у GW1 и GW2 - публичные IP-адреса. Трафик(допустим с адреса 1.1.1.1) приходит на GW2, NAT-ится(DNAT) в 10.0.0.2, доходит до него. PC1 смотрит в таблицу маршрутизации, видит что 1.1.1.1 в ней нет, смотрит маршрут по умолчанию - он ведет через GW1 в Интернет, шлет туда ответ.
В результате в лучшем случае ответный трафик приходит на 1.1.1.1 с публичного адреса GW1(а должен - с публичного адреса GW2). Итог: трафик отбрасывается файрволом на 1.1.1.1.
Также, в некоторых случаях, он может быть отброшен еще раньше - если какой-то маршрутизатор по пути дропает INVALID-соединения в conntrack-е или его аналогах. Это может быть даже GW1, ибо с его стороны это выглядит как попытка отправить ответный пакет без запроса(так как запрос через него не проходил)
Сделав SNAT, ты подменил адрес 1.1.1.1 на локальный адрес, в результате чего у тебя и запросы и ответы пошли по туннельному линку. Но ты на сервере куда делаешь DNAT лишился сведений с какого адреса из Интернета пришли запросы. Если тебя это устраивает - можешь так и оставить. Если нет - нужно крутить policy based routing.
Исправление Pinkbyte, :
Машины, куда ты пробрасываешь порт шлют ответы через другой шлюз - а то скорее всего их не пропускает, или NAT-и в другой IP-адрес.
Например возьмем такую схему
Интернет Интернет
| |
GW1 GW2
(192.168.0.1) | | (172.16.0.1)
| |
(192.168.0.10) | (10.0.0.2) (10.0.0.1) | (172.16.0.10
PC1 --------------------------PC1
За шлюзами GW1 и GW2 - интернет. Для простоты также предположим, что у GW1 и GW2 - публичные IP-адреса. Трафик(допустим с адреса 1.1.1.1) приходит на GW2, NAT-ится(DNAT) в 10.0.0.2, доходит до него. PC1 смотрит в таблицу маршрутизации, видит что 1.1.1.1 в ней нет, смотрит маршрут по умолчанию - он ведет через GW1 в Интернет, шлет туда ответ.
В результате в лучшем случае ответный трафик приходит на 1.1.1.1 с публичного адреса GW1(а должен - с публичного адреса GW2). Итог: трафик отбрасывается файрволом на 1.1.1.1.
Также, в некоторых случаях, он может быть отброшен еще раньше(если кто-то на пути дропает INVALID-соединения в conntrack-е или его аналогах).
Сделав SNAT, ты подменил адрес 1.1.1.1 на локальный адрес, в результате чего у тебя и запросы и ответы пошли по туннельному линку. Но ты на сервере куда делаешь DNAT лишился сведений с какого адреса из Интернета пришли запросы. Если тебя это устраивает - можешь так и оставить. Если нет - нужно крутить policy based routing.
Исправление Pinkbyte, :
Машины, куда ты пробрасываешь порт шлют ответы через другой шлюз - а то скорее всего их не пропускает, или NAT-и в другой IP-адрес.
Например возьмем такую схему
Интернет Интернет
| |
GW1 GW2
(192.168.0.1) | | (172.16.0.1)
| |
(192.168.0.10) | (10.0.0.2) (10.0.0.1) | (172.16.0.10
PC1 --------------------------PC1
За шлюзами GW1 и GW2 - интернет. Для простоты также предположим, что у GW1 и GW2 - публичные IP-адреса. Трафик(допустим с адреса 1.1.1.1) приходит на GW2, NAT-ится(DNAT) в 10.0.0.2, доходит до него. PC1 смотрит в таблицу маршрутизации, видит что 1.1.1.1 в ней нет, смотрит маршрут по умолчанию - он ведет через GW1 в Интернет, шлет туда ответ.
В результате в лучшем случае ответный трафик приходит на 1.1.1.1 с публичного адреса GW1(а должен - с публичного адреса GW2). В результате трафик отбрасывается файрволом на 1.1.1.1.
Также, в некоторых случаях, он может быть отброшен еще раньше(если кто-то на пути дропает INVALID-соединения в conntrack-е или его аналогах).
Сделав SNAT, ты подменил адрес 1.1.1.1 на локальный адрес, в результате чего у тебя и запросы и ответы пошли по туннельному линку. Но ты на сервере куда делаешь DNAT лишился сведений с какого адреса из Интернета пришли запросы. Если тебя это устраивает - можешь так и оставить. Если нет - нужно крутить policy based routing.
Исходная версия Pinkbyte, :
Машины, куда ты пробрасываешь порт шлют ответы через другой шлюз - а то скорее всего их не пропускает, или NAT-и в другой IP-адрес.
Например возьмем такую схему
Интернет Интернет
| |
GW1 GW2
(192.168.0.1) | | (172.16.0.1)
| |
(192.168.0.10) | (10.0.0.2) (10.0.0.1) | (172.16.0.10
PC1 --------------------------PC1
За шлюзами GW1 и GW2 - интернет. Для простоты также предположим, что у GW1 и GW2 - публичные IP-адреса. Трафик(допустим с адреса 1.1.1.1) приходит на GW2, NAT-ится в 10.0.0.2, доходит до него. PC1 смотрит в таблицу маршрутизации, видит что 1.1.1.1 в ней нет, смотрит маршрут по умолчанию - он ведет через GW1 в Интернет, шлет туда ответ.
В результате в лучшем случае ответный трафик приходит на 1.1.1.1 с публичного адреса GW1(а должен - с публичного адреса GW2). В результате трафик отбрасывается файрволом на 1.1.1.1.
Также, в некоторых случаях, он может быть отброшен еще раньше(если кто-то на пути дропает INVALID-соединения в conntrack-е или его аналогах).
Сделав SNAT, ты подменил адрес 1.1.1.1 на локальный адрес, в результате чего у тебя и запросы и ответы пошли по туннельному линку. Но ты на сервере куда делаешь DNAT лишился сведений с какого адреса из Интернета пришли запросы. Если тебя это устраивает - можешь так и оставить. Если нет - нужно крутить policy based routing.