Как получить доступ к веб-сервису позади NAT?
У нас есть продукт, который мы развертываем на некоторых предприятиях малого бизнеса. Это - в основном УСПОКОИТЕЛЬНЫЙ API по SSL с помощью Tomcat. Это установлено на сервере в малом бизнесе и получено доступ через iPhone или другое портативное устройство устройства. Так, устройства, соединяющиеся с сервером, могли прибыть из любого количества IP-адресов.
Проблема идет с установкой. Когда мы устанавливаем этот сервис, это, кажется, всегда становится проблемой при выполнении перенаправления портов, таким образом, внешний мир может получить доступ к коту. Это кажется большей частью времени, владелец не знает пароля маршрутизатора, и т.д., и т.д.
Я пытаюсь исследовать другие способы, которыми мы можем выполнить это. Я придумал следующее и хотел бы услышать другие мысли о теме.
Установите туннель SSH с каждого клиентского офиса на центральный сервер. В основном удаленные устройства соединились бы с тем центральным сервером на порте, и тот трафик будет туннелирован назад к Tomcat в офисе. Кажется довольно избыточным, чтобы иметь SSH и затем SSL, но действительно никакой другой способ выполнить его, так как от начала до конца мне нужен SSL (от устройства до офиса). Не уверенный в последствиях производительности здесь, но я знаю, что это работало бы. Должен был бы контролировать туннель и возвратить его, если бы это идет сделанное, должен был бы обработать ключевые обмены SSH, и т.д.
Установите uPNP, чтобы попытаться настроить дыру для меня. Вероятно, работал бы большую часть времени, но uPNP, как гарантируют, не будет включен. Может быть хороший следующий шаг.
Придуманный некоторый тип NAT трансверсальная схема. Я просто не знаком с ними и не уверен в том, как они точно работают. У нас есть доступ к централизованному серверу, который требуется для аутентификации, если это делает его немного легче.
На что еще я должен смотреть получить выполненный?
8 ответов
Разве эта услуга не может быть размещена публично вами или хостинг-провайдером, а не с клиентом?
У меня была похожая ситуация, когда я разрабатывал киоски. Я никогда не знал, с каким типом сетевой среды мне придется иметь дело при следующей установке.
В конечном итоге я создал PPTP VPN, чтобы позволить всем киоскам подключаться к одному серверу, который я разместил публично. Затем мы создали веб-службу контроллера для предоставления доступа к киоскам, которые были подключены через VPN. Я не уверен, насколько вы знакомы с VPN, но с VPN-соединением я смог полностью обойти брандмауэр перед каждым киоском, зайдя в киоск через назначенный VPN IP.
Каждый узел киоска был невероятно прост в настройке, как только у меня был настроен VPN-сервер. Это также принесло управленческие преимущества и доход от лицензирования, о которых я изначально не думал. с помощью этой инфраструктуры я легко смог развернуть услуги, доступные через мобильные телефоны.
Желаем удачи!
Установите Apache перед вашим Tomcat. Этот Apache должен быть виден из Интернета, а Tomcat - нет.
Настройте Apache для пересылки всего трафика на Tomcat. Это легко сделать с помощью mod_proxy (ознакомьтесь с директивами ProxyPass и ProxyPassReverse).
Расположите свой сертификат SSL в Apache, чтобы все клиенты могли общаться по протоколу HTTPS с сервером Apache, который, в свою очередь, общается с Tomcat по обычному протоколу HTTP.
Никакого туннелирования или других неприятностей + вы удивитесь, насколько легко настроить Apache для этого.
В прошлом мне приходилось делать нечто подобное, и я считаю. лучшим вариантом является первый, который вы предложили.
Вы можете сделать это простым способом, используя ssh с опцией -R, используя publick key auth и пару скриптов для проверки подключения. Не забывайте о различных функциях поддержания жизни и таймаута. функции ssh.
Не беспокойтесь о производительности. Используйте непривилегированных пользователей и порты если можете. Не утруждайте себя установкой CA, открытый ключ каждого удаленного сервера проще поддерживать, если только вы не работаете с тысячами.
Мониторинг довольно прост. Каждый сервер должен тестировать службу на центральном сервере. Если он не работает, то либо туннель не работает, либо нет соединения. Перезапуск туннеля в любом случае не повредит.
Или вы можете сделать это на уровне сети, используя IPsec (strongswan). Это может быть сложнее в настройке, и я использовал именно этот вариант, но в следующий раз я буду использовать SSH. использовать SSH в следующий раз, это сэкономило бы мне много времени.
Существуют решения для "динамического" доступа к программному обеспечению на компьютере за NAT, но, как правило, в основном для UDP-коммуникаций.
Техника UDP hole punching является одной из них. Однако не гарантируется, что она сработает в любой возможной ситуации. Если обе стороны коммуникации находятся за "симметричным конусным NAT", это не сработает.
Вы, очевидно, можете уменьшить вероятность того, что клиент не сможет общаться, используя UPnP в качестве резервной (или даже основной) альтернативы.
Я недостаточно знаком с веб-сервисами и даже не знаю, является ли использование UDP для вашего веб-сервиса вариантом (и возможно ли это вообще).
Использование той же техники для прямого TCP, скорее всего, будет неудачным (TCP соединения не являются stateless - это вызывает много проблем).
Альтернативой, использующей ту же технику, может быть создание некоторой VPN на основе UDP (как OpenVPN), но, как вы уже сказали, вам придется управлять ключами, сертификатами и так далее. Это можно автоматизировать (я это делал), но все же это не совсем тривиально.
===EDIT===
Если вы действительно хотите использовать TCP, вы можете создать простую "прокси" программу на клиентских компьютерах, которая будет служить в качестве ретранслятора.
У вас будет следующая схема:
- Веб-сервис на клиентских боксах, за NAT
- Программа "прокси" на тех же боксах, устанавливающая исходящее (таким образом, не блокируемое) TCP-соединение с серверами вашей компании
- На серверах вашей компании также размещен веб-сервис, которому требуется что-то вроде "идентификатора клиента" для перенаправления запроса на соответствующее установленное TCP-соединение.
- Прокси-программа опрашивает локальный WebService и отправляет ответ на серверы компании, которые передают ответ отправителю запроса.
Альтернативный вариант: вы можете попросить прокси-программу напрямую подключиться к запрашивающей стороне для повышения производительности, но тогда вы можете столкнуться с теми же проблемами NAT, которых вы пытаетесь избежать.
Если вы хотите иметь интеграцию RESTful с клиентским сервером , туннель к центральному серверу, который работает как прокси, кажется лучшим подходом.
Но если это не является жестким требованием, вы можете позволить центральному серверу обрабатывать RESTfull и интегрировать центральный сервер и клиентский сервер с другими промежуточное ПО. Хорошими кандидатами будут RMI или JMS. Например, соединение RMI, инициированное клиентом, позволяет серверу выполнять вызовы RMI к клиенту.
+1 за использование туннеля SSH. Он хорошо известен, широко доступен и не слишком сложен в настройке.
Однако, как вы указываете, вы уже используете SSL, поэтому шифрование SSH является избыточным. Вместо SSH вы можете просто использовать обычный прокси-сервер туннелирования, который обеспечивает туннелирование без шифрования. Я использовал этот в прошлом, и он работал хорошо, хотя я не тестировал его под нагрузкой - он использовался только с горсткой пользователей.
Вот блог человека, который использовал туннельный прокси-сервер для доступа к своей веб-камере из-за пределов своего брандмауэра.
Вы можете попытаться подключиться к компьютеру / серверу и туннелировать все данные через hamachi (бесплатное программное обеспечение VPN), потому что этот инструмент вы можете установить, и он создаст обратное соединение (изнутри вашего nat-сервера), чтобы вы могли подключиться на его
сайт: http://hamachi.cc/
Именно из-за таких вещей люди сейчас туннелируют все по http, и именно поэтому некоторые производители оборудования берут небольшие деньги за фильтрацию пакетов 7-го уровня.
Это огромный объем работы по устранению одной проблемы, когда у клиента как минимум три проблемы. Помимо той, которую вы указали, если они не знают свой собственный пароль, то кто его знает? Администратор, который там больше не работает? Это проблема.
Во-вторых, если они не знают пароль, это означает, что они почти наверняка сильно отстают в обновлении прошивки своего брандмауэра.
Я думаю, им стоит серьезно подумать о том, чтобы сделать сброс PROM на своем брандмауэре и заново настроить его с нуля (и обновить прошивку, пока они это делают).
3 зайца, один камень.