Как получить доступ к веб-сервису за NAT?

Question

У нас есть продукт, который мы внедряем на некоторых малых предприятиях.Это в основном RESTful API поверх SSL с использованием Tomcat.Это установлено на сервере в малом бизнесе и доступно через iPhone или другое портативное устройство.Таким образом, устройства, подключающиеся к серверу, могут поступать с любого количества IP-адресов.

Проблема связана с установкой.Когда мы устанавливаем этот сервис, кажется, что он всегда становится проблемой при переадресации портов, поэтому внешний мир может получить доступ к tomcat.Кажется, что в большинстве случаев владелец не знает пароля маршрутизатора и т. Д. И т. Д.

Я пытаюсь найти другие способы, которыми мы можем добиться этого.Я предложил следующее и хотел бы услышать другие мысли по этой теме.

1. Настройка SSH-туннеля от каждого клиентского офиса к центральному серверу.По сути, удаленные устройства будут подключаться к этому центральному серверу через порт, и этот трафик будет направляться обратно в Tomcat в офисе.Кажется избыточным иметь SSH, а затем SSL, но на самом деле нет другого способа сделать это, так как сквозной мне нужен SSL (от устройства к офису).Не уверен, что это повлияет на производительность, но я знаю, что это сработает.Потребовалось бы контролировать туннель и вернуть его обратно, если это будет сделано, потребуется обработать обмен ключами SSH и т.д.Скорее всего, будет работать большую часть времени, но uPNP не гарантированно будет включен.Может быть, хороший следующий шаг.

2. Придумайте некую трансверсальную схему NAT.Я просто не знаком с этим и не уверен, как именно они работают.У нас есть доступ к централизованному серверу, который необходим для аутентификации, если это облегчает задачу.

На что еще мне нужно обратить внимание, чтобы добиться этого?

Answer 1

Нет ли способа, чтобы эта услуга была размещена публично вами или хостинг-провайдером, а не у клиента?

У меня была похожая ситуация, когда я разрабатывал киоски.Я никогда не знал, с каким сетевым окружением мне придется иметь дело при следующей установке.

В итоге я создал PPTP VPN, чтобы все киоски могли подключаться к одному серверу, который я публично размещал.Затем мы создали веб-сервис контроллера для предоставления доступа к киоскам, которые были подключены через VPN.Я не уверен, насколько вы знакомы с VPN, но с помощью VPN-соединения я смог полностью обойти брандмауэр перед каждым киоском, получив доступ к киоску через назначенный VPN IP.

Каждый узел киоска был невероятноЛегко настроить, как только я настроил VPN-сервер.Это также принесло управленческие преимущества и доход от лицензий, о которых я изначально не думал.с помощью этой инфраструктуры я легко смог развернуть услуги, доступные через мобильные телефоны.

Удачи!

Answer 2

Существуют решения для «динамического» доступа к программному обеспечению на компьютере за NAT, но обычно в основном для связи по UDP.

Одним из них является метод UDP дырокола . Однако это не гарантирует работу в каждой возможной ситуации. Если обе стороны связи находятся за «симметричным конусным NAT», это не так.

Вы можете уменьшить вероятность того, что клиент не сможет общаться, используя UPnP в качестве резервной (или даже основной) альтернативы.

Я недостаточно знаю веб-сервисы и даже не знаю, является ли использование UDP для вашего веб-сервиса одним из вариантов (или если это вообще возможно).

Использование того же метода для непосредственного TCP может привести к сбою (TCP-соединения не являются без сохранения состояния - здесь возникает много проблем).

Альтернативой, использующей ту же технику, может быть настройка некоторого VPN на основе UDP (точно так же как OpenVPN ), но, как вы сказали, вам придется управлять ключами, сертификатами и т. , Это может быть автоматизировано (я сделал это), но все же, это не совсем тривиально.

=== РЕДАКТИРОВАТЬ ===

Если вы действительно хотите использовать TCP, вы можете создать простое «прокси» программное обеспечение на клиентских компьютерах, которое будет служить ретранслятором.

Вы бы имели следующую схему:

