RPC & TCP Поведение
Может ли кто-нибудь описать с сетевой точки зрения, что такое RPC (SUN и / или DCE) и почему он отличается от стандартного поведения TCP?
Насколько я понимаю, клиент обращается к серверу с уникальным портом источника, а затем переключает порт источника после завершения трехстороннего рукопожатия TCP. Я работаю с брандмауэрами ASA, поэтому это поведение становится очень очевидным, когда проверка DCE RPC не включена, поскольку брандмауэр блокирует его, потому что видит в этом угрозу. Я прочитал несколько статей MS TechNet и других определений веб-сайта, включая просмотр около пяти видеороликов Youtube, которые, кажется, объясняют это с точки зрения программистов, но я еще не полностью понял эту концепцию, так как я не программист.
1 ответ
Обратите внимание, что ничто не отличается от стандартного TCP в отношении протоколов RPC.
SunRPC или DCE RPC работают поверх UDP(по крайней мере SunRPC может использовать UDP) или поверх TCP.
Обычно для того, чтобы RPC-клиент связывался / вызывал RPC-сервер, он сначала связывается с каким-либо поисковым сервером (называемым portmapper или rpcbind в случае SunRPC), который отвечает местоположением (IP-адресом и номером порта) того места, где находится фактический сервер работает.
Итак, с сетевой точки зрения:
- Серверы RPC прослушивают случайный номер порта, который может меняться каждый раз, когда серверная программа запускается (перезапускается).
- При запуске сервер RPC подключается к portmapper, который работает на хорошо известном порту и регистрирует себя, с каким IP-адресом и номером порта он прослушивает.
Обычно служба portmapper работает на той же машине, что и программы сервера RPC.
Когда клиент хочет подключиться или вызвать службу RPC, он выполняет следующие действия:
- Подключается к portmapper через хорошо известный / стандартный порт назначения и спрашивает его, где находится конкретная служба, к которой он хочет подключиться.
- portmapper отвечает IP-адресом и номером порта службы, которую запросил клиент.
- клиент разрывает соединение с portmapper
- клиент устанавливает новое соединение с сервисом, используя IP-адрес и номер порта, которые ему дал pormapper.
- клиент вызывает службу RPC через это новое соединение, которое клиент может использовать для нескольких вызовов RPC.
- Эти вызовы RPC являются просто сообщениями приложения, которыми обмениваются поверх TCP-соединения.
(В случае, если вместо TCP используется UDP, он работает примерно так же, но, естественно, нет никакой установки / разрыва соединения по сети)
Это создает проблему для брандмауэров, так как серверы прослушивают случайно выбранные номера портов, поэтому невозможно административно разрешить доступ к определенному номеру порта. Вместо этого брандмауэр, желающий поддерживать такую настройку, должен был бы открыть порт portmapper, перехватить сообщения RPC, идущие на этот хорошо известный порт portmapper, проверить содержимое сообщения, которым обмениваются portmapper, чтобы извлечь IP-адрес и номер порта из Сообщения RPC (сама программа portmapper реализована как сервер RPC) для динамического открытия порта между сервером RPC и клиентом.