17.09.2019 07:44:11] Strix привет, можешь решить пока задачки? [17.09.2019 07:44:37] 1. Когда может возникать ошибка 504 при использовании nginx? Опишите случаи и решения по ним. Ошибка 504 "Gateway timeout" означает, что истек таймаут показа / генерации динамической страницы. Может возникать по нескольким причинам. а) Может быть задержка исполнения SQL-запроса, т.е., некий SQL-запрос исполняется слишком долго, и время его исполнения превышает некий таймаут, по истечению которого выдается ошибка 504. Часто бывает, что запросы, исполняемые PHP- скриптами, не оптимизированы по времени выполнения, например, могут быть джойны нескольких таблиц, которые долго обрабатываются. Тут может помочь оптимизация самих запросов или создание индексов для их ускорения. У MySQL полезно включить "лог медленных запросов" (в my.cnf прописывается таймаут, по истечению которого запрос считается "медленным", т.е., выполняющимся слишком долго, и этот факт фиксируется в отдельном логе для медленных запросов). б) Могут долго исполняться DNS-запросы. Например, может быть включен обратный ресолвинг, а PTR-запись в DNS отсутствует. Или DNS-сервер сам не отвечает. Можно попробовать в конфиге Nginx прописать ! resolver 8.8.8.8; ! resolver_timeout 5s; Это выбирает конкретный рабочий DNS-сервер и таймаут по обращению к нему. в) Может быть таймаут ввода/вывода, например при обращению к диску, свопинг и т.п. Для этого можно проверить загрузку системы (загрузка памяти: команда free, загрузка CPU: смотрим load average -- команды uptime, top, загрузка дисковой подсистемы: команда iotop). г) и наконец, может быть таймаут при обращении к бекенду: fastcgi/php-fpm или бекенд-Apache или Nginx, если первый Nginx работает в режиме прокси/ балансировщика нагрузки. Т.е., время ожидания бэкенда истекло. Тут могут быть следующие причины: a) PHP скрипт "завис" или "заморозился". b) время выполнения скрипта просто слишком большое и превышает таймаут c) загрузка системы большая и сервер не успевает обслуживать клиентов в случае использования fastcgi, можно попробовать увеличить таймаут бекенда, например, 300 сек: ! fastcgi_send_timeout 300; ! fastcgi_read_timeout 300; Если Nginx работает как фроентенд для другого веб-сервера, то таймаут увеличивается вот так: ! proxy_connect_timeout 300; ! proxy_send_timeout 300; ! Proxy_read_timeout 300; ! Send_timeout 300; -- здесь задаются таймауты для различных действий: соединение, посылка данных, чтение данных и др. В случае php-fpm, можно включить "лог медленных скриптов" и посмотреть, какие скрипты выполняются медленно, и уже дальше смотреть каждый скрипт отдельно: ! slowlog = /var/log/php-fpm/www-slow.log ! request_slowlog_timeout = 5s 2. Как решить проблемы с реальными адресами посетителей в связке Nginx + LAMP? Если Nginx работает как фронтенд для другого веб-сервера (например, Apache или Nginx), то скрипты, исполняемые на бекенде, могут выполнять какие-либо действия, различая клиентов по их IP. В таком случае, бекенд может увидеть вместо IP клиента, IP фронтенда/прокси. Чтобы передать бэкенду реальный IP клиента, можно настроить фронтенд, чтобы он передавал IP клиента в спец. заголовках HTTP-запроса. Для этого можно сделать вот так: ! proxy_set_header X-Real-IP $remote_addr; ! proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; здесь в хедере X-Real-IP передается переменная $remote_addr и в хедере X-Forwarded-For передается переменная $proxy_add_x_forwarded_for. Теперь, если посмотреть phpinfo() на бэкенде, мы увидим, что переменные _SERVER["HTTP_X_REAL_IP"] и _SERVER["HTTP_X_FORWARDED_FOR"] равны реальному IP пользователя, но _SERVER["REMOTE_ADDR"] по-прежнему показывает IP фронтенда. Тут можно сделать вот так: ! location ~ \.php$ { ! fastcgi_param REMOTE_ADDR $http_x_real_ip; ! #...other rules ! } в конфиге бэкенда, и REMOTE_ADDR будет равен тоже IP клиента. Теперь PHP-скрипты, которые смотрят в REMOTE_ADDR, будут работать. Но это будет работать только в PHP- скриптах на бэкенде. Сам веб-сервер бекенда действия на основе IP пользователя делать не сможет. В этом случае можно использовать на веб-сервере бэкенда спец. модуль для реального IP пользователя. В случае Nginx надо вписать в конфиг бэкенда следующую строчку: ! set_real_ip_from 192.168.122.1; -- где 192.168.122.1 это IP фронтенда. В случае Apache в качестве бэкенда, нужно использовать модуль mod_remoteip. В конфиге Apache нужно прописать название HTTP-хедера и список прокси-серверов: ! RemoteIPHeader X-Real-IP ! RemoteIPInternalProxyList conf/trusted-proxies.lst где conf/trusted-proxies.lst имеет примерно такой вид: ! # Our internally trusted proxies; ! 10.0.2.0/24 #Everyone in the testing group ! gateway.localdomain #The front end balancer 3. Дано: Linux сервер в качестве маршрутизатора с интерфейсами eth0 (0.0.0.0/0 - интернет) и eth1 (1.1.1.0/24 - сеть с белой адресацией). Напишите правило для iptables, которое блокирует транзитный трафик на ip 1.1.1.2 с TCP флагом SYN+ACK. Можно на маршрутизаторе выполнить следующую команду: iptables -A FORWARD -i eth0 -o eth1 -d 1.1.1.2 -p tcp --tcp-flags SYN,ACK -j DROP 4. Какие проблемы могут возникнуть при использовании GRE (IPIP) тоннелей в маршрутизируемой сети и как это проявляется? GRE это протокол для туннелирования других протоколов сетевого уровня внутри IP- пакетов. Т.е., он нужен для того, чтобы другой протокол сетевого уровня засунуть внутрь IP-пакета. Сам протокол GRE тоже работает на сетевом уровне. Т.е., в нем отсутствует понятия порта, как в UDP или TCP. Это служит источником следующих проблем: 1) проблема флага DF. Если стоит флаг "Don't Fragment" (не фрагментировать) в IP- заголовке, то фрагментация пакетов запрещена. Т.е., большие пакеты не разбиваются на более мелкие. Пакеты, размер которых больше MTU GRE-туннеля, просто отбрасываются. Более мелкие пакеты проходят. Внутри IP-пакета к данным протокола-"пассажира" добавляется еще заголовок GRE-пакета, поэтому размер полезной нагрузки уменьшается на размер GRE- заголовка. Чтобы пакеты не отбрасывались из-за слишком большого размера, рекомендуется использовать path-mtu-discovery -- фича IP-стека, которая позволяет для маршрута следования пакетов определить максимальный размер пакета для передачи. 2) проблема NAT-а. Т.к. NAT использует открытие множества портов на шлюзе, по одному для каждого соединения, а GRE-это протокол сетевого уровня, и не использует порты, то возникает проблема, если мы хотим пробросить GRE-туннель через NAT. Для преодоления этой проблемы испольуется такая фича как VPN passtrhough (в частности, PPTP passthrough), которую могут поддерживать некоторые роутеры. В случае протокола PPTP, вместо портов на NAT-е, используется спец. поле "call ID" в заголовке GRE-пакета, т.е., используется расширенная версия протокола GRE. Т.е., NAT должен уметь различать обычные соединения от GRE-туннелей, и в случае GRE-туннелей использовать это поле для различения различных соединений внутри туннеля. [17.09.2019 07:47:03] Я пока доделаю задачи, потом расскажу что делать, ну в принципе вот так и будет, решать задачи свзанные с nginx, iptables и т.д, с работой сервисов