Tohle je věc, která mě dráždí už dlouho. Když přijde na publikování nějaké aplikace, která má webový interface, dřív nebo později to skončí tím, že mají uživatelé v nejrůznějších poznámkách něco podobného:

Přístup k administraci docházky: http://mail.mojefirma.cz:88/dochazka

Objednávání obědů: http://mail.mojefirma.cz:8880/

Přístup k poště: https://mail.mojefirma.cz/owa

Jak dlouho ještě budeme my, ajťáci, předstírat, že to je úplně v pořádku? Když to takhle budeme dělat dál, i průměrný ajťák bude objednávat obědy tak, že se nejdřív logne na firewall, podívá se, na jakém portu je aplikace publikovaná, pak se koukne do konfigurace IISka, na jaké cestě ji hledat, a URL vykonstruuje z čisté vody. To je na zcvoknutí! Vážně věříte, že si ty adresy může normální člověk pamatovat?

Takže konec! Od teďka chci, aby všechny mé aplikace měly následující formát:

Přístup k administraci docházky: http://dochazka.mojefirma.cz

Objednávání obědů: http://obedy.mojefirma.cz

Přístup k poště: http://mail.mojefirma.cz

A ještě něco, chci, aby uživatel sice napsal do adresního řádku jen napříkladdochazka.mojefirma.cz a aby jej to samo přesměrovalo na zabezpečené připojení, které nebude na každém cizím počítači otravovat s nedůvěryhodným certifikátem. Dokonce, i když ta obskurní aplikace https neumí.

V první řadě si ujasněme, proč vlastně k tomuto neblahému jevu dochází.

Prvním, asi hlavním, důvodem je to, že IPv4 adres je málo a často mám k dispozici jenom jednu veřejnou adresu, což mě nutí k používání jiných, než standardních portů, tedy v případě HTTP a HTTPS jsou to porty jiné než TCP/80 a TCP/443. A když použiju jiný, než standardní port, musím jej uvést do URL, grrr!

Dalším, podstatným, důvodem je fakt, že pokud aplikace nesedí na stejném serveru, těžko pomocí prostého forwardování stejného portu zjistíme, kam bychom měli provoz směrovat. Jistě jste si všimli, že NAT forwarding ve svém nastavení nemá žádnou možnost, jak zjistit, zda uživatel přistupuje na konkrétní jméno, všechna nastavení jsou od podstaty věci jen kombinací veřejné IP, cílového portu na veřejné straně a neveřejné IP adresy s jejím cílovým portem na serveru s aplikací v lokální síti.

Poněkud nepříjemnou drobností je navíc fakt, že pokud naopak na lokálním serveru běží více aplikací, dost často využívají stejný virtuální server (pozdravuji, Default website IIS) a přístup k nim se liší jen cestou za lomítkem.

Je tedy zjevné, že potřebujeme něco univerzálnějšího. To co hledáme, je tzv. reverzní proxy. Ve své podstatě se jedná o speciálně nakonfigurovaný webový server, který místo toho, aby sám servíroval, mnohdy dynamický obsah, tak jen předává a přeposílá požadavky, které vyřizují servery v lokální síti. A webový server, jak známo, umí rozpoznat jméno, na které uživatel přistoupil, umí tzv. URL rewriting, což nám umožní zbavit se těch stupidních konců URL za lomítkem a umí si poradit i se šifrováním pomocí certifikátů tak, abychom mohli obsah do světa posílat přes HTTPS. No a taky umí provést prosté přesměrování, čehož využijeme k tomu, abychom uživatele, který do adresního řádku prohlížeče vyťuká ono dochazka.mojefirma.cz, bez dalšího ptaní poslali na http://dochazka.mojefirma.cz.

Takže jaký je plán:

1. Nainstalujeme si do nějakého (maličkého, 1CPU, 512MB RAM, 8GB HDD) virtuálního stoje Ubuntu Linux (já ještě používám 14.04 LTS, nějak jsem ještě nepřivykl systemd).
2. Veřejné adrese našeho routeru přidělíme v DNS nějaké pěkné jméno pomocí A záznamu: 1.2.3.4 IN A rproxy.mojefirma.cz.
3. Pro všechny aplikace si posléze budeme vytvářet CNAME, třeba: dochazka IN CNAME rproxy.mojefirma.cz..
4. Do virtuálního stroje nainstalujeme webový server NGINX, který nám bude sloužit jako reverzní proxy.
5. Na firewallu nastavíme publikování portů TCP/80 a TCP/443 na virtuál s reverzní proxy.
6. Nakonfigurujeme pro každou aplikaci samostatný virtuální server (v NGINX, ne v hypervizoru) a dle požadavků nastavíme reverzní proxy na konkrétní server s danou aplikací.
7. Nastavíme si URL rewrite tak, aby cesty v URL nemusely obsahovat vždy se opakující společnou část, tedy abychom nemuseli zadávat např. http://dochazka.mojefirma.cz/dochazka, ale jen http://dochazka.mojefirma.cz.
8. Rozběhneme si HTTPS pomocí certifikátů generovaných buď pomocí certifikační autority Let’s Encrypt, nebo si certifikát pro každou aplikaci koupíme.
9. Nakonec se podíváme na možnost, jak pomocí reverzní proxy publikovat MS Exchange, protože, jak jinak, tohle chce NGINX trošku ohnout.

Následující postup předpokládá, že už máte nainstalovaný server s Ubuntu Linuxem, který má pevnou privátní IP adresu, a že jste již nastavili publikování HTTP a HTTPS provozu na firewallu sem, a že již máte nastavené DNS záznamy dle bodů 2 a 3 výše.

Snad jediná poznámka — je vhodné, abyste při publikování mysleli na to, že chcete, aby provoz z internetu pro naši publikovanou reverzní proxy vypadal, jako kdyby přišel z původní IP, ne z lokální IP firewallu. Jak na to, to se liší dle výrobce firewallu/routeru, takže to nechám na vaší šikovnosti.

Instalace NGINX

Instalace NGINX je jednoduchá, stačí použít balíčkovací systém vaší distribuce, v mém případě je to apt:

sudo apt-get update
sudo apt-get install nginx -y
sudo service nginx start      # pro jistotu, kdyby nenastartoval sám

