Wednesday, December 26, 2018

Аутентификация пользователей при помощи профиля в социальных сетях

В этой статье приведены шаги, позволяющие включить аутентификацию гостя через Facebook и Google+.
Примечания и требования: Применимо к UniFi Controller 5.4.2.1 и версиям выше. Чтобы использовать стороннюю аутентификацию гостя, у Вас должно быть общедоступное имя хоста, указывающее на Ваш контроллер. Если Ваша компания уже использует общедоступное доменное имя, например example.com, Вы можете настроить субдомен, такой как portal.example.com. Существует множество провайдеров динамических DNS, в которых Вы можете зарегистрировать имя хоста, а затем обновить USG для своего IP-адреса WAN

Содержание

  • Введение
  • Настройка приложения Facebook
  • Настройка API Google+
  • Настройка контроллера UniFi

Введение

Гостевая аутентификации через аккаунт в социальных сетях может быть включена для разрешения клиентам входить в гостевую сеть, используя свои учетные данные в Facebook или Google+. Начните с создания приложения facebook, входа в Google + API или обоих.

Настройка приложения Facebook

1. Зарегистрируйте приложение Facebook

Используйте ЭТО руководство, чтобы зарегистрировать приложение для аутентификации через Facebook, оставляя эту статью открытой для чтения.
Шаг 3 предлагает Вам выбрать отображаемое имя для Вашего приложения. Выберите имя, которое будет представлять ваш портал WiFi. Пользователи будут видеть его при аутентификации. В этом примере я буду использовать имя "CMurphy Hotspot Login" и электронную почту по умолчанию, которая связана с моей учетной записью Facebook. Для категории я использую "Communication". Категория здесь не критично важна, поэтому не стесняйтесь использовать другую категорию, если она лучше отражает Ваш бизнес.
Register a Facebook App
Вам будет предложено либо пройти к руководству по быстрой настройке, либо вернуться. Если Вы нажмете кнопку "Назад", Вы попадете на панель инструментов, нажав "My Apps" в верхнем правом углу. Выберите "Choose Platform > Website", чтобы начать быструю настройку.

2. Завершите быструю наастройку веб-сайта Facebook.

Complete Facebook Website Quick Start.
Выберите "Website".
В разделе "Tell us about your website", введите доменное имя вашего контроллера в качестве URL-адреса сайта. Затем нажмите "Developer Dashboard", чтобы перейти к панели разработчика.

3. Настройка приложения

Перейдите в раздел "Settings" на боковой панели, чтобы открыть основные настройки приложения.
App Settings
"App ID" и "App Secret" будут автоматически назначены Вашему приложению. Выберите имя и псевдо для Вашего приложения - они могут быть кикими угодно, но именно их пользователи будут видеть при аутентификации.
В разделе "App Domains" и "Site URL" введите домен или субдомен Вашего контроллера.
Если Вы хотите, можете добавить URL-адреса для политики конфиденциальности и условий обслуживания, а также значок приложения. Они не влияют на работу приложения, но улучшат профессиональное восприятие портала входа в систему.
Если вы хотите, можете добавить URL-адреса для политики конфиденциальности и условий обслуживания, а также значок приложения. Они не требуются для правильной работы, но улучшат профессиональное восприятие портала входа в систему.

4. Добавьте приложение

Затем нажмите "Add Product", затем "Facebook Login", чтобы создать страницу входа в систему.
Add Product

5. Добавьте субдомен контроллера и порт

В настройках входа в Facebook укажите домен контроллера или субдомен вместе с портами 8880 и 8843. Используйте параметры переключения в приведенном ниже изображении.
  • http://domain.com:8880/
  • https://domain.com:8843/
Add Controller Subdomain and Port
Сохраните изменения перед продолжением.

6. Опубликуйте приложение

Наконец, опубликуйте приложение с помощью "App Review > Make [App Name] Public" и нажмите "Confirm".
Publish App
Если Вы настраиваете и аутентификацию Google тоже, продолжайте чтение. Если нет - перейдите к настройке контроллера.

Настройка API Google+

1. Включите вход через Google

Используйте «Руководство по включению Google+ API», чтобы включить вход через Google.
Шаг 6а в этом руководстве предлагает администратору добавить свое приложения. В этом случае это будет субдомен, за которым следует порт 8880. Обратите внимание на "Client ID" и "Client Secret", которые будут использоваться позже в настройке контроллера.
Enable Google Login
Примечание: Если после установки клиентское устройство получает ошибку переадресации, добавьте URI-переадресацию ниже в разделе «Authorized redirect URIs» на предыдущем шаге:
Enable Google Login

