амазон, у виртуалки два айпи, внутрий и внешний, Net Core 7
HttpListener слушает внутренний с префиксом типа http://12.34.56.78/
в если запрос приходит извне то в ответ приходит NotFound <h1>Not Found (Not Found)</h1> не вызывая мой оброботчик вообще
причем это именно HttpListener возврщает потому что если процесс убить то получается обычное "нет ответа, таймаут"
говорят вроде если запрос был бы не по айпи а по имени домена то проблемы не будет, но мне нада по айпи
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Во-первых надо слушать 0.0.0.0, а не внутренний IP.
Во-вторых раз тебе что-то приходит в ответ, а не connection could not be established, значит таки на этом адресе кто-то слушает.
В-третьих по моим воспоминаниям в амазоне виртуалке внешний IP назначить вообще невозможно. Там все внешние IP идут на их роутеры, через которые они уже перенаправляют пакеты куда надо,
Резюмируя — для начала попробуй 0.0.0.0. Если не сработает, значит надо погружаться глубже в тему. Амазон это совсем непросто и совсем не похоже на другие хостинги.
Re[2]: HttpListener на AWS выдает NotFound c биндом на IP
Здравствуйте, vsb, Вы писали:
vsb>Во-первых надо слушать 0.0.0.0, а не внутренний IP.
0.0.0.0 я не могу потому что у меня к машине привязано 4 айпи и там 4 процесса которые слушают один и тот же порт но с разных айпи
т.е. как бы 4 сервера на одной машине
порты менять тоже низя
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
А как это реализовано технически? Это Elastic IP или дефолтные адреса из публичного амазоновского пула?
В любом случае я бы начал с того, что зашел на ec-instance по SSH и посмотрел, что там с сетью (ifconfig/ip -a/ip -r и т.п.)
Хз, как оно там у них сейчас внутри устроено, может на инстансе вообще нету интерфейсов с такими ip.
Далее, если интерфейсы есть, то попробовать постучаться туда локально с того же инстанса: curl -k http://ip.
Далее, набросать какой-нибудь простой echo-серер на bash(nc,ncat)/nodejs/go, который также слушает на конкретном ip и попробовать с ним.
Последнее — чтобы понять, дело в .NET или в чем-то другом.
Re: HttpListener на AWS выдает NotFound c биндом на IP
Здравствуйте, Barbar1an, Вы писали:
B>амазон, у виртуалки два айпи, внутрий и внешний, Net Core 7 B>HttpListener слушает внутренний с префиксом типа http://12.34.56.78/
B>в если запрос приходит извне то в ответ приходит NotFound <h1>Not Found (Not Found)</h1> не вызывая мой оброботчик вообще
Здравствуйте, RushDevion, Вы писали:
RD>А как это реализовано технически? Это Elastic IP или дефолтные адреса из публичного амазоновского пула?
RD>В любом случае я бы начал с того, что зашел на ec-instance по SSH и посмотрел, что там с сетью (ifconfig/ip -a/ip -r и т.п.) RD>Хз, как оно там у них сейчас внутри устроено, может на инстансе вообще нету интерфейсов с такими ip. RD>Далее, если интерфейсы есть, то попробовать постучаться туда локально с того же инстанса: curl -k http://ip. RD>Далее, набросать какой-нибудь простой echo-серер на bash(nc,ncat)/nodejs/go, который также слушает на конкретном ip и попробовать с ним. RD>Последнее — чтобы понять, дело в .NET или в чем-то другом.
пара моментов:
у нас там висит таким же макаром но TcpListener, тоже слушает тока свой айпи, и с ним никаких проблем нет
админ повесил nginx на тот же порт и тоже чтобы слушал тока 1 айпи и всё ок
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, RushDevion, Вы писали:
RD>А как это реализовано технически? Это Elastic IP или дефолтные адреса из публичного амазоновского пула?
Elastic IP
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Re[5]: HttpListener на AWS выдает NotFound c биндом на IP
B>Elastic IP
Ну раз nginx и TcpListner работают, то, значит, c этой стороны все в порядке.
И еще в .net сore HttpListener вроде бы не завезли. Получается, ec2-instance — это внезапно винда?
А IIS, там случайно не крутится?
Ведь для того, чтобы HttpListner ответил <h1>NotFound</h1>, где-то в хендлере такой код должен быть явно написан.
Т.к. после _listener.GetContext(), мы сами контролируем, что будет послано клиенту.
Re[6]: HttpListener на AWS выдает NotFound c биндом на IP
Здравствуйте, RushDevion, Вы писали:
B>>Elastic IP RD>Ну раз nginx и TcpListner работают, то, значит, c этой стороны все в порядке.
RD>И еще в .net сore HttpListener вроде бы не завезли. Получается, ec2-instance — это внезапно винда? RD>А IIS, там случайно не крутится? RD>Ведь для того, чтобы HttpListner ответил <h1>NotFound</h1>, где-то в хендлере такой код должен быть явно написан. RD>Т.к. после _listener.GetContext(), мы сами контролируем, что будет послано клиенту.
убунту,
и как это не завезли? он вроде вгеда там был
net7.0, кор это или не кор хз , вроде уже не кор, но по сути кор
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Re[7]: HttpListener на AWS выдает NotFound c биндом на IP
B>убунту, B>и как это не завезли? он вроде вгеда там был
Хм. Точно, есть.
А у меня почему-то отложилось, что раньше не было. Надо будет глянуть, как они его реализовали.
Тогда хз. Точно помню, в .net 4.x под виндой, чтобы ответить NotFound, это нужно было явно закодить.
Может, в никсовой версии какой-то дефолтный обработчик добавили.
А точно нет своего кода, который NotFound может выдавать?
Re[8]: HttpListener на AWS выдает NotFound c биндом на IP
Здравствуйте, RushDevion, Вы писали:
RD>А точно нет своего кода, который NotFound может выдавать?
там временное логирование в самом начале обработчика и оно никогда не вызывается
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
RD>>А точно нет своего кода, который NotFound может выдавать?
B>там временное логирование в самом начале обработчика и оно никогда не вызывается
Ну логирование все же так себе показатель. Особенно, если приложение через какой-нибудь systemd запущено.
Проверь еще, что ip/порт в LISTEN, когда приложение запущено, типа такого: sudo lsof -i -P -n | grep LISTEN или netstat -tulpn | grep LISTEN
Но, скорей всего, там все будет нормально.
Здравствуйте, Barbar1an, Вы писали:
B>амазон, у виртуалки два айпи, внутрий и внешний, Net Core 7 B>HttpListener слушает внутренний с префиксом типа http://12.34.56.78/
B>в если запрос приходит извне то в ответ приходит NotFound <h1>Not Found (Not Found)</h1> не вызывая мой оброботчик вообще
B>причем это именно HttpListener возврщает потому что если процесс убить то получается обычное "нет ответа, таймаут"
B>говорят вроде если запрос был бы не по айпи а по имени домена то проблемы не будет, но мне нада по айпи
У меня не HttpListener, на базовый урл я указываю вот такой: http://* Конекты по ip тогда проходят.
Программа – это мысли спрессованные в код
Re: HttpListener на AWS выдает NotFound c биндом на IP
Здравствуйте, Barbar1an, Вы писали:
B>амазон, у виртуалки два айпи, внутрий и внешний, Net Core 7 B>HttpListener слушает внутренний с префиксом типа http://12.34.56.78/ B>в если запрос приходит извне то в ответ приходит NotFound <h1>Not Found (Not Found)</h1> не вызывая мой оброботчик вообще
Посмотрел в полглаза на код HttpListener и скорее всего да, проблема в том, как указать правильный префикс.
Если в 2-х словах, то префикс используется для 2-х целей:
1. выбора ip/порта который нужно слушать
2. выбора какому из Listener отдать обработку пришедшего пакета
И вы как раз упираетесь во второе — на это указывает 404 ошибка, она выбрасывается тут.
Собственно в п.2 проистекает из того, что HTTP, благодаря наличию host (и port) в заголовке каждого пакета, позволяет "сажать" на один IP адрес любое количество хостов — главное, чтобы тот, кто слушает сокет был готов их обрабатывать.
Т.е. ситуация:
— вы сидите на внутреннем IP, слушаете его и ждете в хостах его же,
— вам через NAT прилетают исходные запросы, у которых в заголовке или внешний IP, или вообще DNS-имя
— инфраструктура HttpListener пытается по этому заголовку понять, каком из запущенных HttpListener нужно отдать обработку
— ... ну и никакого не находит, и кидает 404.
В вашей ситуации сложность в том, что вам нужно, по сути, сделать настройку вида "слушай IP XXX с портом YYY, при этом будь готов принимать на нем пакеты для хоста ZZZ с портом ЕЕЕ" (про то, что нужно еще по-разному обрабатывать защищенный (SSL/TLS) и не защищенный канал — опустим, надеюсь что у вас это консистентно)
На сколько я искал HttpListener такого не умеет. Он просто берет все префиксы, которые вы ему сгрузили и пытается по ним понять, какие локальные адреса нужно слушать, а при получении пакета сличает с этими префиксами заголовок пакета.
Поэтому какие видятся варианты (по мере нарастания сложности):
1. Указать префикс в формате "http://+:80/" или "http://*:80/" (смотрите, что вам подходит больше — в документации есть описание). Но в этом случае будут слушаться все локальные адреса, а вы писали, что у вас каждый слушает свой процесс (а шаринг между процессами одного сокета нормально не сделано нигде, как я помню)
2. Указать внешний адрес (или домен), а чтобы правильно определился внутренний адрес прописать его в hosts или аналоге. Тут надо посмотреть в документации AWS, возможно что-то такое уже прописывается, когда вы задаете для инстанса привязку внешнего IP.
3. Поменять немного схему работы: выпускать во внешнюю сеть не саму машину, а реверсный proxy (например nginx).
Там суть в том, что:
— клиент стучится к такому прокси, указывая его адрес.
— прокси разбирает запрос и делает новый запрос, уже указывая явно адрес (внутренний) вашей виртуалки.
Поэтому в такой схеме вам прилетают запросы извне, но для вас они как запросы сделанные изнутри. Причем, реверсный прокси может вам прокинуть и параметры исходного запроса (например, на какой домен он пришел, или от какого клиентского IP, ...).
Для HttpListener я примера не нашел, но схема одинакова вне зависимости от того, на чем вы работаете, поэтому можно посмотреть пример Host ASP.NET Core on Linux with Nginx
Наверняка, есть что-то более-менее готовое у самого Amazon, я с ходу нашел вот такую статью Serving Content Using a Fully Managed Reverse Proxy Architecture in AWS
4. (Вот тут я не до конца уверен — нужно проверять) Пересесть на хостинг (имеется в виду классы .Net) под чем-то, что позволит указать и какие URL/prefixes вам могут прилететь, и на каких IP их слушать. На сколько я могу судить, тот же Kestrel такой финт сделать позволяет.
