Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Filip Jirsák

Stran: 1 ... 190 191 [192] 193 194 ... 375
2866
Software / Re:Spolehlivý souborový systém pro RPi
« kdy: 14. 11. 2018, 16:08:41 »
Nejméně náchylný na násilné odpojení bude FAT nebo FAT32, protože mají minimální množství metadat, takže je tam minimum toho, co by mohlo být nějak nekonzistentní nebo poškozené.

U ostatních souborových systémů by mělo pomoci zapnout žurnálování, protože to umožní souborový systém po výpadku obnovit do konzistentního stavu.

Ještě závisí na „chytrosti“ cílového média. Mám pocit, že SD už mohou obsahovat nějakou logiku, a pokud si souborový systém bude myslet, že něco už je zapsané ale nebude, ale zapsané bude něco následujícího, tak nepomůže ani žurnál, když bude rozbitý.

2867
Vývoj / Re:Proč se v Javě XML nahrazuje YML?
« kdy: 14. 11. 2018, 07:25:07 »
Typy myslím : možnosti rozšíření např. DTD, XSD
To nejsou rozšíření, to jsou nástroje, které můžete s XML používat. Jako kdybyste k naučení se YAML počítal, že se naučíte používat vim a grep.

Máš drastické problémy s představivostí a pamětí. Vzpomeň kolik hodin jsi věnoval k naučení úplně tomu základnímu použití XML ( tagy, parser - to pod hodinu nedostaneš) a kolik stovek, tisíc  jsi věnoval plnému pochopení XML.
Zatímco YAML example je pochopený za 1 minutu. To je rozhodující.
Nebo ty drastické problémy máte vy. Netuším, proč do základů pochopení XML motáte partser a do základů YAML ne. A stovky ani tisíce hodin jsem pochopení XML rozhodně nevěnoval – akorát jsem to pochopení elementů a atributů rozšířil o entity, komentáře, CDATA a XML instrukce, podíval se na možnosti DTD a zjistil, že to používat nechci a nepotřebuju, a tím to skončilo. YAML example pochopený za minutu nemám, ve skutečnosti si musím pokaždé znovu nastudovat, jak se v YAMLu píšou takové „komplikovanosti“ jako seznamy nebo víceřádkové hodnoty.

Ale srovnávám. To ty máš zjevně problém si přiznat, že když se něco učíš 1 minutu a něco jiného např. 10,60 minut, pak to co se učíš rychleji je zjevně jednodušší. Mimochodem, ty nástroje se musíš taky naučit a to bere taky čas. A pak zjistíš, že to třeba ani nepotřebuješ, jenom kvůli tomu že autor nástroje je tak stupidní že ani pořádně neumí napsat co to umí/neumí.
To by mne zajímalo, odkud máte tak přesné informace, co jsem se jak dlouho učil. Můžu se vám ale přiznat, že YAML dosud neumím, a už jsem z něj viděl dost na to, abych věděl, že se ho ani plánovaně učit nehodlám. Nemám totiž rád jazyky, které mají na každou věc deset cukrátek, kterými se něco dá ve specifických případech „zjednodušit“, protože pak mají zbytečně komplikovanou gramatiku a člověk musí neustále přemýšlet, o jaký specifický případ se jedná.

Nástroje jako XPath, XSLT nebo XQuery jsem se naučil používat a velmi to šetří můj čas. Ale nikdo vás nenutí je používat, klidně si hledejte pomocí hledání v textovém editoru, přepisujte si soubory ručně a ručně si vybírejte potřebná data. Přesně tak, jak byste to dělal s YAMLem, kde ty nástroje k dispozici nemáte, nebo s JSONem, kde existují spíš teoreticky.

2868
Vývoj / Re:Proč se v Javě XML nahrazuje YML?
« kdy: 13. 11. 2018, 21:14:26 »
...v komentáři nebo v dokumentaci...
přesně!
Takže pokaždé, když s tím něco chci dělat, například si to jen přečíst, musím si vedle otevřít dokumentaci a hledat v ní, co v tom konfiguráku vlastně vidím.

2869
Vývoj / Re:Proč se v Javě XML nahrazuje YML?
« kdy: 13. 11. 2018, 07:15:46 »
Za mě je nevýhodou XML jeho rozsáhlost, různé typy XML, specifikace schémat, atd.. stal se prostě moc složitým.
Jaké různé typy? K psaní schémat vás nic nenutí, je to jenom možnost.