Настройка контроллера UniFi

1. Активируйте гостевые политики

После того, как Вы настроили приложение Facebook или Google, зайдите на свой контроллер. Начните с активации гостевой политики.
Activate Guest Policies

2. Настройте гостевой портал

Затем откройте вкладку "Guest Control ", чтобы настроить гостевой портал. Выберите "Hotspot authentication". Если хотите, введите рекламный URL-адрес для пересылки клиентов на свой веб-сайт после их аутентификации. Выберите "Promotional URL" с использованием имени хоста и введите субдомен контроллера. Выберите "Enable HTTPS Redirection".
Configure the Guest Portal

3. Активируйте метод аутентификации сторонних поставщиков

В разделе "Hotspot", выберите сторонние методы аутентификации, которые Вы хотите активировать. Введите "ID" и "Secret" для выбранных приложений.
Activate Third Party Authentication Method

4. Добавить общедоступные IP-адреса Facebook

В разделе "Access Control" добавьте следующий список общедоступных IP-адресов, которые использует Facebook:
31.13.24.0/21
31.13.64.0/18
45.64.40.0/22
66.220.144.0/20
69.63.176.0/20
69.171.224.0/19
74.119.76.0/22
103.4.96.0/22
129.134.0.0/16
157.240.0.0/16
173.252.64.0/18
179.60.192.0/22
185.60.216.0/22
204.15.20.0/22
Add Facebook's Public IPs

5. Протестируйте гостевую сеть

Наконец, используйте устройство для подключения к гостевой сети и убедитесь, что гостевой портал работает правильно.

Dual Wan и особенности реализации NetWatch в MikroTik

Как работают вместе failover и netwatch. Взгляд изнутри.
Почти каждой более-менее подросшей компании начинает хотеться качества коммуникаций. Среди прочего, заказчику часто хочется отказоустойчивый «Dual WAN» и VoIP телефонию. Тоже отказоустойчивую, разумеется. Руководств и статей по каждой теме в отдельности написано много, но внезапно оказалось, что совместить первое и второе получается не у всех.
Уже есть статья «Mikrotik. Failover. Load Balancing» от vdemchuk. Как оказалось, она послужила для многих источником копипасты кода в маршрутизаторы.
Хорошее, рабочее решение, но SIP-клиенты из LAN, подключающиеся к внешней IP-АТС посредством NAT, при переключении теряли связь. Проблема известная. Связана она с работой Connection tracker, который запоминает имеющиеся соединения вовне, и сохраняет их состояние независимо от других условий.
Понять почему так происходит можно посмотрев на диаграмму packet flow:
Реализация NetWatch в MikroTik
Для транзитного трафика процедура обработки connection tracker выполняется всего в одной цепочке — prerouting, (т.е. до роутинга), до выбора маршрута и исходящего интерфейса. На этой стадии еще неизвестно, через какой интерфейс пакет пойдет в Интернет, и отследить src-ip при нескольких Wan-интерфейсах невозможно. Механизм фиксирует установленные соединения уже пост-фактум. Фиксирует и запоминает на время пока через соединение идут пакеты или пока не истечет заданный таймаут.

Описанное поведение характерно не только для маршрутизаторов MikroTik, но и для большинства Linux-based систем выполняющих NAT.

В результате, при обрыве связи через WAN1, поток данных послушно направляется через WAN2, только SOURCE IP прошедших через NAT пакетов остается неизменный — от интерфейса WAN1, т.к. в connection tracker уже есть соответствующая запись. Естественно, ответы на такие пакеты идут на интерфейс WAN1 уже потерявший связь с внешним миром. В итоге, связь как будто есть, но на самом деле её нет. При этом все новые соединения устанавливаются корректно.
Hint: увидеть с каких и на какие адреса делается NAT можно в колонках «Reply Src. Address» и «Reply Dst. Address». Отображение этих колонок включается в таблице «connections» с помощью правой кнопки мыши.
Реализация NetWatch в MikroTik
На первый взгляд выход выглядит довольно простым — при переключении сбросить ранее установленные SIP-соединения, чтобы они установились заново, уже с новым SRC-IP. Благо простой скрипт по просторам интернета бродит.
Cкрипт
:foreach i in=[/ip firewall connection find dst-address~":5060"] do={ /ip firewall connection remove $i }