1. Веб-сервис на клиентских компьютерах за NAT
2. Программное обеспечение «прокси» в тех же самых блоках, устанавливающее исходящее (таким образом незаблокированное) TCP-соединение с серверами вашей компании
3. На серверах вашей компании также размещается WebService, для которого требуется что-то вроде «идентификатора клиента», чтобы перенаправить запрос на соответствующее установленное TCP-соединение.
4. Прокси-программа опрашивает локальный WebService и отправляет ответ на серверы компании, которые также передают ответ исходному запрашивающему.

Альтернативный вариант: вы можете попросить прокси-программное обеспечение напрямую подключиться к запрашивающей стороне, чтобы повысить производительность, но тогда вы можете столкнуться с теми же проблемами NAT, которые пытаетесь избежать.

Answer 3

Именно из-за таких вещей люди сейчас туннелируют все через http, и поэтому некоторые производители оборудования берут небольшое состояние за фильтрацию пакетов уровня 7.

Это огромная работа по исправлениюпроблема, когда у клиента есть как минимум три проблемы.Кроме того, который вы определили, если они не знают свой собственный пароль, то кто знает?Администратор, который там больше не работает?Это проблема.

Во-вторых, если они не знают пароля, это означает, что они почти наверняка сильно отстают в обновлении прошивки своего брандмауэра.

Я думаю, что им следует серьезно рассмотреть возможность сброса PROM на своем брандмауэре и перенастройки с нуля (и обновления прошивки, пока они там).*

Answer 4

+ 1 для перехода с SSH-туннелем. Он хорошо известен, широко доступен и не слишком сложен в настройке.

Однако, как вы указали, вы уже используете SSL, поэтому шифрование SSH является избыточным. Вместо SSH вы можете просто использовать обычный туннельный прокси, который обеспечивает туннелирование без шифрования. Я использовал этот в прошлом, и он работал хорошо, хотя я не загружал его тестирование - он использовался всего несколькими пользователями.

Вот блог от кого-то, кто использовал туннельный прокси для доступа к своей веб-камере вне своего брандмауэра.

Answer 5

Я должен был сделать нечто подобное в прошлом, и я считаю, лучший вариант - первый предложенный вами.

Вы можете сделать это простым способом, используя ssh с опцией -R, используя аутентификация с открытым ключом и пара скриптов для проверки подключение. Не забывайте о различных событиях жизни и времени ожидания особенности ssh.

Не беспокойся о спектаклях. Используйте непривилегированных пользователей и порты если ты можешь. Не пытайтесь настроить CA, открытый ключ каждого пульта Сервер проще в обслуживании, если вы не в тысячах.

Мониторинг довольно прост. Каждый сервер должен проверить сервис на центральный сервер. Если это не удается, либо туннель не работает, либо нет подключения. Перезапуск туннеля ни в коем случае не повредит.

Или вы можете сделать это на сетевом уровне, используя IPsec (strongswan). Это может быть сложнее для настройки, и это вариант, который я использовал, но я буду использовать SSH в следующий раз, это сэкономило бы мне много времени.

Answer 6

Вы можете попытаться подключиться к ПК / серверу и туннелировать все данные через hamachi (бесплатное программное обеспечение VPN), потому что этот инструмент вы можете установить, и он создаст обратное соединение (изнутри вашего nat к внешнему), чтобы вы могли подключитьсяк нему

сайт: http://hamachi.cc/

Answer 7

Если вы хотите иметь RESTful-интеграцию с клиентским сервером , туннель к центральному серверу, который работает в качестве прокси-сервера, кажется лучшим подходом.

Но если это не такЭто жесткое требование: вы можете позволить центральному серверу обрабатывать RESTfull и интегрировать центральный сервер и клиентский сервер с другим промежуточным ПО.Хорошими кандидатами будут RMI или JMS.Например, соединение RMI, инициированное клиентом, позволяет серверу выполнять вызовы RMI клиенту.

Answer 8

Установите Apache перед вашим Tomcat.Этот Apache должен быть виден из интернета, а Tomcat - нет.

Настройте Apache для пересылки всего трафика на Tomcat.Этого легко достичь, используя mod_proxy (ознакомьтесь с директивами ProxyPass и ProxyPassReverse).

Ваш SSL-сертификат должен находиться в Apache, чтобы все клиенты могли обмениваться HTTPS с сервером Apache, который, в свою очередь, общается с HTTP через Tomcat.

Никаких туннелей или других неприятностей + вы будете удивлены, насколько легко настроить Apache для этого.