Архів рубрики: Мережа

Шифрований (https) доступ до wiki (http) за допомогою Nginx

До wiki сайту треба створити зашифрований SSL доступ. Wiki працює всередині віртуальної машини і не має можливості дати йому реального IP. Тому шифрування доступу будемо здійснювати засобами Nginx.

Схема буде такою:

Nginx (https) -> proxy_pass -> Apache (http) with Wiki

Генерація штучного SSL сертифікату доволі тривіальна задача, не будемо зупинятися на цьому.

Налагодження Nginx складається з 3-х частин:

  • переведення всього HTTP трафіку у HTTPs
  • проксування HTTPs з Nginx на Apache з wiki
  • зміна $wgServer у параметрах wiki

1. Перетворюємо HTTP запити у дзеркальні HTTPs

server {
    listen   80;
    server_name ДОМЕН;
    rewrite ^ https://$server_name$request_uri? permanent;
}

2. Проксуємо трафік до wiki

server {
    listen   443;
    server_name ДОМЕН;
    ssl  on;
    ...
    location / {
        proxy_pass       http://ЛОКАЛЬНА_АДРЕСА_WIKI:80;
        proxy_set_header Host      $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_redirect   off;
    }
}

3. Міняємо http на https у змінній $wgServer

Після перших 2-х кроків ми практично зробили шифроване з’єднання, але деякі посилання всередині wiki сторінок містять http протокол.

Треба відредагувати файл LocalSettings.php і замінити:

$wgServer = "http://ДОМЕН";

на

$wgServer = "https://ДОМЕН";

Видалення правил iptables за їх порядковим номером

Фільтр iptables досить ризикований інструмент, заплутаний проте дуже потужний.

Сьогодні дізнався як видалити одне правило з ланцюжка за його порядковим номером. Для цього достатньо додати параметер –line-numbers:

# iptables -nL -v --line-numbers -t nat
Chain PREROUTING (policy ACCEPT 1463 packets, 92569 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1        2   120 DNAT       tcp  --  *      *       0.0.0.0/0            ...

Chain POSTROUTING (policy ACCEPT 323 packets, 27643 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1        0     0 MASQUERADE  tcp  --  *      *       192.168.122.0/24    ...
2        1    76 MASQUERADE  udp  --  *      *       192.168.122.0/24    ...
3        0     0 MASQUERADE  all  --  *      *       192.168.122.0/24    ...

Chain OUTPUT (policy ACCEPT 198 packets, 14282 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Стовпець num вказує порядковий номер. Мені потрібен перший запис у ланцюжку PREROUTING. Видаляю його командою:

# iptables -D PREROUTING 1 -t nat

Ping та завантаженість каналу мережі

Коли локальна мережа та підключення до інтернету поєднані через некеровані комутатори (свічі), то досить важко визначити на якому саме напрямку проблеми.

Корисна утиліта ping дає, на перший погляд, тільки приблизну оцінку того, як саме пакети йдуть мережею і який відсоток втрат. Але якщо уважно придивитися до її виводу, то можна побачити одну характерну ознаку, яка може свідчити про проблеми у пропускній здатності каналу чи мережевої карти: істотне коливання часу відповіді echo reply на запит echo request.

Поясню на прикладі:

$ ping 192.168.0.26
PING 192.168.0.26 (192.168.0.26) from 192.168.0.22 : 56(84) bytes
 of data.
64 bytes from 192.168.0.26: icmp_seq=1 ttl=64 time=0.890 ms
64 bytes from 192.168.0.26: icmp_seq=2 ttl=64 time=0.503 ms
64 bytes from 192.168.0.26: icmp_seq=3 ttl=64 time=0.485 ms
64 bytes from 192.168.0.26: icmp_seq=4 ttl=64 time=0.492 ms
64 bytes from 192.168.0.26: icmp_seq=5 ttl=64 time=0.495 ms
64 bytes from 192.168.0.26: icmp_seq=6 ttl=64 time=0.502 ms
64 bytes from 192.168.0.26: icmp_seq=7 ttl=64 time=0.476 ms
64 bytes from 192.168.0.26: icmp_seq=8 ttl=64 time=0.490 ms
64 bytes from 192.168.0.26: icmp_seq=9 ttl=64 time=0.499 ms
64 bytes from 192.168.0.26: icmp_seq=10 ttl=64 time=0.492 ms
64 bytes from 192.168.0.26: icmp_seq=11 ttl=64 time=0.496 ms
64 bytes from 192.168.0.26: icmp_seq=12 ttl=64 time=0.476 ms
64 bytes from 192.168.0.26: icmp_seq=13 ttl=64 time=0.487 ms
64 bytes from 192.168.0.26: icmp_seq=14 ttl=64 time=0.487 ms
64 bytes from 192.168.0.26: icmp_seq=15 ttl=64 time=0.480 ms
64 bytes from 192.168.0.26: icmp_seq=16 ttl=64 time=0.500 ms
64 bytes from 192.168.0.26: icmp_seq=17 ttl=64 time=0.485 ms
64 bytes from 192.168.0.26: icmp_seq=18 ttl=64 time=0.477 ms

--- 192.168.0.26 ping statistics ---
18 packets transmitted, 18 received, 0% loss, time 17017ms
rtt min/avg/max/mdev = 0.476/0.511/0.890/0.096 ms

Тут все гаразд, відхилення звичайно є, але в середньому (0.096 ms) вони не істотні. І зовсім інша картина у наступному прикладі:

$ ping 192.168.10.10
PING 192.168.10.10 (192.168.10.10) from 192.168.10.1 : 56(84) bytes
 of data.
64 bytes from 192.168.10.10: icmp_seq=1 ttl=128 time=4.41 ms
64 bytes from 192.168.10.10: icmp_seq=2 ttl=128 time=0.730 ms
64 bytes from 192.168.10.10: icmp_seq=3 ttl=128 time=0.804 ms
64 bytes from 192.168.10.10: icmp_seq=4 ttl=128 time=0.724 ms
64 bytes from 192.168.10.10: icmp_seq=5 ttl=128 time=0.740 ms
64 bytes from 192.168.10.10: icmp_seq=6 ttl=128 time=0.734 ms
64 bytes from 192.168.10.10: icmp_seq=7 ttl=128 time=3.03 ms
64 bytes from 192.168.10.10: icmp_seq=8 ttl=128 time=2.61 ms
64 bytes from 192.168.10.10: icmp_seq=9 ttl=128 time=0.730 ms
64 bytes from 192.168.10.10: icmp_seq=10 ttl=128 time=0.746 ms
64 bytes from 192.168.10.10: icmp_seq=11 ttl=128 time=0.720 ms
64 bytes from 192.168.10.10: icmp_seq=12 ttl=128 time=0.721 ms
64 bytes from 192.168.10.10: icmp_seq=13 ttl=128 time=0.911 ms
64 bytes from 192.168.10.10: icmp_seq=14 ttl=128 time=0.741 ms
64 bytes from 192.168.10.10: icmp_seq=15 ttl=128 time=0.754 ms
64 bytes from 192.168.10.10: icmp_seq=16 ttl=128 time=2.54 ms
64 bytes from 192.168.10.10: icmp_seq=17 ttl=128 time=0.731 ms
64 bytes from 192.168.10.10: icmp_seq=18 ttl=128 time=2.04 ms
64 bytes from 192.168.10.10: icmp_seq=19 ttl=128 time=0.739 ms
64 bytes from 192.168.10.10: icmp_seq=20 ttl=128 time=0.730 ms
64 bytes from 192.168.10.10: icmp_seq=21 ttl=128 time=0.728 ms

--- 192.168.10.10 ping statistics ---
21 packets transmitted, 21 received, 0% loss, time 20205ms
rtt min/avg/max/mdev = 0.720/1.268/4.419/1.011 ms

На час першого відгуку (4.41 ms) не звертаємо увагу, але я спеціально позначив аномальний час 7, 8, 16 та 18 запитів. Це саме ті моменти, коли час відповіді істотно відрізняється. В обох прикладах відсоток втрати пакетів нульовий, але у другому можна стверджувати, що мережевий канал чи пристрій істотно завантажені.