Ладно, вы все вынудили меня снова раздолбать мою сеть и повторить эксперимент
Лабораторное оборудование:
длинк с IP-адресом 1.2.3.1 и DHCP-сервером в роли провайдера
кинетик с «внешним» IP-адресом 1.2.3.4 и внутренним IP-адресом 192.168.0.1/24 в роли бытового роутера
компьютер с IP-адресом 192.168.0.168 в роли «лампочки»
гипотетический пользователь этих бытового роутера и «лампочки», который в сетях ничего не понимает
я в роли злого людя, который устроился на работу к провайдеру специально чтобы хакать лампочки
Никакие порты не проброшены, никакие дополнительные маршруты не добавлены (на скриншоте выше кинетик сам сгенерировал маршруты для своей работы)
Итак, поехали: я в качестве злого людя, хочу найти лампочку и подключиться к ней. Процесс поиска IP-адреса опустим, предположим, что я узнал или узнаю перебором, что это именно 192.168.0.168
Так как я провайдер и имею доступ к своему собственному длинку, я могу творить тёмные дела прямо на нём. Захожу на длинк и пробую подключиться к лампочке:
Ой, Network is unreachable
Ну в общем-то логично, откуда длинку знать, куда отправлять пакеты с локальными IP-адресами
Но я же провайдер и имею полный контроль над длинком!
Не проблема — добавляю маршрут для локальных IP-адресов
Пробую ещё раз:
Опаньки
Ошибка исчезла — длинк успешно отправил пакет, но кинетик его дропнул, потому что межсетевой экран делает своё тёмное дело
В захвате трафика на кинетике можно увидеть, что он успешно получает пакеты, но дальше они дропаются межсетевым экраном
Здесь выяснилось, что выключить межсетевой экран на кинетике нельзя ¯\_(ツ)_/¯
Так что вместо выключения смоделирую немного другую ситуацию:
Пользователь пытался запустить майнкрафт-сервер и своими кривыми руками надобавлял разрешающих правил в роутер
Напомню, что мы проверяем ваше утверждение «как его пакет пролезет сквозь роутер до лампочки, если у меня никакие порты не проброшены?», поэтому в рамках данного эксперимента такое устранение влияния межсетевого экрана тоже корректно
Никакие порты НЕ проброшены
(UPnP кстати тоже не установлен)
Ну, что, ещё одна попытка?
ААААААААААА
Без межсетевого экрана кинетик успешно отроутил пакет из внешней сети во внутреннюю
Скриншот из Wireshark, запущенного на «лампочке», это подтверждает
Удаляем разрешающее правило из межсетевого экрана кинетика — пакеты перестают появляться в Wireshark на «лампочке»
Таким образом, по итогам этого эксперимента в очередной раз повторю — NAT ЭТО НЕ ЗАЩИТА, защищает именно межсетевой экран, без него пакеты до лампочки прекрасно пролезают через роутер
Что такое «без дополнительных настроек»? Если под этой фразой вы имеете в виду отключение фаервола — поздравляю, вы только что сами опровергли свой самый первый комментарий
Почему? Не вижу технических причин, которые помешали бы провайдеру прописать в src свой собственный адрес — роутеры именно для того и существуют, чтобы роутить такие адреса туда-сюда между разными сетями
Вышеупомянутую проверку на практике я делал как раз на кинетике и убеждался, что включение фаерволла начинает дропать пакеты, так что буду считать, что всё ок
Всё так, поэтому я не доверяю не только своей локальной сети, но даже локалхосту (всё, для чего нашлась техническая возможность закрыть и/или зашифровать, у меня закрыто и/или зашифровано, впрочем, я пока ещё не продумал защиту от штук вроде BadUSB или DMA-атак)
Провайдеру и не надо его маршрутизировать, бытовой роутер подключен к нему напрямую, провайдер может просто взять и отправить пакет непосредственно в Ethernet-кабель (или что там у него) без всяких маршрутизаций, если он того захочет
Если я попрошу провайдера попасть на 192.168.0.168 даже со шлюза, то как его пакет пролезет сквозь роутер до лампочки, если у меня никакие порты не проброшены?
А что должно помешать пролезть? Роутер видит входящий пакет на адрес 192.168.0.168 — роутер пересылает пакет на адрес 192.168.0.168, и я не вижу ничего, что остановило бы роутер от совершения такого действия (собственно, его ничего и не останавливает — повторюсь ещё раз, я ПРОВЕРЯЛ описанное вами действие на практике)
Если «снаружи» это провайдер — попросите его отправить какие-нибудь пакеты на внутренний IP-адрес вашей лампочки, и при отключенном на роутере межсетевом экране вы вполне обнаружите эти пакеты в своей локальной сети
Если «снаружи» это интернет — они просто не смогут найти маршрут до вашей лампочки (я не знаю способов отправлять пакеты с внутренними IP-адресами через интернет), а даже если каким-то чудом смогут, то их отфильтрует межсетевой экран провайдера (а попросить провайдера отключить его собственный межсетевой экран вы уже вряд ли сможете)
Защищает не роутер, а межсетевой экран. Если его отключить или криво настроить, роутер всё отроутит и даст доступ к лампочкам даже без проброса портов — я проверял это на практике
То, что в языке программирования этого нет и нужна сторонняя утилита — уже проблема языка программирования
То, что запрет паник возможен (согласно вашим утверждениям) только с добавлением обработки несуществующих ошибок — тоже проблема языка программирования, я не желаю тратить кучу своего времени на обработку того, что не может произойти даже теоретически
Я хочу написать vec[idx] так, чтобы компилятор подтвердил, что я доказал корректность индекса и паники здесь быть не может, или чтобы компилятор сказал мне, что ничего не доказалось и паника возможна — ближе всего к этому подходит крейт no_panic, но он тоже кривой и имеет ложноположительные срабатывания (потому что работает через костыли)
И он бесполезен, потому что вынуждает перегружать код обработкой несуществующих ошибок и всё равно не способен отлавливать паники из сторонних библиотек
Тогда не знаю что вы делаете не так
Ладно, вы все вынудили меня снова раздолбать мою сеть и повторить эксперимент
Лабораторное оборудование:
длинк с IP-адресом 1.2.3.1 и DHCP-сервером в роли провайдера
кинетик с «внешним» IP-адресом 1.2.3.4 и внутренним IP-адресом 192.168.0.1/24 в роли бытового роутера
компьютер с IP-адресом 192.168.0.168 в роли «лампочки»
гипотетический пользователь этих бытового роутера и «лампочки», который в сетях ничего не понимает
я в роли злого людя, который устроился на работу к провайдеру специально чтобы хакать лампочки
Никакие порты не проброшены, никакие дополнительные маршруты не добавлены (на скриншоте выше кинетик сам сгенерировал маршруты для своей работы)
Итак, поехали: я в качестве злого людя, хочу найти лампочку и подключиться к ней. Процесс поиска IP-адреса опустим, предположим, что я узнал или узнаю перебором, что это именно 192.168.0.168
Так как я провайдер и имею доступ к своему собственному длинку, я могу творить тёмные дела прямо на нём. Захожу на длинк и пробую подключиться к лампочке:
Ой, Network is unreachable
Ну в общем-то логично, откуда длинку знать, куда отправлять пакеты с локальными IP-адресами
Но я же провайдер и имею полный контроль над длинком!
Не проблема — добавляю маршрут для локальных IP-адресов
Пробую ещё раз:
Опаньки
Ошибка исчезла — длинк успешно отправил пакет, но кинетик его дропнул, потому что межсетевой экран делает своё тёмное дело
В захвате трафика на кинетике можно увидеть, что он успешно получает пакеты, но дальше они дропаются межсетевым экраном
Здесь выяснилось, что выключить межсетевой экран на кинетике нельзя ¯\_(ツ)_/¯
Так что вместо выключения смоделирую немного другую ситуацию:
Пользователь пытался запустить майнкрафт-сервер и своими кривыми руками надобавлял разрешающих правил в роутер
Напомню, что мы проверяем ваше утверждение «как его пакет пролезет сквозь роутер до лампочки, если у меня никакие порты не проброшены?», поэтому в рамках данного эксперимента такое устранение влияния межсетевого экрана тоже корректно
Никакие порты НЕ проброшены
(UPnP кстати тоже не установлен)
Ну, что, ещё одна попытка?
ААААААААААА
Без межсетевого экрана кинетик успешно отроутил пакет из внешней сети во внутреннюю
Скриншот из Wireshark, запущенного на «лампочке», это подтверждает
Удаляем разрешающее правило из межсетевого экрана кинетика — пакеты перестают появляться в Wireshark на «лампочке»
Таким образом, по итогам этого эксперимента в очередной раз повторю — NAT ЭТО НЕ ЗАЩИТА, защищает именно межсетевой экран, без него пакеты до лампочки прекрасно пролезают через роутер
Какой один клик?
Что такое «без дополнительных настроек»? Если под этой фразой вы имеете в виду отключение фаервола — поздравляю, вы только что сами опровергли свой самый первый комментарий
Вы не забыли отключить фаервол?
Почему? Не вижу технических причин, которые помешали бы провайдеру прописать в src свой собственный адрес — роутеры именно для того и существуют, чтобы роутить такие адреса туда-сюда между разными сетями
Вышеупомянутую проверку на практике я делал как раз на кинетике и убеждался, что включение фаерволла начинает дропать пакеты, так что буду считать, что всё ок
Всё так, поэтому я не доверяю не только своей локальной сети, но даже локалхосту (всё, для чего нашлась техническая возможность закрыть и/или зашифровать, у меня закрыто и/или зашифровано, впрочем, я пока ещё не продумал защиту от штук вроде BadUSB или DMA-атак)
Ради интереса выполнил для default и для всех интерфейсов на своём кинетике — получил сплошные нули. Это плохо?)
Провайдеру и не надо его маршрутизировать, бытовой роутер подключен к нему напрямую, провайдер может просто взять и отправить пакет непосредственно в Ethernet-кабель (или что там у него) без всяких маршрутизаций, если он того захочет
Прекрасно понимаю, но это всё ещё не делает фразу «защита NAT» корректной
Ну то есть вся «защита NAT» держится лишь на вере в отсутствие заинтересованных злых людей ¯\_(ツ)_/¯
Это, конечно, хорошо работает на практике и я ничего против такого общественного блага не имею, но называть это «защитой», пожалуйста, не надо
А что должно помешать пролезть? Роутер видит входящий пакет на адрес 192.168.0.168 — роутер пересылает пакет на адрес 192.168.0.168, и я не вижу ничего, что остановило бы роутер от совершения такого действия (собственно, его ничего и не останавливает — повторюсь ещё раз, я ПРОВЕРЯЛ описанное вами действие на практике)
Если злые люди завелись у провайдера — никакой NAT уже не поможет
До вашего роутера они вообще не дойдут, потому что не смогут найти маршрут, ваш роутер не имеет никакого отношения к этой защите
Для начала определитесь, что такое «снаружи»
Если «снаружи» это провайдер — попросите его отправить какие-нибудь пакеты на внутренний IP-адрес вашей лампочки, и при отключенном на роутере межсетевом экране вы вполне обнаружите эти пакеты в своей локальной сети
Если «снаружи» это интернет — они просто не смогут найти маршрут до вашей лампочки (я не знаю способов отправлять пакеты с внутренними IP-адресами через интернет), а даже если каким-то чудом смогут, то их отфильтрует межсетевой экран провайдера (а попросить провайдера отключить его собственный межсетевой экран вы уже вряд ли сможете)
Защищает не роутер, а межсетевой экран. Если его отключить или криво настроить, роутер всё отроутит и даст доступ к лампочкам даже без проброса портов — я проверял это на практике
Звучит не очень круто для языка, стремящегося быть blazingly fast )
То, что в языке программирования этого нет и нужна сторонняя утилита — уже проблема языка программирования
То, что запрет паник возможен (согласно вашим утверждениям) только с добавлением обработки несуществующих ошибок — тоже проблема языка программирования, я не желаю тратить кучу своего времени на обработку того, что не может произойти даже теоретически
Я хочу написать
vec[idx]так, чтобы компилятор подтвердил, что я доказал корректность индекса и паники здесь быть не может, или чтобы компилятор сказал мне, что ничего не доказалось и паника возможна — ближе всего к этому подходит крейт no_panic, но он тоже кривой и имеет ложноположительные срабатывания (потому что работает через костыли)И он бесполезен, потому что вынуждает перегружать код обработкой несуществующих ошибок и всё равно не способен отлавливать паники из сторонних библиотек