21 Jan 15 13:43, Constantin Stefanov wrote to Vassily Kiryanov: >>>> VK>> Hаступил на странные грабли. Есть система, на которой >>>> VK>> несколько джэйлов, для апача, нгинкса, мускуля и прочего - по >>>> VK>> задаче на джэйл. В в джэйле с апачем22 стоит и php56 >>>> VK>> (хотелось посвежее, но из pkg) вызываемый через suphp. В >>>> VK>> итоге даже простейший файл с вызовом phpinfo клиенту от >>>> VK>> нгинкса приходит неполным. В логе ошибок нгинкс строки вида: >>>> VK>> [alert] 60985#0: *28 writev() failed (13: Permission denied) >>>> VK>> while sending to client, client: 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 (есть в >> портах, удобная штука). CS> Ясно, до такого я, действительно, не дошел. Если чего получится - CS> расскажи, пожалуйста, чтоб знать на будущее.
Сделал, как собирался, конфигурацию на kernel-NAT, но бе "nat global". Появился неожиданный бонус - nginx теперь смог-бы вести логи отдельно по доступу на каждый внешний адрес, только мне это без надобности. Однако, основной результат без изменений - отдаются внешнему клиенту только первые 32-с-чем-то Кб ответа. Плюнул, тут-же поднял datapipe и всё заработало "как доктор прописал". Жотя это некрасиво, т.к. потребует перегонять пакеты через userland и потом отдавать обратно в kernel. Однако это не хуже, чем делать трансляцию адресов плюс редирект портов через natd, который тоже userland. В общем, пока что оставлю схему проброса на datapipe. Чтобы datapipe, имеющий свойство иногда вылетать, не оставил мои сервисы без запросов, нарисовал по-быстрому скрипт, который будет вызываться кроном, вот он:
$prog $Virt_Host $Virt_Port $Real_Host $Real_Port >> /dev/null 2>&1 ExitCode=${?:-255} # $?=0 - datapipe started OK # $?=20 - datapipe was already started an now working