Три шага к фейлу

Шаг первый. Копипастеры добросовестно переносят конфиг для Failover recursive routing:
Настройка роутинг из статьи «Mikrotik. Failover. Load Balancing»
# Настроим сети провайдеров:
/ip address add address=10.100.1.1/24 interface=ISP1
/ip address add address=10.200.1.1/24 interface=ISP2
# Настроим локальный интерфейс 
/ip address add address=10.1.1.1/24 interface=LAN
# скроем за NAT все что выходит из локальной сети
/ip firewall nat add src-address=10.1.1.0/24 action=masquerade chain=srcnat
###Обеспечение failover c более глубоким анализом канала###
#с помощью параметра scope укажем рекурсивные пути к узлам 8.8.8.8 и 8.8.4.4
/ip route add dst-address=8.8.8.8 gateway=10.100.1.254 scope=10
/ip route add dst-address=8.8.4.4 gateway=10.200.1.254 scope=10
# укажем 2 default gateway через узлы путь к которым указан рекурсивно
/ip route add dst-address=0.0.0.0/0 gateway=8.8.8.8 distance=1 check-gateway=ping
/ip route add dst-address=0.0.0.0/0 gateway=8.8.4.4 distance=2 check-gateway=ping
Шаг второй. Отследить событие переключения. Чем? "/tool netwatch", естественно! Попытка отследить падение шлюза WAN1 обычно выглядит так:
Netwatch config
/tool netwatch
add comment=«Check Main Link via 8.8.8.8» host=8.8.8.8 timeout=500ms /
down-script=":log warning («WAN1 DOWN»)
:foreach i in=[/ip firewall connection find dst-address~":5060"] do={
:log warning («clear-SIP-connections: clearing connection src-address:$[/ip firewall connection get $i src-address] dst-address:$[/ip firewall connection get $i dst-address]»)
/ip firewall connection remove $i}" 
up-script=":log warning («WAN1 UP»)
:foreach i in=[/ip firewall connection find dst-address~":5060"] do={
:log warning («clear-SIP-connections: clearing connection src-address:$[/ip firewall connection get $i src-address] dst-address:$[/ip firewall connection get $i dst-address]»)
/ip firewall connection remove $i}"
Шаг третий. Проверка.
Админ гасит первый аплинк WAN1 и вручную запускает скрипт. SIP-клиенты переподключились. Работает? Работает! Админ включает обратно WAN1 и вручную запускает скрипт. SIP-клиенты переподключились. Работает? Работает!

Fail

В реальной обстановке такой конфиг работать отказывается. Неоднократное повторение шага №3 приводит админа в состояние озлобления и мы слышим «Не работает ваш микротик!».

Разбор полётов

Всё дело в непонимании того, как происходит работа утилиты Netwatch. Применительно в отношении именно рекурсивного роутинга, утилита просто пингует заданный хост согласно основной таблице маршрутизации, используя активные маршруты.
Проведем эксперимент. Отключим основной канал WAN1 и посмотрим и интерфейс /tool netwatch. Мы увидим, что хост 8.8.8.8 по-прежнему имеет состояние UP.
Для сравнения опция check-gateway=ping, работает для каждого маршрута в отдельности в т.ч. рекурсивно, и делает сам маршрут активным либо НЕактивным.
Netwatch использует уже активные на данный момент маршруты. Когда что-либо происходит на линке до шлюза провайдера ISP1 (WAN1), маршрут до 8.8.8.8 через WAN1 становится неактивным, и netwatch игнорирует его, отправляя пакеты в новый default route. Failover играет злую шутку, и netwatch считает, что всё в порядке.
Второй вариант поведения netwatch, это двойное срабатывание. Механизм его таков: если пинги от netwatch попадут в таймаут check-gateway, то на один цикл проверки хост будет признан DOWN. Сработает скрипт переключения канала. SIP-соединения корректно перейдут на новый линк. Работает? Не совсем.
Скоро таблица маршрутизации перестроится, хост 8.8.8.8 получит статус UP, вновь сработает скрипт сброса SIP-соединений. Соединения второй раз переустановятся через WAN2.
В результате, при возвращении в строй ISP1 и переходе рабочего трафика на WAN1, SIP-соединения так и останутся висеть через ISP2 (WAN2). Чревато это тем, что при проблемах у на запасном канале система этого не заметит и телефонной связи не станет.