Takže zcela rozumím, proč se u XML učit 100x  více( a tedy i mnohem déle) + pamatovat si to, se lidem zjevně nechce.
To bych to 100× více chtěl vidět. Pro psaní XML stačí umět napsat element a atribut. S YAML stejné složitosti dosáhnete, když se naučíte psát víceřádkové hodnoty – a pořád ještě zbývají seznamy, odsazení…

např. ta kniha od Herouta je dobrá, ale má cca 200+ stránek a plně nepokrývá vše co XML obnáší, zatím co YML (např. https://dzone.com/articles/using-yaml-java-application ) je mnohem, mnohem jednoduší a znakové sady taky podporuje(http://yaml.org/spec/current.html#id2513364).
Jenže to porovnáváte dvě úplně nesouměřitelné věci. Používat XML stejně, jako používáte YAML, není složitější, spíš naopak. A vedle toho pak máte pro XML spoustu nástrojů, které můžete použít, když se vám to hodí, ale používat je nemusíte.

2870
Vývoj / Re:Proč se v Javě XML nahrazuje YML?
« kdy: 12. 11. 2018, 22:57:58 »
Za roky praxe jsem jeste nevidel hezky/prehledny/citelny XML dokument, ktery by mel vice jak ~30 radku.
Řekl bych, že jste na jeden koukal zrovna při psaní toho komentáře. HTML5 se dá serializovat i jako XHTML. Dokument si přece nemusíte prohlížet jen ve zdrojové podobě – dokumenty z LibreOffice nebo MS Wordu si také asi neprohlížíte ve zdrojáku, stejně jako HTML.

XSLT - probuh proc?! To snad nikdo nemuze nazvat featurou, tuhle vec bych rad zapomnel.
XSLT je výborná věc, můžete deklarativně popsat transformaci jednoho formátu XML dokumentu do jiného, a nemusíte to pracně programovat v nějakém imperativním jazyce. Máte třeba výstup z relační databáze jako XML, a pomocí XSL transformací z toho nasekáte HTML5 webovou stránku, FO a to převedete na PDF, MS Excel a LibreOffice a pro chudé z toho vyrobíte CSV. Porovnejte si to s JSONem, kde se to pořád přesypává ručně z jednoho JSONu do jiného.

XPath - no dobre, to je uzitecne, ale kolikrat jsem to potreboval za poslednich ~5 let? 1x?
Já několikrát měsíčně.

rychle neco vyblejt a jit dal, ne resit den XMLko.
Kdyby se v té YAML konfiguraci třeba Spring Bootu řešilo to samé, co se dříve řešilo XML pro Spring (Core), nebudete ten YAML řešit den, ale měsíc. Což ale nebyla chyba XML, ale jeho nevhodného použití (což není výtka, tehdy to moc lépe nešlo). Všimněte si, že abyste mohl tu konfiguraci třeba Spring Bootu dneska pohodlně editovat, museli pro to autoři IDE naprogramovat podporu, která rozumí tomu formátu souboru, rozumí Springu a umí to propojit. Přitom editory XML umí tohle s pomocí XML schémat dávno. Takže na straně editoru by se nemuselo řešit nic, a na straně Springu jenom umět z toho datového modelu konfigurace v Javě vygenerovat XSD. A to už můžou používat ty editory, můžou to používat validátory, může se to použít při generování dokumentace. Ale proč používat nástroje, které tu jsou už patnáct let, když to může celé napsat znova a pro tenhle jeden konkrétní případ, že…

2871
Vývoj / Re:XML vs YML - svět se zbláznil?
« kdy: 12. 11. 2018, 22:43:13 »
Uživatelské entity používám jako makra.
Podle mne to za ty problémy nestojí. Místo maker se dá použít XSLT.

Jak bys chtěl do XML entit injektovat chyby? To by neprošlo validací. Uživatelské entity se definují zpravidla přímo v dokumentu, ale je mnoho užitečných externích DTD, které obsahují entity vhodné pro určité obory činnosti.
„Neprošlo validací“ znamená, že už to muselo projít parserem. Právě ty externí DTD jsou obrovské bezpečností riziko.

Takže nelze zrušit ani DTD.
Já myslím, že lze. V pohodě bych se obešel bez všeho, co DTD umožňuje, nikdy jsem to nepotřeboval a neviděl použité.

Vlastně si ho můžeš zrušit tak, že ho nebudeš používat. XML dokument může být samostatnou plnohodnotnou entitou, stejně jako YAML/JSON/INI.
Může a většinou je. Ale nedá se na to spolehnout. Když budu psát XML parser, musím počítat s DTD. Když budu používat parser, musím řešit, jak se zachovat k případným externím DTD. Když budu psát webovou službu (ať na straně serveru nebo klienta), musím řešit, co když v tom XML někdo použije DTD, nebo dokonce externí DTD. Ano, když tu webovou službu definuju, můžu do podmínek navíc někde textově napsat, že se nesmí používat DTD. Ale bylo by fajn, kdyby si tohle nemusel definovat každý zvlášť a každý trochu jinak, ale kdyby stačilo napsat, že se používá XML 2.0.

2872
Vývoj / Re:XML vs YML - svět se zbláznil?
« kdy: 12. 11. 2018, 20:45:38 »
Tady nesouhlasím.
Vždyť jsem to psal, že se stejně lidi neshodnou, co z těch málo používaných věcí z XML vyhodit :-)

