Vylepšení funkcionality HTTP/HTTPS proxy
-
- Administrátor
- Příspěvky: 1373
- Registrován: úte 12. říj 2010 9:16:11
- Kontaktovat uživatele:
Vylepšení funkcionality HTTP/HTTPS proxy
Dobrý den,
4smart.cz vylepšil imlementaci funkcionality reverzní HTTP proxy a s tím tedy přichází několik nových výhod a možností:
1) Nyní máme dva Reverzní HTTP Proxy servery - proxy1.4smart.cz a proxy2.4smart.cz.
2) Podporované protokoly - Proxy servery 4smart.cz podporují protokoly HTTP, HTTPS (díky SNI proxy) a SMTP pouze pro příjem pošty. Pokud tedy chcete zpřístupnit svůj web, a to i jeho zabezpečený obsah (https), není použití proxy serverů 4smart.cz omezením ani problémem. Vše funguje transparentně i pro https.
3) Rychlost - Změna nastavení proxy serveru, s výjimkou poštovního subsystému pro Vaši doménu, se projeví do minuty
4) Spárovanost s přidělovanými subdoménami 4smart.eu - Na 4smart.cz automaticky dostanete vlastní doménu ke každému VPS, jehož hostname není „localhost“. Pokud má Váš VPS navíc neveřejnou IPv4 adresu, dostane automaticky doménu www.[hostname_bez_tld].4smart.eu. Tato doména je automaticky spárována přes naše doménové servery s reverzními proxy servery a lze ji ihned zadat do prohlížeče. Vše je automatizované, rychlé, spolehlivé a pro uživatele bezpracné.
5) Odolnost proti výpadku HW uzlu - Pro automaticky přidělované subdomény 4smart.eu je celá funkčnost postavená tak, že je odolná vůči selhání některého z HW uzlů, kde právě běží jeden nebo druhý proxy server. Naše doménové servery ns1.4smart.cz a ns2.4smart.cz se totiž nachází na stejných HW uzlech, jako proxy1.4smart.cz a proxy2.4smart.cz. Pokud neběží doménový server ns2.4smart.cz, neodkazuje nic na proxy2.4smart.eu a podobně pokud neběží ns1.4smart.cz, neodkazuje nic na proxy1.4smart.cz. Pro domény jiné, než 4smart.eu. může uživatel nastavit u svého registrátora CNAME na takto přidělenou subdoménu 4smart.eu. Tím zajistí, že i pro jiné domény bude zachována vysoká dostupnost.
J.M.
4smart.cz vylepšil imlementaci funkcionality reverzní HTTP proxy a s tím tedy přichází několik nových výhod a možností:
1) Nyní máme dva Reverzní HTTP Proxy servery - proxy1.4smart.cz a proxy2.4smart.cz.
2) Podporované protokoly - Proxy servery 4smart.cz podporují protokoly HTTP, HTTPS (díky SNI proxy) a SMTP pouze pro příjem pošty. Pokud tedy chcete zpřístupnit svůj web, a to i jeho zabezpečený obsah (https), není použití proxy serverů 4smart.cz omezením ani problémem. Vše funguje transparentně i pro https.
3) Rychlost - Změna nastavení proxy serveru, s výjimkou poštovního subsystému pro Vaši doménu, se projeví do minuty
4) Spárovanost s přidělovanými subdoménami 4smart.eu - Na 4smart.cz automaticky dostanete vlastní doménu ke každému VPS, jehož hostname není „localhost“. Pokud má Váš VPS navíc neveřejnou IPv4 adresu, dostane automaticky doménu www.[hostname_bez_tld].4smart.eu. Tato doména je automaticky spárována přes naše doménové servery s reverzními proxy servery a lze ji ihned zadat do prohlížeče. Vše je automatizované, rychlé, spolehlivé a pro uživatele bezpracné.
5) Odolnost proti výpadku HW uzlu - Pro automaticky přidělované subdomény 4smart.eu je celá funkčnost postavená tak, že je odolná vůči selhání některého z HW uzlů, kde právě běží jeden nebo druhý proxy server. Naše doménové servery ns1.4smart.cz a ns2.4smart.cz se totiž nachází na stejných HW uzlech, jako proxy1.4smart.cz a proxy2.4smart.cz. Pokud neběží doménový server ns2.4smart.cz, neodkazuje nic na proxy2.4smart.eu a podobně pokud neběží ns1.4smart.cz, neodkazuje nic na proxy1.4smart.cz. Pro domény jiné, než 4smart.eu. může uživatel nastavit u svého registrátora CNAME na takto přidělenou subdoménu 4smart.eu. Tím zajistí, že i pro jiné domény bude zachována vysoká dostupnost.
J.M.
Re: Vylepšení funkcionality HTTP/HTTPS proxy
Díky, jen tak dál
Jen nemůžu úplně potvrdit bod 4 - "Tato doména je automaticky spárována ... a lze ji ihned zadat do prohlížeče. Vše je automatizované, rychlé, spolehlivé a pro uživatele bezpracné.". Alespoň pro už existující servery je třeba http://www.domena.4smart.eu zadat ručně do konfigurace proxy. Ale ručně = vědomě je obvykle lepší, než automaticky a uživatel pak netuší, jaké všechny přístupy má "náhodou" otevřené do internetu.
S přibývajícíma službama na proxy by se hodila taky možnost určit, která služba má na proxy fungovat a která ne - např. nastavením http začnete posílat taky https, i když to třeba uživatel nechce. (a skončí pak na podivné hlášce ala "Bezpečná komunikace s partnerem není možná: Nenalezen žádný společný šifrovací algoritmus."). Stejně tak budete na stejnou doménu akceptovat poštu, i když ji nebude kam poslat (a nějaký spammer to může zkoušet i bez MX záznamu).
Oproti http má https proxy taky jednu nevýhodu - z principu neumí nastavit hlavičku x-forwarded-for, tj. všechny požadavky budou v http logu jako z IP adresy proxy. To může někomu vadit, ale nic moc s tím udělat nejde (kromě dekódování SSL už na proxy)
Jen nemůžu úplně potvrdit bod 4 - "Tato doména je automaticky spárována ... a lze ji ihned zadat do prohlížeče. Vše je automatizované, rychlé, spolehlivé a pro uživatele bezpracné.". Alespoň pro už existující servery je třeba http://www.domena.4smart.eu zadat ručně do konfigurace proxy. Ale ručně = vědomě je obvykle lepší, než automaticky a uživatel pak netuší, jaké všechny přístupy má "náhodou" otevřené do internetu.
S přibývajícíma službama na proxy by se hodila taky možnost určit, která služba má na proxy fungovat a která ne - např. nastavením http začnete posílat taky https, i když to třeba uživatel nechce. (a skončí pak na podivné hlášce ala "Bezpečná komunikace s partnerem není možná: Nenalezen žádný společný šifrovací algoritmus."). Stejně tak budete na stejnou doménu akceptovat poštu, i když ji nebude kam poslat (a nějaký spammer to může zkoušet i bez MX záznamu).
Oproti http má https proxy taky jednu nevýhodu - z principu neumí nastavit hlavičku x-forwarded-for, tj. všechny požadavky budou v http logu jako z IP adresy proxy. To může někomu vadit, ale nic moc s tím udělat nejde (kromě dekódování SSL už na proxy)
Re: Vylepšení funkcionality HTTP/HTTPS proxy
Dobrý den,
HTTPS port na proxy už druhý den neodpovídá, čím to?
$ telnet proxy1.4smart.cz 443
Trying 77.93.202.118...
telnet: Unable to connect to remote host: Connection refused
$ telnet proxy2.4smart.cz 443
Trying 77.93.202.15...
telnet: Unable to connect to remote host: Connection refused
HTTPS port na proxy už druhý den neodpovídá, čím to?
$ telnet proxy1.4smart.cz 443
Trying 77.93.202.118...
telnet: Unable to connect to remote host: Connection refused
$ telnet proxy2.4smart.cz 443
Trying 77.93.202.15...
telnet: Unable to connect to remote host: Connection refused
-
- Administrátor
- Příspěvky: 1373
- Registrován: úte 12. říj 2010 9:16:11
- Kontaktovat uživatele:
Re: Vylepšení funkcionality HTTP/HTTPS proxy
Dobrý den,
příčinou problému byl pád sniproxy démona. Bohužel se mi nepodařilo zjistit, proč k tomu došlo, logy neobsahují nic, co by tuto událost vysvětlilo.
Sniproxy jsem neprodleně po Vašem oznámení restartoval.
Před chvílí jsem implementoval kontrolní script, který v prápadě dalšího pádu sniproxy sám restartuje a událost zaloguje.
Budeme to sledovat.
J.M.
příčinou problému byl pád sniproxy démona. Bohužel se mi nepodařilo zjistit, proč k tomu došlo, logy neobsahují nic, co by tuto událost vysvětlilo.
Sniproxy jsem neprodleně po Vašem oznámení restartoval.
Před chvílí jsem implementoval kontrolní script, který v prápadě dalšího pádu sniproxy sám restartuje a událost zaloguje.
Budeme to sledovat.
J.M.
Re: Vylepšení funkcionality HTTP/HTTPS proxy
ok, díky. Aktuálně to k ničemu nepotřebuju a chtěl jsem to jen vyzkoušet.Trochu bych ale čekal, že každá veřejně-komerčně nabídnutá služba bude mít taky nastavený nějaký dohled, aby vám výpadky nemuseli hlásit uživatelé
-
- Administrátor
- Příspěvky: 1373
- Registrován: úte 12. říj 2010 9:16:11
- Kontaktovat uživatele:
Re: Vylepšení funkcionality HTTP/HTTPS proxy
Záleží na použitém SW. Některý SW dohled nepotřebuje, jiný ano. Ve světě Linuxového SW je spolehlivost obvykle celkem vysoká.alfi píše:ok, díky. Aktuálně to k ničemu nepotřebuju a chtěl jsem to jen vyzkoušet.Trochu bych ale čekal, že každá veřejně-komerčně nabídnutá služba bude mít taky nastavený nějaký dohled, aby vám výpadky nemuseli hlásit uživatelé
Například Postfix si svoje dceřiné procesy umí hlídat a podle potřeby je i restartovat, atd.
Sniproxy to bohužel neumí, zřejmě zde není proces, který by dohlížel na ostatní. Je potřeba si uvědomit, že nově spuštěná služba může vykazovat vždy určité problémy, obzvláště například, pokud jde o SW, který napsal někdo jiný a my jej jen nasadili.
V takovém případě se potom přijímají nějaká následná opatření, například vlastní script pro kontrolu služby. Lépe je, když se taková chyba projeví hned, než v době, kdy je dostupnost této služby kritická.
J.M.
Re: Vylepšení funkcionality HTTP/HTTPS proxy
[quote="admin"]Záleží na použitém SW. Některý SW dohled nepotřebuje, jiný ano. Ve světě Linuxového SW je spolehlivost obvykle celkem vysoká.
[/quote]
Já bych trochu čekal, že každá komerčně nabízená aplikace má nějaký aktivní externí dohled - protože stát se může cokoliv a neměl by na to přijít až externí zákazník. Ale to je samozřejmě na vašem rozhodnutí
Každopádně dnes opět SSL nejede na proxy2. A protože DNS teď taky vrací v cca 90% případů IP na proxy2, je SSL z pohledu uživatele úplně nefunkční
[/quote]
Já bych trochu čekal, že každá komerčně nabízená aplikace má nějaký aktivní externí dohled - protože stát se může cokoliv a neměl by na to přijít až externí zákazník. Ale to je samozřejmě na vašem rozhodnutí
Každopádně dnes opět SSL nejede na proxy2. A protože DNS teď taky vrací v cca 90% případů IP na proxy2, je SSL z pohledu uživatele úplně nefunkční
-
- Administrátor
- Příspěvky: 1373
- Registrován: úte 12. říj 2010 9:16:11
- Kontaktovat uživatele:
Re: Vylepšení funkcionality HTTP/HTTPS proxy
Dobrý den,
dohled nad sniproxy jsem po předchozím oznámení samozřejmě implementoval. Je založený na bash scriptu, který se dotazuje přes příkaz service na stav služby.
Bohužel v tomto případě selhal i systemd, který vracel True, ačkoliv sniproxy neběžela. Takže jsem nyní dohled doplnil ještě o další záložní metodu, která není založena na důvěře v systemd.
Jistě uznáte, že ne vše lze uhlídat. Chyby jsou v každém softwaru, především tam, kde je nikdo nečeká.
J.M.
dohled nad sniproxy jsem po předchozím oznámení samozřejmě implementoval. Je založený na bash scriptu, který se dotazuje přes příkaz service na stav služby.
Bohužel v tomto případě selhal i systemd, který vracel True, ačkoliv sniproxy neběžela. Takže jsem nyní dohled doplnil ještě o další záložní metodu, která není založena na důvěře v systemd.
Jistě uznáte, že ne vše lze uhlídat. Chyby jsou v každém softwaru, především tam, kde je nikdo nečeká.
J.M.
- xsouku04
- Administrátor
- Příspěvky: 8167
- Registrován: pát 15. říj 2010 11:11:44
- Bydliště: Brno
- Kontaktovat uživatele:
Re: Vylepšení funkcionality HTTP/HTTPS proxy
No ale nejdůležitější je podle mne najít příčinu problému a zabránit tomu, aby se daný problém opakoval.
Dohled je berlička snad jen pro případ, že samotnou příčinu problému nedovedeme odstranit, nebo též pro nové těžko dopředu odhadnutelné možné příčiny.
A nebo též pro hlídání hardware a kde možnost selhání nikdy nelze úplně odstranit.
Proč to resolvovalo v 90% případech na proxy2?
V čem přesně systemd selhal? Myslel jsem, že systemd je stále nestabilní, tedy alespoň mám tu zkušenost.
A také jsem měl za to, že v debianu, který je nyní stabilní (tento týden), systemd ještě defaultně není.
Dohled je berlička snad jen pro případ, že samotnou příčinu problému nedovedeme odstranit, nebo též pro nové těžko dopředu odhadnutelné možné příčiny.
A nebo též pro hlídání hardware a kde možnost selhání nikdy nelze úplně odstranit.
Proč to resolvovalo v 90% případech na proxy2?
V čem přesně systemd selhal? Myslel jsem, že systemd je stále nestabilní, tedy alespoň mám tu zkušenost.
A také jsem měl za to, že v debianu, který je nyní stabilní (tento týden), systemd ještě defaultně není.
-
- Příspěvky: 486
- Registrován: čtv 10. říj 2013 10:20:15
Re: Vylepšení funkcionality HTTP/HTTPS proxy
Tak jsem si to dneska konečně všechno správně nastavil, tak běda jestli to nepojede
Jen taková připomínka, co se týká té redundance - pro kořenovou doménu žádné řešení asi neexistuje, že? Vhledem k tomu, že @ záznam nemůže být CNAME, tak si stejně holt musím vybrat jednu proxy natvrdo a tu tam dát jako A záznam. Nebo na to nějaké řešení je?
Jen taková připomínka, co se týká té redundance - pro kořenovou doménu žádné řešení asi neexistuje, že? Vhledem k tomu, že @ záznam nemůže být CNAME, tak si stejně holt musím vybrat jednu proxy natvrdo a tu tam dát jako A záznam. Nebo na to nějaké řešení je?