Решение

Для того, чтобы трафик на используемый для мониторинга хост 8.8.8.8 не заворачивался на ISP2, нам нужно иметь запасной маршрут до 8.8.8.8. На случай падения ISP1, создаем резервный маршрут с большим значением distance, например distance=10 и type=blackhole. Он и станет активным при пропадании линка до WAN1 Gateway:
/ip route add distance=10 dst-address=8.8.8.8 type=blackhole
В итоге имеем дополнение конфига всего лишь одной строкой:
Исправленный роутинг
# Настроим сети провайдеров:
/ip address add address=10.100.1.1/24 interface=ISP1
/ip address add address=10.200.1.1/24 interface=ISP2
# Настроим локальный интерфейс 
/ip address add address=10.1.1.1/24 interface=LAN
# скроем за NAT все что выходит из локальной сети
/ip firewall nat add src-address=10.1.1.0/24 action=masquerade chain=srcnat
###Обеспечение failover c более глубоким анализом канала###
#с помощью параметра scope укажем рекурсивные пути к узлам 8.8.8.8 и 8.8.4.4
/ip route add dst-address=8.8.8.8 gateway=10.100.1.254 scope=10
/ip route add distance=10 dst-address=8.8.8.8 type=blackhole
/ip route add dst-address=8.8.4.4 gateway=10.200.1.254 scope=10
# укажем 2 default gateway через узлы путь к которым указан рекурсивно
/ip route add dst-address=0.0.0.0/0 gateway=8.8.8.8 distance=1 check-gateway=ping
/ip route add dst-address=0.0.0.0/0 gateway=8.8.4.4 distance=2 check-gateway=ping
Данная ситуация характерна именно при падении последней мили, когда шлюз ISP1 становится недоступным. Либо при использовании туннелей, которые более подвержены падениям в силу цепной зависимости.

Monday, December 10, 2018

MikroTik ACCESS LAN --> WAN --> LAN Hairpin NAT

Hairpin NAT

In the below network topology a web server behind a router is on private IP address space, and the router performs NAT to forward traffic to its public IP address to the web server behind it.
Hairpin nat 1.png
The NAT configuration would look like below:
/ip firewall nat
add chain=dstnat dst-address=1.1.1.1 protocol=tcp dst-port=80 \
  action=dst-nat to-address=192.168.1.2
add chain=srcnat out-interface=WAN action=masquerade
When a client out on the Internet with IP address 2.2.2.2 establishes a connection to the web server, the router performs NAT as configured.
Hairpin nat 2 new.png
  1. the client sends a packet with a source IP address of 2.2.2.2 to a destination IP address of 1.1.1.1 on port tcp/80 to request some web resource.
  2. the router destination NATs the packet to 192.168.1.2 and replaces the destination IP address in the packet accordingly. The source IP address stays the same: 2.2.2.2.
  3. the server replies to the client's request and the reply packet has a source IP address of 192.168.1.2 and a destination IP address of 2.2.2.2.
  4. the router determines that the packet is part of a previous connection and undoes the destination NAT, and puts the original destination IP address into the source IP address field. The destination IP address is 2.2.2.2, and the source IP address is 1.1.1.1.
The client receives the reply packet it expects, and the connection is established.
When a client on the same internal network as the web server requests a connection to the web server's public IP address, the connection breaks.
Hairpin nat 3.png
  1. the client sends a packet with a source IP address of 192.168.1.10 to a destination IP address of 1.1.1.1 on port tcp/80 to request some web resource.
  2. the router destination NATs the packet to 192.168.1.2 and replaces the destination IP address in the packet accordingly. The source IP address stays the same: 192.168.1.10.
  3. the server replies to the client's request. However, the source IP address of the request is on the same subnet as the web server. The web server does not send the reply back to the router, but sends it back directly to 192.168.1.10 with a source IP address in the reply of 192.168.1.2.