Pokud do prohlížeče zadáte jméno vaší reverzní proxy (takže třeba http://rproxy.mojefirma.cz), měli byste, pokud jste někde neudělali chybu v publikování na firewallu, dostat následující výsledek:

Konfigurace reverzní proxy pro první dvě aplikace

Předpokládejme, že vaše aplikace běží jen na HTTP, každá na jiném serveru a alespoň jedna na nějakém alternativním portu.

Takže, pro účely našeho příkladu, první aplikace (docházka) je lokálně dostupná na http://192.168.1.23/dochazka a druhá (objednávání obědů) je k dispozici na http://192.168.1.20:88.

Pro zopakování, chceme aby ta první byla k dispozici na adrese http://dochazka.mojefirma.cz a ta druhá na http://obedy.mojefirma.cz.

Zatím se nebudeme trápit tím, jak zajistit přepisování URL na konci, tedy v prvním případě se spokojíme s URL ve tvaru http://dochazka.mojefirma.cz/dochazka. URL rewiting si popíšeme v dalším díle.

Nejprve vytvoříme 2 konfigurační soubory, já používám editor nano:

sudo nano /etc/nginx/sites-available/dochazka.mojefirma.cz

Já mám ve zvyku pojmenovávat si konfigurační soubory pro NGINX podle celého jména site (tedy dochazka.mojefirma.cz), nicméně volba je na vás.

Obsahem souboru bude následující:

server {
  listen 80;
  server_name dochazka.mojefirma.cz;
  access_log            /var/log/nginx/dochazka.access.log;  location / {
    proxy_set_header        Host $host;
    proxy_set_header        X-Real-IP $remote_addr;
    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header        X-Forwarded-Proto $scheme;    proxy_pass          http://192.168.1.23;
    proxy_read_timeout  90;    proxy_redirect      http://192.168.1.23 http://dochazka.mojefirma.cz;
  }
}

Konfigurační soubor pro druhou aplikaci vytvoříme pomocí

sudo nano /etc/nginx/sites-available/obedy.mojefirma.cz

Jeho obsahem bude:

server {
  listen 80;
  server_name obedy.mojefirma.cz;
  access_log            /var/log/nginx/obedy.access.log;location / {
    proxy_set_header        Host $host;
    proxy_set_header        X-Real-IP $remote_addr;
    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header        X-Forwarded-Proto $scheme;    proxy_pass          http://192.168.1.20:88;
    proxy_read_timeout  90;proxy_redirect      http://192.168.1.23:88 http://obedy.mojefirma.cz;
  }
}

Tím jsme si připravili konfigurační soubory. NGINX (alespoň na Ubuntu) includuje všechny soubory, které najde v adresáři /etc/nginx/sites-enabled. Bývá dobrým zvykem mít všechny konfigurační soubory uložené v /etc/nginx/sites-available a pak už jen linkovat ty, které chcete právě zapnout. Já to dělám pomocí následujícího postupu:

cd /etc/nginx/sites-enabled
sudo ln -s ../sites-available/dochazka.mojefirma.cz
sudo ln -s ../sites-available/obedy.mojefirma.cz

Jakmile mám v adresáři sites-enabled/ nalinkované soubory, pro jistotu ověřím, že jsem neudělal nějakou chybu v syntaxi pomocí příkazu:

sudo nginx -t

Odpovědí bude v případě úspěchu násleující:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

V takovém případě můžeme NGINX donutit převzít naši novou konfiguraci:

sudo service nginx reload

Můžete vyzkoušet přístup na oba weby zadáním http://dochazka.mojefirma.cz/dochazka (nezapomeňte, adresář z URL budeme ještě odstraňovat příště) a http://obedy.mojefirma.cz a naše krásná nová reverzní proxy nám z jediné veřejné IP adresy servíruje dva různé weby na dvou různých serverech a ještě každý běžící na jiném portu.

Zdroj: Robert Houser
https://blog.pbcom.cz/je%C5%A1t%C4%9B-nepou%C5%BE%C3%ADv%C3%A1te-reverzn%C3%AD-proxy-ab536b04c2f7

V komentáři k mému předchozímu článku o reverzní proxy mě Jindrich Sarson upozornil, že se mu osvědčilo používat tzv. upstream direktivu k definici backend serverů. Původně jsem chtěl jen aktualizovat původní článek, neb to považuji za přínosný komentář, ale nakonec jsem usoudil, že to chce maličko vysvětlení, než jen přidat pár řádků do příkladu konfiguračního souboru.

Nejprve o co jde. V zásadě je to možnost definovat si cílový server v lokální síti jako “entitu” a na tu pak odkazovat v konfiguraci. Vezmu-li za příklad naše produkční prostředí, kde mám v /etc/nginx/sites-enabled nějakých 20 konfiguračních souborů, které porůznu ukazují na 4 různé servery, zdá se to být jako dobrý nápad. Když dojde k nějaké změně, například v IP adrese, nebo třeba přidáte nějaký fail-over server, stačí to definovat na jednom místě.

Jak na to. Nejprve si připravte definici upstream serverů, nejlépe v nginx.conf:

sudo nano /etc/nginx/nginx.conf

A do sekce http přidejte definici upstream serverů těsně nad řádek s include /etc/nginx/sites-enabled/*. Pro příklad z našeho předchozího článku bude vypadat nějak takhle:

http {  # ......puvodni obsah, je ho tam dost :-)  upstream dochazka {
    server 192.168.1.23;
  }  upstream obedy {
    server 192.168.1.20:88;
  }
 
  # ------konec upstream definici  # ------puvodni obsah souboru
  include /etc/nginx/sites-enabled/*;
}

V konfiguračních souborech bude potom změna vypadat takhle:

sudo nano /etc/nginx/sites-available/dochazka.mojefirma.cz

Obsah:

server {
  listen 80;
  server_name dochazka.mojefirma.cz;
  access_log            /var/log/nginx/dochazka.access.log;location / {
    proxy_set_header        Host $host;
    proxy_set_header        X-Real-IP $remote_addr;
    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header        X-Forwarded-Proto $scheme;proxy_pass          http://dochazka;
    proxy_read_timeout  90;
  }
}

Všiměte si, že jsem proti původní verzi vymazal direktivu proxy_redirect, není pro náš účel v tuto chvíli nutná (ale nevadí), zatoulala se mi tam z mé konfigurace, kde jsem si řešil konkrétní situaci, kdy jsem potřeboval přepisovat HTTP HEADER Location.

Konfigurační soubor pro aplikaci obědy:

sudo nano /etc/nginx/sites-available/obedy.mojefirma.cz

Jeho obsahem bude:

server {
  listen 80;
  server_name obedy.mojefirma.cz;
  access_log            /var/log/nginx/obedy.access.log;location / {
    proxy_set_header        Host $host;
    proxy_set_header        X-Real-IP $remote_addr;
    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header        X-Forwarded-Proto $scheme;proxy_pass          http://obedy;
    proxy_read_timeout  90;
  }
}

Druhá, důležitá, poznámka. Port, na který přesměrováváte v lokální síti, je součástí definice pomocí upstream direktivy, není tedy možné jej v upstream vynechat a pak jej přidat v konfiguraci virtuálního serveru. Tohle proxy_pass http://obedy:88; je tedy špatně a nebude to fungovat. (A pokud svědomitě používáte nginx -t před každým naloadováním konfigurace, řekne vám to 🙂

Zdroj: Robert Houser
https://blog.pbcom.cz/reverzn%C3%AD-proxy-upstream-direktiva-daebeee19ddf

Málokterá aplikace neobsahuje data. A když obsahuje nějaká data, musíte je chránit před neautorizovaným přístupem. A není hloupější způsob, jak data vyzdradit, než je nechat téci internetem v otevřené podobě.

A dokonce i v případě, že aplikace žádná citlivá data neobsahuje (třeba naše vzorová, s objednáváním obědů), je dost hloupé nechat sniffnout svým uživatelům přístupové heslo. A věřte, že máte 95% šanci, že heslo, které používají do objednávání obědů, budou mít naši uživatelé i do pošty, Windows, do všeho… 🙂

Tenhle článek je pokračováním série o reverzní proxy NGINX.

Výhodou reverzní proxy je, že i když budete mít potřebu do internetu vystrčit nějakou obskurní aplikaci, která třeba ani HTTPS neumí, je jednoduché ji pomocí reverzní proxy zabezpečit.

Poznámka: bavíme se o zabezpečení přenosového kanálu šifrováním pomocí SSL, tedy o použití HTTPS. Vůbec, ani v nejmenším, nemluvíme o bezpečnosti samotné webové aplikace.

Takže, jaký je plán

Abychom mohli zajistit HTTPS, musíme udělat následující kroky:

1. Zajistit si důvěryhodný certifikát. To se dá udělat buď za peníze (možná jednodušší varianta), nebo s jistou spotřebou lidského sádla zadarmo. My se budeme zabývat variantou zadarmo, s použitím certifikační autority Letsencrypt. Pokud si chcete certifikát koupit, prostě přeskočíte některé body.
2. Rozběhnout reverzní proxy tak, aby fungovala stejně při zadání adresy ve formátu http://aplikace.mojefirma.cz i https://aplikace.mojefirma.cz.
3. Nakonec udělat redirect, aby kdykoliv uživatel zkusí přistoupit na adresu v nezašifrované podobě, tedy přes HTTP, byl okamžitě, bez ptaní přesměrován na HTTPS.

Cerifikát

Pokud si certifikát hodláte koupit, přeskočte následujících pár odstavců a jděte rovnou na konfiguraci NGINXu pro HTTPS. Jinak začneme instalací Letsencrypt klienta z Githubu:

sudo -s
apt-get install -y git bc
git clone https://github.com/letsencrypt/letsencrypt /opt/letsencrypt

Důležitá věc. Ujistěte se, že soubor /etc/nginx/sites-enabled/default odkazuje do adresáře /usr/share/nginx/html. Pokud jste instalovali NGINX na čisté Ubuntu 14.04 LTS dle návodu v minulých dílech, tak to tak bude, ale jinak je potřeba vědět, že do tohoto adresáře budeme ukládat soubory k ověření žádosti u certifikační autority a tím pádem je nutné, aby to co tam uložíme, náš NGINX naservíroval do světa. Stačí, když tento adresář pojede ven po HTTP, takže do /etc/nginx/sites-enabled/default nebudete muset sáhnout.

Druhá důležitá věc. Pokud jedete nějakou zkratkou a ještě nemáte v DNS připravený CNAME se jménem vaší aplikace (a tedy tím, co bude v certifikátu), nejpozději teď je chvíle, kdy to musíte udělat, jinak následující krok neprojde. Pokud to uděláte až teď, doporučuji si po vytvoření CNAME záznamu dát pět minut pauzu na kafe nebo cigáro (já preferuju kafe) a počkat, až váš registrátor zaktualizuje DNS servery. Což bývá většinou skoro hned (proto těch 5 minut). Když zkusíte ze zvědavosti spustit žádost o certifikát příliš brzy, certifikační autorita sáhne do DNS, nakešuje si informaci o tom, že jméno ještě neexistuje a vy budete třeba hodinu čekat (většina našich registrátorů neumožňuje TTL v DNS kratší než 1 hodina), než bude možné žádost dokončit. Takže se těch pět minutek zdržení vyplatí, věřte mi, už jsem čekal, jinak bych to tu nepsal.

Takže pokud máme DNS záznam v pořádku hotový, necháme si vygenerovat certifikát:

cd /opt/letsencrypt
./letsencrypt-auto certonly -a webroot -d aplikace.mojefirma.cz --webroot-path=/usr/share/nginx/html

Název aplikace.mojefirma.cz samozřejmě nahradíte DNS jménem své aplikace, v našich příkladech tedy dochazka.mojefirma.cz nebo obedy.mojefirma.cz, podle toho, pro kterou doménu certifikát vytváříte. Je samozřejmě možné do jednoho certifikátu uvést více jmen, ale v našem případě to nedoporučuji, držte si všechny certifikáty zvlášť. Hvězdičkový (wildcard) certifikát Letsencrypt neumí, více jmen se používá typicky, když chcete publikovat www server ve variantě s a bez “www”. Potom náš příklad vypadá takhle (už bez přechodu do adresáře /opt/letsencrypt:

./letsencrypt-auto certonly -a webroot -d www.mojefirma.cz -d mojefirma.cz --webroot-path=/usr/share/nginx/html

Ale to jen pro úplnost.

Ve výstupu by se mělo objevit něco podobného:

Reporting to user: Congratulations! Your certificate and chain have been saved at /etc/letsencrypt/live/aplikace.mojefirma.cz/fullchain.pem. Your cert will expire on 2017-04-17. To obtain a new or tweaked version of this certificate in the future, simply run letsencrypt-auto again. To non-interactively renew *all* of your certificates, run "letsencrypt-auto renew"If you like Certbot, please consider supporting our work by:Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
Donating to EFF:                    https://eff.org/donate-le

Pokud se objeví nějaké chyby, je to buď proto, že jste mi nevěřili a po aktualizaci DNS jste to zkoušeli moc rychle, pak je potřeba počkat, nebo náš NGINX neobsluhuje naši --webroot-path. Každopádně čas na debugging.

Nicméně nám zatím všechno zafungovalo a z výše uvedeného výstupu nás zajímá tohle — /etc/letsencrypt/live/aplikace.mojefirma.cz/fullchain.pem. To je cesta k našemu certifikátu, se kterou budeme operovat dál.

Když se podíváte na platnost svého nového certifikátu, zjistíte, že byl vygenerován na 3 měsíce. To je daň za to, že je to zadarmo. Ale na druhou stranu, protože případné prodloužení je takhle jednoduché (automaticky prodlouží VŠECHNY certifikáty, kterým bude brzy končit platnost):

/opt/letsencrypt-auto renew

A taky je hezké, že pokud není žádný certifikát k prodloužení, nic se nestane, takže stačí přidat tento příkaz do crontabu a máme klid:

crontab -e#tohle přidejte do souboru, který se vám otevře v editoru:
30 2 * * 1 /opt/letsencrypt/letsencrypt-auto renew >> /var/log/le-renewal.log

Tenhle řádek zajistí, že se automatická obnova spustí každou neděli ve 2:30 v noci a výstup se pošle (přidá) do souboru /var/log/le-renewal.log.

Rozběhnutí HTTPS na NGINX

Když už máme certifikát, je rozběhnutí HTTPS na NGINXu až směšně jednoduché. Ukážeme si na příkladu naší aplikace dochazka.mojefirma.cz.

Otevřeme konfigurační soubor:

nano /etc/nginx/sites-enabled/dochazka.mojefirma.cz

…a přidáme novou sekci server, která bude vypadat takhle:

server {
  listen 443 ssl;  server_name dochazka.mojefirma.cz;  ssl_certificate           /etc/letsencrypt/live/dochazka.mojefirma.cz/fullchain.pem;
  ssl_certificate_key       /etc/letsencrypt/live/dochazka.mojefirma.cz/privkey.pem;  ssl on;
  ssl_session_cache  builtin:1000  shared:SSL:10m;
  ssl_protocols  TLSv1 TLSv1.1 TLSv1.2;  access_log            /var/log/nginx/dochazka.mojefirma.cz.access.log;  location / {
    proxy_set_header        Host $host;
    proxy_set_header        X-Real-IP $remote_addr;
    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header        X-Forwarded-Proto $scheme;    proxy_pass          http://dochazka; #upstream direktiva,
                                         #lze i http://192.168.1.23
    proxy_read_timeout  90;
  }  # kvuli obnove certifikatu
  root /usr/share/nginx/html;
  location ~ /.well-known {
    allow all;
  }}

Což v podstatě znamá, že jsme původní server na portu TCP/80 (HTTP) opráskli i s chlupama, jen jsme přidali pár voleb pro SSL a na konci jsme nechali obsloužit cestu, do které si sahá autorenew od Letsencrypt.

Otestujeme, jestli jsme něco nerozbili (doporučuji, když pak máte na jedné reverzní proxy vícero služeb, není nic horšího, než si celou konfiguraci rozbít a kvůli chybějícímu středníku na sebe nechat od uživatelů používat zlé maďarské výrazy):

nginx -t

A pokud je vše v pořádku, reloadneme konfiguraci:

service nginx reload

Pak je možné vyzkoušet, zda nám funguje jednak přístup na adresu http://dochazka.mojefirma.cz (to jestli jsme opravdu něco nerozbili) a taky https://dochazka.mojefirma.cz. Mělo by to fungovat, bez jakýchkoliv varování a chyb, já takhle publikuji i všechny naše weby, nejen interní aplikace:

Nastavení automatického přesměrování

Těžko budeme své uživatele nutit, aby si pamatovali, že před adresu, na kterou se chystají přistoupit musí napsat https://. Předpokládejme, že prostě napíšou (když už si to vůbec budou ochotni pamatovat) jen třeba dochazka.mojefirma.cz a tím to zhasne. Takže potřebujeme nějaký mechanismus, který je přesměruje. Což je jednoduché, už nám chodí https, takže stačí změnit konfiguraci virtuálního serveru, který obsluhuje HTTP protokol na portu TCP/80 a místo servírování obsahu jej přepnout na redirect. Takže patřičnou sekci server {…} nahradíme:

nano /etc/nginx/sites-enabled/dochazka.mojefirma.cz

Celá sekce server obsluhující nezabezpečené HTTP bude vypadat takto:

server {
  listen 80;
  server_name dochazka.mojefirma.cz
  return 301 https://$host$request_uri;
}

O dost jednodušší, že? A stejným způsobem nastavíme i všechny naše ostatní virtuální servery a jsme hotovi.