DTD je sice přežitkem, ale proč se zbavovat uživatelských entit? XML instrukce a CDATA většina uživatelů asi nezná a je ochotna je postrádat ale když je nepoužijí, tak jim ani nepřekáží.
Na XML instrukce i CDATA občas narazím. Uživatelské entity jsem v praxi ještě použité neviděl. Zbavoval bych se jich proto, že velmi komplikují XML parser a otvírají cestu pro různé XML injection chyby. Navíc tedy pokud vím, jsou definované v DTD, takže když se chci zbavit DTD, musím se zbavit i jich – pokud je nechci nějak komplikovaně zavádět jinak. Navíc zrušením DTD a uživatelských entit by se docílilo toho, že XML dokument by byl vždy samostatná plnohodnotná entita, nezávisel by na ničem dalším. (Trochu by to kazily výchozí hodnoty v XML schématu, ale to je věc o úroveň výš, XML dokument jde rozparsovat i bez nich.)

2873
Sítě / Re:Nastavení routování
« kdy: 12. 11. 2018, 19:03:20 »
On se ten pfSense obcas chova divne, ruzne apliku/neaplikuje pravidla. Kdyz jsou pak v ceste 3, blbe se to ladi. Uz odladit to cele divadlo s VPN mezi sebou byl celkem porod.
Právě proto bych na vašem místě, pokud můžete, použil to řešení přes proxy. Protože když použijete NAT, pohybujete se na té samé vrstvě, jako ta VPN a routování, a vzájemně se to bude ovlivňovat – každá změna v tom NATu může znamenat, že budete muset někde měnit i routování nebo VPN, a naopak každá změna v routování nebo VPN může vyvolat nutnost změnit ten NAT. Když to uděláte tím proxy serverem, pohybujete se ve vrstvě nad tou síťovou vrstvou, a můžete se spolehnout na to, že když vám funguje ta síťová vrstva, a změníte ji do jiného funkčního stavu, na té aplikační vrstvě (proxy) nemusíte nic měnit. A naopak laborováním s proxy si nemůžete rozbít tu síťovou vrstvu.

2874
Vývoj / Re:XML vs YML - svět se zbláznil?
« kdy: 12. 11. 2018, 18:55:50 »
YAML - je vizuální markdown jazyk - a už před nástupem JSONu jsem jej vidět používat pro konfigurace, pro poznámky. V JSONu a XMLku je ta vizuální stránka potlačená.

XMLko je fajn, ale některé z mých nepříjemných zážitků jsou spojené s konfigurací Java aplikací v XML. Případně číst XML logy taky nemusím.

Srovnejte si složitost SOAPu a RESTu - tam mám pocit, že designéři se trochu utrhli s řetězu. Asi by mohl docela dobře existovat REST nad XML, ale k výměně technologie obvykle musí být víc důvodů než jeden - byť některé důvody jsou marketingové nebo podmíněné nástupem nové generace programátorů, která starší technologii nezvládla nebo odmítla.