The client receives the reply packet, but it discards it because it expects a packet back from 1.1.1.1, and not from 192.168.1.2. As far as the client is concerned the packet is invalid and not related to any connection the client previously attempted to establish.
To fix the issue, an additional NAT rule needs to be introduced on the router to enforce that all reply traffic flows through the router, despite the client and server being on the same subnet. The rule below is very specific to only apply to the traffic that the issue could occur with - if there are many servers the issue occurs with, the rule could be made broader to save having one such exception per forwarded service.
/ip firewall nat
add chain=srcnat src-address=192.168.1.0/24 \
  dst-address=192.168.1.2 protocol=tcp dst-port=80 \
  out-interface=LAN action=masquerade
Hairpin nat 4.png
With that additional rule, the flow now changes:
  1. the client sends a packet with a source IP address of 192.168.1.10 to a destination IP address of 1.1.1.1 on port tcp/80 to request some web resource.
  2. the router destination NATs the packet to 192.168.1.2 and replaces the destination IP address in the packet accordingly. It also source NATs the packet and replaces the source IP address in the packet with the IP address on its LAN interface. The destination IP address is 192.168.1.2, and the source IP address is 192.168.1.1.
  3. the web server replies to the request and sends the reply with a source IP address of 192.168.1.2 back to the router's LAN interface IP address of 192.168.1.1.
  4. the router determines that the packet is part of a previous connection and undoes both the source and destination NAT, and puts the original destination IP address of 1.1.1.1 into the source IP address field, and the original source IP address of 192.168.1.10 into the destination IP address field.
The client receives the reply packet it expects, and the connection is established.
However, the web server only ever sees a source IP address of 192.168.1.1 for all requests from internal clients regardless of the internal client's real IP address. There is no way to avoid this without either using a router that can do application level DNS inspection and can rewrite A records accordingly, or a split DNS server that serves the internal clients the internal server IP address and external clients the external server IP address.

Dynamic DNS Update Script for No-IP DNS

This script is a solution made of others solutions (nothing new). Much of this was adapted from the deprecated version of Dynamic DNS Update Script for behind NAT.
The goal is to update your account on DNSoMatic.com. The main advantage of this solution is that DNSoMatic offers the possibility of propagating DNS updates to thirth party DNSlike systems like OpenDNS, DynDNS, Change IP and other 27 more.
Note: The script below is RouterOS 5.14 & 6.6 Tested!
The following permissions are required for this script to run:
  • write
  • test
  • read
  • policy (for ROS 6.0+)
# DNSoMatic automatic DNS updates

#--------------- Change Values in this section to match your setup ------------------

# User account info of DNSoMatic

:local maticuser "dnsomatic-username"
:local maticpass "dnsomatic-password"

# Set the hostname or label of network to be updated. This is the part after the double colon (::) on the DNSoMatic services page.
# Hostnames with spaces are unsupported. Replace the value in the quotations below with your host names.
# To specify multiple hosts, separate them with commas. 
# Use "all.dnsomatic.com" for the matichost to update all items in dnsomatic with this IP.

:local matichost "hostname1,hostname2"

# Change to the name of interface that gets the changing IP address

:local inetinterface "ether1-gateway"

#------------------------------------------------------------------------------------

# No more changes need

:global previousIP;

:if ([/interface get $inetinterface value-name=running]) do={
# Get the current IP on the interface
    :local currentIP [/ip address get [find interface="$inetinterface" disabled=no] address];
    
# Strip the net mask off the IP address
    :for i from=( [:len $currentIP] - 1) to=0 do={
        :if ( [:pick $currentIP $i] = "/") do={ 
            :set currentIP [:pick $currentIP 0 $i]
        } 
    }
    
    :if ($currentIP != $previousIP) do={
        :log info "DNSoMatic: Update needed"
        :set previousIP $currentIP
        
# The update URL. Note the "\3F" is hex for question mark (?). Required since ? is a special character in commands.
        :local url "http://updates.dnsomatic.com/nic/update\3Fmyip=$currentIP&wildcard=NOCHG&mx=NOCHG&backmx=NOCHG"
        :local matichostarray;
        :set matichostarray [:toarray $matichost];
        :foreach host in=$matichostarray do={
            :log info "DNSoMatic: Sending update for $host"
            /tool fetch url=($url . "&hostname=$host") user=$maticuser password=$maticpass mode=http dst-path=("dnsomaticupdate-" . $host . ".txt")
            :log info "DNSoMatic: Host $host updated on DNSoMatic with IP $currentIP"
        }
    }  else={
        :log info "DNSoMatic: Previous IP $previousIP and current IP equal, no update need"
    }
} else={
    :log info "DNSoMatic: $inetinterface is not currently running, so therefore will not update."
}
This will also need you to configure scheduler entry for periodical runs (maybe every minute or so). You will probably want a second scheduler event run this script upon RouterOS startup.
If for whatever reason the update fails, the script will not update DNSoMatic until the IP address changes again. This is rare, but could happen. It would be recommended to set up a third scheduler with longer intervals (maybe 1 hour) to run a script with the following code:
:global previousIP;
:set previousIP ""

