Для чого потрібний порт для переадресації в Tomcat?

Важко осмислити документацію tomcat і, переглянувши server.xml, ви знайдете салат з портів, який може бути важко зрозуміти, оскільки це насправді не пояснено належним чином або широко в документації.

Наприклад, цей рядок у конфігураційному файлі server.xml

<Connector port="8345" protocol="AJP/1.3" redirectPort="9875" />

І тут ви можете знайти ще один порт переадресації:

<Connector executor="tomcatThreadPool"
               port="8080" protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443" />

Я розумію, що робить порт з'єднувача. У першому випадку ви використовуєте це, щоб створити працівника в апачі та відправити його туди, у другому ви відкриєте порт для доступу до tomcat безпосередньо. Однак, коли справа доходить до переадресації, речі стають нечіткими.

Ось пояснення, надані документацією на tomcat на порт ajp:

Якщо цей Роз'єм підтримує не-SSL-запити, і отримується запит, для відповідності якого потрібен транспорт SSL, Каталіна автоматично перенаправить запит на вказаний тут номер порту.

Я завжди вибираю випадковий порт переадресації понад 1024, і він працює,

Але коли це втілиться в життя? Звідки це знати, коли для запиту потрібен транспорт SSL?

У мене є супутниковий сервер, на якому працює модуль tomcat. Цей модуль набуває чинності шляхом перенаправлення трафіку на ajp-роз'єм з apache з основного сервера і навпаки.

На головному сервері https застосовується в apache. Чи означає це, що всі запити надсилаються на супутниковий сервер у зашифрованому вигляді чи у простому тексті? Я знаю, що якщо я отримую доступ до супутникового сервера через порт 8080, він не шифрується, але мені цікаво, чи це стосується і трафіку, який перенаправляється на основний сервер, і де цей порт переадресації набирає чинності.

linux tomcat tomcat7

— Улукай
джерело

Як визначено в документації, порт переадресації прийме в зображення, коли SSL-запит надійде на сервер, і оскільки порт з'єднувача http не може обробляти SSL-запити, він перенаправить на визначений порт. Але їх повинен бути інший розділ, визначений у файлі server.xml, у якому визначений порт переадресації буде виконувати роль порту з'єднувача для обробки запитів SSL. Наприклад, якщо ви хочете, щоб http-запити оброблялися через порт 80, а https-запит через порт 443, сервер.xml виглядатиме так:

<Connector port="80" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="443" />

<Connector port="443" protocol="org.apache.coyote.http11.Http11Protocol" SSLEnabled="true" scheme="https" secure="true" sslProtocol="TLS" keystoreFile="/path/to/kestorefile" keystorePass="my_keystore_password"/>

Keystorefile - це сертифікат ssl вашого веб-сайту.

Якщо ви не налаштуєте інший розділ з портом переадресації як порт з'єднання, ваші запити не будуть перенаправлені на цей порт. Наприклад, якщо веб-сайт не підтримує ssl-запити, і ви намагаєтеся надіслати https-запит на цей веб-сайт, у браузері відображатиметься помилка, наприклад, безпечне з'єднання не вдалося .

— Гаурав Пундір
джерело

Справедливо. Що з конфігурацією ajp на відміну від http? Також корисно використовувати порти під 1024, як ви згадуєте? Це означає, що виконувати Tomcat як root, і це не добре.

— Улукай

Я не маю багато уявлення про ajp, але перенаправлення має працювати так само, як і http. Про використання портів під 1024, ви повністю залежить від вас. 80 і 443 - порти за замовчуванням для протоколу https & https, не потрібно чітко їх згадувати в URL-адресі. Якщо ви хочете використовувати нестандартні порти, це залежить від вас. Також працює tomcat з root, це залежить від розгорнутої програми. Якщо ви не довіряєте програмі з точки зору безпеки, ви не повинні запускати tomcat з root. З іншого боку, ви можете використовувати apache або nginx в якості проксі для запуску через порт 80 і 443 і перенаправити запит на tomcat.

— Гаурав Пундір

Зауважу, що iptablesтакож чудово працює для перенаправлення трафіку на Tomcat, серед інших підходів .

— SeldomNeedy

Це пояснення є неповним. Якщо ви переспрямовуєте з не-SSL на порт SSL, недостатньо включити цільовий роз'єм у server.xml. Також необхідно налаштувати розділ <security-constraint> у веб.xml. Див stackoverflow.com/questions/9526425 / ...

— luiscolorado