V programování hraje velkou roli lidský faktor a dochází k cyklické obměně technologii - jednak se mění hw, mění se požadavky zákazníků, a většina technologii má tendence bobtnat - což není problém, když danou technologii zastihnete na začátku cyklu jako junior nebo mladý senior - změny stíháte absorbovat. Pokud ale k technologii přistoupíte v pozdějším cyklu, tak komukoliv bez let zkušeností letitá technologie musí přijít jako monstrum - do rozjetého vlaku se dost špatně nastupuje - a začíná se znova s něčím jednoduchým, přehledným, rychlým elegantním, z čehož se za 10-20 let stane monstrum.
Na konfigurační soubory, které se vejdou na jednu obrazovku a mají maximálně tři úrovně odsazení, je YAML krásný formát. Jenže každý takovýhle krásný jednoduchý konfigurační soubor časem roste a roste. A to je problém všech těchhle formátů, které mají být jednodušší než XML. Všechny fungují na jednoduchých příkladech, ale se stoupající komplexitou toho, co mají popisovat, křivka použitelnosti strmě klesá. Podívejte se třeba na pradědečka všech těchhle formátů „jednodušších než HTML/XML“ – wiki, konkrétně MediaWiki syntax. Když se podíváte na zdroják libovolné stránky na Wikipedii, je tam plno nesrozumitelných šablon, parametry se píšou pokaždé jinak a bez nápovědy nenapíšete ani externí odkaz. O co přehlednější a srozumitelnější by ten zdroják byl, kdyby se nepoužíval „jednoduchý“ wiki jazyk, ale „komplikované“ XML.

Konfigurace Java aplikací přes XML bývá problém, když je pro konfiguraci použitý prakticky vlastní jazyk serializovaný do XML. Jde to udělat, ale to neznamená, že je to dobrý nápad – a není to chyba XML. A zrovna ty logy – ony i v tom textovém souboru mají nějakou strukturu, která se zápisem do čistého textu ztratí, a pak ji zase další nástroje pro analýzu logů pracně obnovují. Nepřipadá mi zase tak špatný nápad dělat to opačně – logovat strukturovaná data, a pak je případně pro zobrazení člověku hezky zformátovat. Ostatně logování v cloudu už přesně k tomuhle vede, protože logy z desítek strojů už nejde zpracovávat tak, že si budete pročítat textové soubory.

U SOAPu je ten problém, že se snažil vyřešit všechny problémy světa a vyhovět všem. REST nemá formát specifikovaný, může se použít i XML a často se používá, a oproti použití JSONu to má spoustu výhod. Použít pro REST JSON má vlastně jedinou výhodu – snadno se s tím pracuje v prohlížečích, protože prohlížeče nemají rozumné nástroje pro práci s XML (přestože pracují s DOMem, který je přirozenou reprezentací XML).

S tou obměnou technologií v cyklech je to pravda. Mně ale na těch opakovaných snahách vymyslet „jednoduché XML“ vadí to, že se nepoučí z předchozích případů. Takže pořád dokola vznikají WikiWiki, Markdown, JSON, YAML a vždy se na to vrhne spousta lidí s pocitem, že teď už to konečně bude jednoduché – a nedochází jim, že ta složitost není v jazyce, ale v těch dokumentech, a že pro zápis složitějších dokumentů prostě je potřeba určitá robustnost, která u jednoduchých dokumentů skutečně bude trochu překážet. Akorát že se vyplatí naučit se ten nástroj používat, i když je na jednoduché dokumenty trochu neohrabaný, protože se to mnohonásobně vrátí v budoucnosti.

XML by pomohla jedna věc – vydat novou verzi, ve které bychom se vykašlali na DTD a uživatelské entity, a ponechalo by se tam to, co se dnes z XML reálně používá. Problém je, že mnozí by chtěli nejspíš vyházet i XML instrukce a/nebo CDATA, na čemž se nejspíš nikdo neshodne, tak se do toho nikdo raději ani nepouští.

2875
Vývoj / Re:XML vs YML - svět se zbláznil?
« kdy: 12. 11. 2018, 16:23:06 »
Berte to tak, že někteří lidé prostě k smrti nenávidí špičaté závorky. Nic jiného za tím není, hledat v tom nějakou logiku je pošetilé.