:log info "Cleared previousIP to force DNS-O-Matic update on next run."
The following permissions are required for this script to run:
  • write
  • test (for ROS 6.0+)
  • read (for ROS 6.0+)
  • policy (for ROS 6.0+)
It will silently fail if it doesn't have this permission.

Sunday, November 11, 2018

Как установить веб-сервер Apache в Ubuntu 18.04

Введение

HTTP сервер Apache является самым широко используемым веб-сервером в мире. Он предоставляет множество удобных функций включая динамически загружаемые модули, широкую поддержку мультимедиа, и интеграцию с другим популярным программным обеспечением.
В этом руководстве мы расскажем, как установить веб-сервер Apache на ваш сервер с Ubuntu 18.04.

Необходимые условия

Перед тем, как начать следовать шагам, описанным в этом руководстве, вам необходимо настроить отдельный, не-рутовый (non-root) профиль пользователя на вашем сервере с Ubuntu 18.04. Кроме того, вам потребуется настроить базовый файрвол для блокирования всех портов, кроме необходимых для работы Apache. Вы можете ознакомиться с процессом настройки аккаунта пользователя и настройкой файрвола на вашем сервере следуя шагам нашего руководства по первичной настройке сервера на Ubuntu 18.04.
После завершения создания аккаунта войдите на ваш сервер с помощью вновь созданного пользователя.

Шаг 1 - Установка Apache

Apache доступен из дефолтных репозиториев Ubuntu, что позволяет устанавливать его с помощью средств управления пакетами.
Давайте начнём с обновления локального индекса пакетов:
  • sudo apt update
Далее установим пакет apache2:
  • sudo apt install apache2
После подтверждения установки apt установит Apache и все необходимые зависимости.

Шаг 2 - Настройка файрвола

Перед тестированием установки Apache необходимо изменить настройки файрвола для разрешения доступа извне к дефолным веб-портам. Если вы следовали инструкциям по настройке файрвола из руководства по первичной настройке сервера, ваш файрвол UFW уже должен быть настроен таким образом, чтобы ограничивать доступ к вашему серверу.
В процессе установки Apache регистрирует себя в конфигурации UFW, создавая несколько профилей приложения, которые могут быть использованы для включения и отключения доступа к Apache через файрвол.
Выведем профили приложений ufw следующей командой:
  • sudo ufw app list
Вы увидите список приложений пользователей:
Вывод
Available applications: Apache Apache Full Apache Secure OpenSSH
Как видно из этого вывода, для Apache доступно три профиля:
  • Apache: этот профиль открывает порт 80 (обычный, не шифрованный веб-трафик).
  • Apache Full: этот профиль открывает порты 80 (обычный, не шифрованный веб-трафик) и 443 (трафик шифруется с помощью TLS/SSL).
  • Apache Secure: этот профиль открывает только порт 443 (трафик шифруется с помощью TLS/SSL).
Рекомендуется включать самый ограниченный профиль, который будет позволять входящий трафик. Поскольку мы не настраивали SSL для нашего сервера в этом руководстве, нам потребуется включить только порт 80:
  • sudo ufw allow 'Apache'
Вы можете проверить внесённые изменения командой:
  • sudo ufw status
В выводе вы должны видеть, что HTTP трафик разрешён:
Вывод
Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere Apache ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) Apache (v6) ALLOW Anywhere (v6)
Как видно из этого вывода профиль был включен для разрешения доступа к веб-серверу.

Шаг 3 - Проверка вашего веб-сервера

После завершения процесса установки Ubuntu 18.04 запустит Apache. Веб-сервер уже должен быть запущен.
Проверим в системе инициализации systemd, что сервис работает, следующей командой:
  • sudo systemctl status apache2
