21 Jan 15 11:33, Constantin Stefanov wrote to Vassily Kiryanov:
>> VK>> Hаступил на странные грабли. Есть система, на которой несколько >> VK>> джэйлов, для апача, нгинкса, мускуля и прочего - по задаче на >> VK>> джэйл. В в джэйле с апачем22 стоит и php56 (хотелось посвежее, >> VK>> но из pkg) вызываемый через suphp. В итоге даже простейший файл >> VK>> с вызовом phpinfo клиенту от нгинкса приходит неполным. В логе >> VK>> ошибок нгинкс строки вида: [alert] 60985#0: *28 writev() failed >> VK>> (13: Permission denied) while sending to client, client: >> VK>> 192.168.x.y
>> EG> Permission denied это, возможно, запрет пакетного фильтра. >> EG> Какой файрвол используется?
>> Очень похоже, что представление авторов ядра FreeBSD на счёт того, >> как нужно организовывать kernel NAT + ports redirect разительно >> отличается от моего. Самое неприятное: начинаю подозревать, что прав >> в этом заочном споре с ними отнюдь не я...
CS> А можно поподробнее о конфигурации? CS> А то у меня примерно похожее (в хостовой системе nginx, в джейлах CS> апачи с php и mysql), и все работает без проблем, и большие файлы CS> ходят. Правда, port mapping у меня использован только для того, чтоб CS> ssh внутрь джейла пробросить, но через него большие файлы тоже отлично CS> пролезают. Вот suphp нет.
Такая конфигурация, которую ты описываешь, у меня тоже работала без проблем. У меня несколько сексуальнее: основная система, своя подсеть адресов, три провайдера интернета (постоянно включены два), в одном джэйле мускуль, в другом нгинкс, в третьем апач, в четвёртом named. С трёх внешних адресов, на которых подняты три kernel-NAT, на 80-й порт джэйла с нгинксом пробросы были через редирект порта. Будь трансляция адресов одной-единственной, оно м.б. и заработало-бы, но обратные пакеты пришлось отправлять через "ipfw nat global", может это помешало. А может я просто не умею этих кошек готовить.
Сейчас сделаю, чтобы нгинкс в джэйле слушал на нескольких разных портах и с каждого внешнего адреса по отдельному redirect на _разные_ порты. Это избавит от необходимости ответные пакеты сервисов пропускать через единый "nat global", если заработает - оставлю так. Если не заработает - вообще уберу redirect_port-ы для tcp, и воспользуюсь в основной системе несколькими datapipe (есть в портах, удобная штука).
Всего хорошего. "За верную и прибыльную дружбу!" (c) Яго.