Už spoustu let tu máme XML, které má jmenné prostory, schémata (XSD), transformace (XSLT), ukazatele (XPath, XPointer), dotazovací jazyk (XQuery). Pak ale přišel někdo, že je XML moc ukecané a bůhvíco ještě, a vymyslel JSON, který se prý mnohem lépe čte a píše. No a pro JSON se pomalu vymýšlí to samé, co máme pro XML – schémata (JSON Schema), ukazatele (JSON Pointer). A teď mám i nejnovější objev, dotazovací jazyk – GraphQL. No a do toho přišel někdo s tím, že JSON je moc ukecaný a bůhvíco ještě (kde jsem to jen viděl), a vymyslel YAML, který se prý mnohem lépe čte a píše.

Takže já bych to nijak neřešil. Ti, co potřebují každé tři roky nový formát, je budou vynalézat stále. No a těm ostatním dojde, že problém není ve formátu. Že jakékoli složitější dokumenty jsou prostě bez podpory na straně editorů (zvýrazňování, formátování, doplňování) nepřehledné z principu, a žádným formátem se to nedá ošidit. No a pro ty tu  pořád bude stabilní a prověřené XML, které má dávno vyřešené všechno, co se teď ve světě JSON/YAML s velkou slávou objevuje.

Ale když už ve světě JSONu vynalezli XSD, XPath a teď i XQuery, kdy myslíte, že vynaleznou XSLT?

2876
Sítě / Re:Nastavení routování
« kdy: 12. 11. 2018, 15:30:34 »
Ono to používat umím, ale tak na Mikrotiku. Nastavení podle stejné logiky na tom pfSense prostě nedělá to samé.
Routerů je samozřejmě v cestě několik, každý saozřejmě pošle provovoz mířící mimo síť rovnou do internetu.

Koncentrátor je pfSense.
pfSense nepoužívám, ale zkuste napsat, jak jste tam ten SNAT nastavil, buď to dáme dohromady, nebo odpoví někdo, kdo pfSense zná. Ale v podstatě by mělo stačit buď tam zapnout maškarádu, a nebo nastavit SNAT na IP adresu vnitřního rozhraní toho VPS (toho rozhraní, kterým se pak paket odesílá na cílový server).

Jinak osobně bych – když tam máte plnohodnotný VPS a FreeBSD – v tomhle případě volil ten nginx nebo ha-proxy, pokud ta spojení na servery mají být nějaké normální protokoly nad TCP. Dostanete tím nezávislost na topologii vašich sítí a budete moci lépe pracovat s příchozím provozem.

2877
Sítě / Re:Nastavení routování
« kdy: 12. 11. 2018, 13:43:03 »
Take muzete smerovat veskery provoz z lokalit pres VPN a az pak do internetu.
Tím se z toho VPS stává single point of failure pro připojení těch lokalit do internetu, navíc může být úzkým hrdlem z hlediska propustnosti sítě.

Pripadne, pro vas asi nejjednodussi reseni. Nejaky "TCP Proxy" na centralnim bodu, napriklad :
Kód: [Vybrat]
 socat TCP-LISTEN:80,fork TCP:202.54.1.5:80

Pokud se jedna o nejakou webovou aplikaci, muzete pouzit i nginx/apache jako reverzni proxy a jako bonus tam muzete pridat https od Let's Encrypt.
Ano, pokud ten centrální bod je stejně nějaký počítač (vypadá to, že ano), nainstaloval bych tam nginx a HTTP/HTTPS hnal přes něj jako přes reverzní proxy (IP adresa klienta se pak předává v hlavičkách), případně jiné protokoly pak přes stream proxy. nginx podporuje PROXY protokol, kterým je v takovém případě také možné předat informace o zdrojové IP adrese.

Navíc tím odpadnou všechny problémy s NATOváním a routováním, můžete spravovat všechny HTTPS certifikáty na jednom místě, můžete směrovat požadavky do různých sítí na základě cesty (např. example.com/pobocka1 do jedné sítě a example.com/pobocka2 do druhé), a pořád takhle můžete směrovat i obecná TCP spojení.

2878
Sítě / Re:Nastavení routování
« kdy: 12. 11. 2018, 12:29:13 »
Doporučuji zaměřit pozornost na slovo MUSÍTE kterým jste se zbytku světa snažil sdělit že žádné jiné varianty neexistují
Není vám to hloupé, vysvětlovat mi, co jsem myslel textem, který jsem napsal? „Musíte“ neznamená „žádné jiné varianty neexistují“. Když se někde v baráku dole na recepci zeptáte, kde máte zaplatit poplatek za psa, odpoví vám: „To musíte výtahem do třetího patra, pak se dáte doleva a jsou to na konci chodby dveře číslo 327.“ Tak se s nimi hlavně nezapomeňte pohádat, že nemusíte, že můžete jít pěšky po schodech, můžete jet výtahem do 5. patra a sjet dvě patra po zábradlí a nebo že si můžete nechat přistavit požární žebřík a vlézt tam oknem.

