shurshur

Не надо использовать time.sleep в асинхронном коде, это блокирует event loop! Вместо этого надо использовать асинхронный вариант asyncio.sleep.

По существу с таким кодом будет делаться 10 отправок в секунду, а официально лимит 30 в секунду. Но лучше бы дополнительно отлавливать исключение с flood control и по нему делать дополнительный sleep хотя бы на 1 секунду, а то и чуть больше, чтобы счётчик числа попыток на стороне Telegram обнулился за это время.

bot.send_message(message.chat.id, 'привет '+message.text)

или

bot.send_message(message.chat.id, f'привет {message.text}')

"Сниффить" может только root.

upd: Каждый объект и каждый запрос имеют ID.
ID каждого объекта больше предыдущего на 1.

Помнить самый большой из id уже возвращавшихся, при каждом запросе проверять, нет ли id больше запомненного. Запросы делать с определёнными интервалами (sleep), чтобы их число в единицу времени не превышало лимитов (наприммер, если разрешено максимум 10 запросов в минуту, то нужно сделать интервал не меньше 6 секунд).

Между прочим, getUpdates в библиотеках telegram используют примерно так же. Более того Bot API позволяет указать в параметре offset нужный id, чтобы в ответ вернулись только более новые.

Довольно кроссплатформенный способ запросить права администратора реализует модуль https://pypi.org/project/elevate/

Для этого порт надо пробрасывать как tcp, не http/https.

Но вообще-то это неправильная практика. Как раз на прокси/балансеры и вешают сертификат в таких случаях, а дальше терминируют трафик на http или на https с любым сертификатом.

input - синхронная функция, она блокирует event loop. Для работы с консолью можно использовать асинхронную функцию ainput из модуля aioconsole.

import asyncio
from aioconsole import ainput

async def main():
  s = await ainput('Enter something: ')
  print (f"You entered {s}")

loop = asyncio.get_event_loop()
loop.run_until_complete(main())

primary key и не обязан "сам заполняться" ни в одной базе. Даже в mysql это отдельная фича - auto_increment. А тут для этого нужен sequence или serial. См. например тут: https://www.postgresqltutorial.com/postgresql-serial/

В России есть Россвязь, которая распределяет номерную ёмкость по операторам. Эта информация публична, можно скачать машиночитаемые выгрузки у них на сайте: https://rossvyaz.gov.ru/deyatelnost/resurs-numerac...

Далее, в России есть MNP, позволяющий переносить мобильный номер от оператора к оператору. Но только в пределах региона. Поэтому если задача по номеру определять только регион, то она надёжно решается указанными выше выгрузками. Оператора по ним определять ненадёжно, так как ежедневно много номеров меняют оператора, и любые данные быстро устаревают.

Оператором базы данных перенесённых номеров (БДПН) является ЦНИИС, на его сайте можно получить текущего оператора только по конкретному номеру: https://zniis.ru/bdpn/check/ а обновляемый доступ ко всей базе простым смертным не получить.

Чтобы понимать масштаб проблемы, сейчас в России ~14.7 млн. перенесённых номеров, за вчерашние сутки ~9.5 тыс. номеров поменяли оператора и ~1.5 тыс. вернулись из списка перенесённых к своему родному оператору.

Таким образом, никакого смысла в подобном сайте без обновляемого доступа к БДПН (а она обновляется каждые 2 часа) нет.

Что касается технической реализации, то тут всё достаточно просто, если у тебя есть доступ к БДПН. ЦНИИС публикует раз в сутки Numbering_Plan, аналогичный выгрузке DEF-9xx.csv Россвязи (формат отличается, но смысл тот же - диапазоны, каждый назначен оператору+региону), также публикует раз в сутки Port_All с полным списком MNP. Если не нужно поддерживать (для простоты) частые (каждые 2 часа) обновления, то этого достаточно. Любой номер сначала проверяем на наличие в Port_All, если не нашёлся - ищем подходящий диапазон в Numbering_Plan.

BGP оперирует не IP-адресами, а автономными системами, которые должны быть не менее чем /24 (256 адресов). Судя по всему, у вас нет своей AS, а адреса принадлежат провайдерам.

Я вижу только один способ сохранить прям те же самые адреса: сервер поместить в датацентр, а на старом месте оставить недорогой сервер для проброса нужных портов в целевой сервер в датацентр. Лучше подобное воспринимать как временное решение, всё переносить на новый IP сервера, переводить туда клиентов и всё такое, чтобы в дальнейшем когда-нибудь от лишних провайдеров отказаться.

Если у оператора есть точка присутствия в датацентре, а текущий договор на юрлицо, то можно попробовать официально договориться с ним о том, чтобы подключиться к нему в датацентре и перености IP, но у оператора моугт быть (и скорее всего будут) свои нюансы устройства сети, которые это не позволят.

Бесплатных легальных сервисов для интеграции WhatsApp (т.н. WhatsApp Business API) нет. Есть нелегальные (не очень дорогие), основанные на имитации взаимодействия с WhatsApp Web, но с ними есть риск получить бан, так что как минимум особенно ценный номер телефона я бы таким в любом случае не доверил.