Я про то, что есть мануальная форма маршрутизации. Иными словами если у вас есть какой-то сервер который находится за вашим натом и вы считаете, что к нему никак не пробиться извне потому что вы не настроили проброс портов. Вы ошибаетесь я пробьюсь к нему. Поскольку у вас есть внешний NAT...
... маршрутизация по меткам позволяет добросить пакет до вашего сервера.
Одна история удивительнее другой, особенно про мануальную маршрутизацию и маршрутизацию по меткам (что это?).
Вы ошибаетесь я пробьюсь к нему.
Во-первых, такие заявления (уровня "я пробьюсь") обычно переформулируются в более нейтральные после настойчивой просьбы продемонстрировать заявленное на практике. Во-вторых, оратор забыл уточнить смысл слова "пробьюсь". Что это значит? Пакет из интернета дойдет до сервера? Какой, какому порту предназначен инкапсулированный сегмент? Какой будет эффект? То, что оратор понимает, что NAT и фаерволл - разные вещи - это очень хорошо, жаль только аргументация небезупречна.
Как, подключиться к порту 4321 компьютера 192.168.1.10
Это возможно в следующем случае. Клиент
192.168.1.10 устанавливает соединение с веб-сервером 2.2.2.2, используя порт
4321 со своей стороны (так получилось, совпадение). На натирующем устройстве с глобально маршрутизируемым адресом 1.1.1.1 создается трансляция вида (
192.168.1.10,tcp,
4321)->(1.1.1.1, tcp, 31337). Веб-сервер видит клиента с адресом 1.1.1.1, портом источника 31337, шлет ему данные (сегменты внутри пакетов), которые после натирования фактически направляются клиенту
192.168.1.10, tcp-порт
4321. Далее, если есть злоумышленник 3.3.3.3, которому очень надо послать tcp-сегмент (внутри Ip-пакета) клиенту
192.168.1.10 на порт
4321, то он указывает статический маршрут (см.
Я про то, что есть мануальная форма маршрутизации) до 192.168.1.10/32 (длина префикса не важна, по моему мнению) через 1.1.1.1, и ему лишь остается угадать/подобрать, на какой tcp-порт слать сегмент, чтобы он правильно снатировался. Если 3.3.3.3 и 2.2.2.2 взаимодействуют (обмениваются информацией), он пошлет на
31337 порт. Если нет - то логичнее слать равномерно на все порты и надеяться на удачу.
Как вы, наверное, догадались, рассчитывать на то, что вы сможете запросто послать сегмент на любой порт любого хоста за NAT немного наивно. С другой стороны, полагать, что за NAT вы как за каменной стеной, также наивно.
Кроме того, немного неясны вводные. Если на порту 4321 висит уязвимый сервис и вы хотите эксплуатировать эту уязвимость, то вышеописанную схему вряд ли получится реализовать, если только этот сервис не будет слать данные (байты внутри сегментов внутри пакетов) в интернет. Потому что если он не будет этого делать, то и трансляции на NAT не возникнет. Если только у NAT нет багов или у вас нет агента за этим же NAT, который, подделывая адреса, добьется создания трансляции (
UPnP как вариант). Как видите, вариаций множество.
TL;DR:
Nat is not a security feature.
Простой