Správné místo pro značkování paketů je ten konec VPN který je v lokální síti
Potřebujete si označit, na kterém zařízení proběhl ten DNAT a pak zařídit, aby se odpovědní paket dostal opět na toto zařízení, které má tabulku spojení, najde v ní údaje pro odpovědní paket a upraví ten odpovědní paket reverzní operací, než jakou udělal na příchozím paketu DNATem (tedy změní zdrojovou IP adresu a případně zdrojový port paketu – ale záměrně to nechci nazývat SNATem).

Ono se totiž klidně může stát, že tazatel síť za dva roky rozšíří a bude mít dvě zařízení s veřejnou IP adresou, a servery bude chtít mít dostupné přes obě dvě ty IP adresy. A v tom okamžiku to vaše řešení „přišlo to z VPN, tudíž to muselo přijít z té jediné veřejné IP adresy“ přestane fungovat.

Ostatně ona je hloupost značkovat vše, co přišlo přes VPN, i když zatím má jen jednu veřejnou IP adresu – protože byste takhle značkoval veškerý provoz, který přišel z VPN, tedy i ten z těch zbývajících dvou lokálních sítí. A ten nepotřebujete hnát přes ten VPS s veřejnou IP adresou, když může jít přímo přes VPN.

2879
Sítě / Re:Nastavení routování
« kdy: 12. 11. 2018, 10:55:10 »
V různých kombinacích je v cestě pfSense a Mikrotik.

S SNATem jsem měl na pfSense problémy - nastavil jsem, ale prostě nefungoval....
Co je za systém na tom centrálním bodu, který má veřejnou IP adresu? Ten DNAT děláte tam?

2880
Sítě / Re:Nastavení routování
« kdy: 12. 11. 2018, 10:53:03 »
řešení které se pan Jirsák naprosto chybně prohlašuje za jediné možné
Je to trollení nutné? Navíc když si každý může jednoduše odskrolovat o půl obrazovky výše, přečíst si mou odpověď kde uvidí, že jsem nabídl řešení, ale nikde jsem netvrdil, že je jediné možné – takže si prostě vymýšlíte.

je třeba použít něco šíkovnějšího, třeba "iptables -j MARK --set-mark 1234" na příchozí pakety a "ip rule add fwmark 1234 table 1234" pro routování odchozích paketů zpátky přes VPN (routovací tabulka 1234 musí samozřejmě být správně nastavená).
Tady je ovšem potřeba doplnit, že to řešení je ve skutečnosti mnohem komplikovanější, než se z téhle jedné věty zdá – takhle jednoduché řešení by fungovalo jen v některých speciálních případech topologie těch sítí.

Místo, kde je nejlepší označkovat pakety, že přišly z VPN, je ten VPN koncentrátor, kde se předpokládám dělá i ten DNAT. Označovat je kdekoli později a vycházet přitom z předpokladu „když to má veřejnou zdrojovou IP adresu a míří to na cílový server, určitě to muselo přijít přes VPN“ se může vymstít, až se konfigurace sítě změní. Za druhé, a to je ještě podstatnější, řešit odchozí provoz pouze vhodnou routovací tabulkou bude fungovat jedině v případě, že ty servery nebo jejich výchozí brána mají přímý link na ten VPN koncentrátor (a ta druhá routovací tabulka musí být tam, odkud ten přímý link vede). Pokud by topologie byla složitější a mezi serverem nejbližší bránou a VPN koncentrátorem byly ještě jiné routery, které mají také přístup do internetu, musela by se ta speciální routovací pravidla nastavit i na nich, aby to fungovalo.

Proto jsem navrhl to řešení s SNATem, protože je to nejjednodušší, vše se vyřeší na jednom místě a nezáleží na topologii zbytku sítě. Pokud někdo umí používat vícenásobné routovací tabulky a značkování paketů, nebude se asi na takhle jednoduchou věc ptát někde na fóru.

Stran: 1 ... 190 191 [192] 193 194 ... 375