Názor k článku Hardening webového serveru Apache: šifrování a certifikáty od Filip Jirsák - Proxy - to ale predpoklada ze obe strany...

Proxy - to ale predpoklada ze obe strany ktore proxy obsluhuje maju implementovane SOCKS.
Nikoli. Předpokládá to, že klient umí nějakým způsobem komunikovat s proxy serverem. Vy jste psal o aktualizacích systému, ty se dnes obvykle stahují přes HTTPS, dříve případně přes FTP. Snad všichni HTTP i FTP klienti umějí komunikovat přes HTTP proxy.

Naproti tomu NAT funguje na transportnej vrstve.
Což nic neznamená. Některé protokoly například přenášejí v aplikačních datech IP adresu. V případě NATu se to musí nějak obcházet – použít variantu protokolu, která to nedělá, na NATu měnit až na úrovni aplikačního protokolu i tu přenášenou IP adresu apod. Pro vaši informaci, tu IP adresu přenáší i protokol FTP ve svém původně nejpoužívanějším aktivním módu. A protokol FTP se hojně používal mimo jiné právě pro stahování distribučních balíků. Samozřejmě, že stejný problém budete mít i s proxy serverem, jenom poukazuju na to, že NAT není bezproblémové řešení.

Viacmenej ak budete potrebovat pouzit aplikaciu alebo zariadenie ktore socks nepodporuju tak sa natu nevyhnete.
Vzhledem k tomu, že neznáte fakta, neměl byste se pouštět do unáhlených závěrů.

Je nejaka vyhoda proxy oproti natu?
Například ta, že na proxy serveru můžete mnohem lépe řídit provoz. Přístup přes proxy server může být autentizovaný, můžete na něm povolit přístup jen k určitému doménovému jménu. Třeba pro ty servery povolíte na proxy serveru jenom přístup k serverům s distribučními balíčky a nikam jinam. To s NATem neuděláte – NAT nevidí DNS názvy, jen IP adresy.

Alebo mi nieco uslo a vo vlakne sa cely cas pisalo len o webe.
Ono se celou dobu píše jenom o webu nejenom v tomto vlákně, ale v celé diskusi. Řekl bych, že to bude mít něco společného se slovy „webový server“, která jsou v nadpisu článku.

Asi si ho precitam cele este raz, aby som sa uistil ci sa nemylim.
Ano, to vám doporučuju. Ve zkratce – původní dotaz na začátku vlákna byl: „Mám server v intranetu, který nemá veřejné doménové jméno. Je možné pro něj nějak vystavit důvěryhodný certifikát?“ Mnou navržené řešení s reverzními DNS záznamy nijak nemanipuluje, tj. pokud měl ten server původně nastavený reverzní DNS záznam, bude úplně stejně fungovat i nadále. Jediná věc je ke zvážení – pro server nemusíte zachovávat původní intranetový název, můžete server na veřejný název přejmenovat (místo vytvoření přezdívky). V takovém případě je potřeba změnit i ten název, na který ukazuje reverzní DNS záznam. Záznam ale pořád zůstane v intranetové reverzní zóně.

Ano, povodne boli privatne rozsahy urcene pre privatne siete, ale ako si sa ukazalo ze aj tieto casto potrebuju pristup do globalnej siete.
Tak příště neargumentujte RFC, kde se píše to, co tvrdím já.

To iste by sa dalo tvrdit o proxy
Tvrdit by se to dalo, třeba vy byste to tvrdit mohl, ale není to pravda. Proxy servery se používaly a používají i tam, kde jsou jen veřejné IP adresy. Dají se použít např. pro řízení přístupu. Nebo můžete pomocí proxy serveru bezpečně zpřístupnit pomocí aktuálních verzí protokolu HTTPS nějaké bláznivé zařízení, které umí jen HTTP nebo HTTPS se SSLv3. A tak dále.

akurat ma nevyhodu ze nefunguje s hociakou aplikaciou
Vzhledem k tomu, jak se postupně víc a víc blížíme k Internet-over-HTTPS (mimo jiné a kvůli NATům), těch aplikací nepodporujících proxy servery je čím dál méně.

Ja pouzijem zavedenejsie prirovnanie: Zbytocne strielate kanonom na vrabce.
Myslíte, že nedostatek IPv4 adres je vrabec a NAT je kanón? Bylo by fajn, kdyby to tak bylo, a kdyby zavedení IPv6 bylo mnohem jednodušší řešení, než používat NAT. Bohužel si to ale spousta správců nemyslí.