Вывод
● apache2.service - The Apache HTTP Server Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled) Drop-In: /lib/systemd/system/apache2.service.d └─apache2-systemd.conf Active: active (running) since Tue 2018-04-24 20:14:39 UTC; 9min ago Main PID: 2583 (apache2) Tasks: 55 (limit: 1153) CGroup: /system.slice/apache2.service ├─2583 /usr/sbin/apache2 -k start ├─2585 /usr/sbin/apache2 -k start └─2586 /usr/sbin/apache2 -k start
Как видно из представленного вывода, сервис выглядит работающим корректно. Тем не менее, самый надёжный способ проверить работу Apache - это запросить веб-страницу.
Вы можете запросить дефолтную веб-страницу Apache с помощью IP адреса вашего сервера. Если вы не знаете IP адрес вашего сервера, вы можете найти его несколькими способами с помощью командной строки.
Введите следующую команду:
  • hostname -I
Она вернёт несколько адресов, разделённых пробелами. Вы можете попробовать каждый из них в вашем веб-браузере.
Другой способ заключается в использовании команды, которая позволяет увидеть ваш IP адрес из другого места в сети Интернет:
  • curl -4 icanhazip.com
После того, как вы найдёте IP адрес вашего сервера, введите его в свой веб-браузер:
  • http://IP_адрес_вашего_сервера
Вы должны увидеть дефолтную страницу Apache для Ubuntu 18.04:
Дефолтная страница Apache
Эта страница свидетельствует о том, что Apache работает корректно. На этой странице также представлена базовая информация о важных файлах и директориях Apache.

Шаг 4 - Управление процессом Apache

Теперь, когда у вас есть работающий веб-сервер, рассмотрим некоторые базовые команды для управления им.
Для остановки себ-сервера наберите:
  • sudo systemctl stop apache2
Для запуска остановленного сервера наберите:
  • sudo systemctl start apache2
Для перезапуска сервиса наберите:
  • sudo systemctl restart apache2
Если вы вносите какие-то изменения в конфигурацию, Apache зачастую может перезагружаться без потери открытых соединений. Для этого наберите команду:
  • sudo systemctl reload apache2
По умолчанию Apache сконфигурирован на запуск при загрузке сервера. Вы можете отключить такое поведение следующей командой:
  • sudo systemctl disable apache2
Для повторного включения сервиса при загрузке сервера наберите:
  • sudo systemctl enable apache2
Теперь Apache должен опять запускаться автоматически при загрузке сервера.

Шаг 5 - Настройка виртуальных хостов (рекомендуется)

При использовании веб-сервера Apache вы можете использовать виртуальные хосты (аналог серверных блоков в Nginx) для хранения конфигурационных настроек разных сайтов. Это позволяет иметь более одного сайта на одном сервере. В этом руководстве мы будем для примера использовать доменное имя example.com, но вам следует заменить его вашим собственным доменным именем. Для того, чтобы узнать больше о настройке доменных имён в DigitalOcean, рекомендуем ознакомиться с нашим Введением в DNS DigitalOcean.
Apache для Ubuntu 18.04 уже имеет один виртуальный хост, включенный по умолчанию, который настроен на отдачу документов из директории /var/www/html. Хотя это и удобно для обслуживания одного сайта, это становится неудобным, когда сайтов несколько. Вместо того, чтобы изменять /var/www/html, давайте создадим новую структуру директорий внутри /var/www для нашего сайта example.com, оставив /var/www/html для показа дефолтной страницы пользователям в случаях, когда клиентский запрос не совпадает ни с одним из настроенных доменных имён.
Создайте директорию для example.com используя флаг -p для создания необходимых родительских директорий:
  • sudo mkdir -p /var/www/example.com/html
Далее настройте владельца директории с помощью переменной окружения $USER:
  • sudo chown -R $USER:$USER /var/www/example.com/html
Теперь права должны для корневой директории быть настроены правильным образом при условии, что вы не меняли своё значение umask. На всякий случай мы можем удостовериться в этом командой:
  • sudo chmod -R 755 /var/www/example.com
Далее создадим страницу index.html в nano или любом другом текстовом редакторе:
  • nano /var/www/example.com/html/index.html
Добавим в файл следующий HTML:
/var/www/example.com/html/index.html
<html>
    <head>
        <title>Welcome to Example.com!</title>
    </head>
    <body>
        <h1>Success!  The example.com server block is working!</h1>
    </body>
</html>
Сохраните и закройте файл.
Для того, чтобы Apache мог отдавать этот контент, нам необходимо настроить виртуальный хост с корректными настройками. Вместо того, чтобы редактировать существующий файл виртуального хоста /etc/apache2/sites-available/000-default.conf, создадим новый файл для нашего сайта - /etc/apache2/sites-available/example.com.conf:
  • sudo nano /etc/apache2/sites-available/example.com.conf
Скопируйте следующий текст настроек виртуального хоста в созданный файл:
/etc/apache2/sites-available/example.com.conf
<VirtualHost *:80>
    ServerAdmin admin@example.com
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /var/www/example.com/html
    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
Обратите внимание, что мы обновили DocumentRoot на адрес нашей новой директории, и ServerAdmin на адрес электронной почты, доступный для администратора example.com. Мы также добавили две директивы: ServerName, которая устанавливает базовое доменное имя, которое должно использоваться для хоста, а также ServerAlias, которая определяет другие имена, которые должны использоваться для отображения хоста так же, как и базовое доменное имя.
Сохраните и закройте файл после внесения изменений.
Теперь активируем профиль сайта с помощью утилиты a2ensite:
  • sudo a2ensite example.com.conf
Деактивируем дефолтный сайт, определённый в 000-default.conf:
  • sudo a2dissite 000-default.conf
Далее проверим наши настройки на наличие ошибок:
  • sudo apache2ctl configtest
Вы должны увидеть следующий вывод:
Вывод
Syntax OK
Перезапустите Apache для применения внесённых изменений:
  • sudo systemctl restart apache2
Теперь Apache должен работать с вашим доменным именем. Вы можете проверить это введя http://example.com в вашем браузере, где в результате вы должны увидеть что-то в этом роде:
Успешная работа Apache

Шаг 6 - Важные файлы и директории Apache

Теперь, когда вы знаете, как управлять сервисом Apache, вам стоит ознакомиться с важными файлами и директориями Apache.

Контент

  • /var/www/html: фактический веб-контент, который по умолчанию состоит только из дефолтной страницы Apache, которую мы видели ранее, хранится в директории /var/www/html. Это может быть изменено в конфигурационных файлах Apache.

Конфигурация сервера

  • /etc/apache2: это конфигурационная директория Apache. Все файлы конфигурации Apache находятся здесь.
  • /etc/apache2/apache2.conf: главный конфигурационный файл Apache. Изменения в этом файле влияют на глобальную конфигурацию Apache. Этот файл отвечает за загрузку многих других файлов из конфигурационной директории.
  • /etc/apache2/ports.conf: этот файл определяет порты, которые Apache будет слушать. По умолчанию Apache слушает порт 80, а также порт 443 при условии, что модуль для работы с SSL включен.
  • /etc/apache2/sites-available/: в этой директории хранятся файлы виртуальных хостов. Apache не использует файлы из этой директории, если ссылки на них нет в директории sites-enabled. Обычно настройка всех файлов виртуальных хостов осуществляется в этой директории, а активация хоста происходит путём создания ссылки в другой директории командой a2ensite.
  • /etc/apache2/sites-enabled/: директория, в которой хранятся активированные виртуальные хосты. Обычно это делается путём создания ссылки на файл конфигурации хоста из директории sites-available с помощью команды a2ensite. Apache читает конфигурационный файлы и ссылки из этой директории при запуске или перезапуске.
  • /etc/apache2/conf-available//etc/apache2/conf-enabled/: эти директории связаны друг с другом так же, как и sites-available и sites-enabled связаны друг с другом, но используются для хранения фрагментов конфигурации, которые не принадлежат виртуальным хостам. Файлы в директории conf-available могут быть включены командой a2enconf и выключены командой a2disconf.
  • /etc/apache2/mods-available//etc/apache2/mods-enabled/: эти директории содержат, соответственно, доступные и активные модули. Файлы, оканчивающиеся на .load, содержат фрагменты для загрузки конкретных модулей, а файлы, оканчивающиеся на .conf, содержат настройки этих модулей. Модули можно активировать командой a2enmod и деактивировать командой a2dismod.

Серверные логи

  • /var/log/apache2/access.log: по умолчанию каждый запрос к вашему веб-серверу записывается в этом файле, если только Apache не настроен на другое поведение.
  • /var/log/apache2/error.log: по умолчанию все ошибки записываются в этот файл. Директива LogLevel в конфигурации Apache определяет, насколько детальными должны быть записи об ошибках.