reklama

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 [2] 3 4 ... 254
16
Pokud ano, tak se akorát divím, že Vám ještě p. Jirsák nenapsal jeho nejoblíbenější argument, totiž přejít na IPv6. Protože zrovna v tomhle případě IPv6 totiž dává smysl.
Samozřejmě že používat IPv6 a ne NAT dává smysl. Jenže v tomto případě to není něco, co by h4kuna mohl ovlivnit. Pokud chce provozovat web server, který bude dostupný komukoli z celého světa, zatím mu nezbývá, než podporovat i IPv4.


Zásadní otázka zní: jakou IP adresu má Váš domácí server napsanou na síťovém rozhraní? Jestli je tam cokoliv jiného, než IP adresa 81.25.21.57 tak to bez dalších berliček nebude nikdy fungovat.
Má tam 192.168.86.34. Jak to vím? No před tím, než odpovídám v diskusi, přečtu si dotaz a ostatní komentáře.

Fungovat to samozřejmě může, akorát se musí použít hairpin NAT.

Důvody máte napsané v tom mailu od providera - veřejnou IP adresu dostáváte pomocí NAT 1:1 na hlavní bráně providera.
To, že je veřejná IP adresa řešena NATem 1:1 na hlavní bráně není žádný důvod, proč by to nemělo fungovat. On ten paket z vnitřní sítě nejspíš už teď doputuje na tu hlavní bránu. Takže stačí, aby se ten NAT neaplikoval jen na pakety, které přijdou na vnější rozhraní, ale aby se aplikoval i na vnitřním rozhraní. A aby se na tom vnitřním rozhraní aplikoval hairpin NAT, tedy DNAT+SNAT.

Pokud nechápete co pro Vás NAT 1:1 znamená, je to dost marný. Asi bych začal bych tím, že si najdete někoho, kdo rozumí síťím a správně Vám to nastaví.
h4kuna to chápat nemusí. Horší je, když se někdo, kdo to nechápe, pokouší radit – například vy.

kompletně přejít na IPv6 doma i u providera.
Jak se k tomu webu pak připojíte například z mobilního telefonu v síti českých operátorů? Takže to není řešení, ale hack, který vyřeší některé případy.

Rozběhnout doma interní DNS server, který pro adresy z vnitřní sítě bude vracet "správné" IP adresy z vaší lokální sítě. Vyřešíte svůj problém ale ne sousedův na přístupové síti stejného providera.
Další hack…

Pokud chcete řešit i přístup pro sousedy, zeptejete se providera, jestli provozuje vlastní DNS server.
Panebože, jen to ne. Chcete opravit jeden problém, ten nevyřešíte, a místo toho vyrobíte deset dalších problémů. Rozbijete DNSSEC, každé přidání dalšího DNS záznamu bude potřeba řešit s ISP, při případné změně IP adresy bude muset myslet na to, že je potřeba to změnit ještě v DNS ISP. A ISP by z toho také jistě byl nadšený, že má v DNS takovouhle nestandardnost a musí na to myslet při každé změně.

Hledat alternativní řešení je jistě zajímavá disciplína. Ale nesmí se to zvrhnout v soutěž o nalezení toho nejblbějšího možného řešení.

Domluvit se s providerem, aby pro IP 81.25.21.57 a porty 80,443 dělal Harpin-NAT na svém routeru - vyřeší určitě problém přístupu souseda a pokud nebude nějaká zrada na Vašem D-Linku, tak i ten Váš. To je asi nejrychlejší řešení, otázkou je, jestli se providerovi bude do nestandartních konfigurací chcít.
Zrada na domácím routeru nebude – od začátku víme, že spojení z internetu funguje. Když se ISP nebude chtít do nestandardních konfigurací, je to ideální situace – opraví ten NAT nejen pro h4kuna, ale i pro všechny ostatní své zákazníky.

Domluvit se s providerem, jestli Vám odroutuje další rozsah /30 veřejných IP adres až na Vaše zařízení. Tam si s tím uděláte co potřebujete a pokud tomu alespoň částečně rozumíte, protáhnete ty veřejné IP adresy až na síťovku Vašeho serveru. Problém vyřešen pro vás, pro souseda, pro celý internet. Akorát počítejte s tím, že to může být dražší (platíte 4 IP adresy) a opět platí, že pokud neumíte správně nakonfigurovat firewall, vyřešením jednoho problému vznikne spousta jiných.
Platit 4 veřejné IPv4 adresy nemusí. Záleží na tom, kolik takových zákazníků ISP má, jak velkou má síť, případně se to dá řešit trošku chytřejším routerem, kterému půjde nakonfigurovat na WAN portu dvě IPv4 adresy. Žádná speciální konfigurace firewallu v tomhle případě není potřeba.

Providerovi nemusíte psát nic, on Vám korektně odpověděl akorát Vy jste ho nepochopil.
Moc korektně neodpověděl. Nepřiznal, že to jejich řešení není tak docela funkční – a buď měl napsat, že tenhle zmetek mají ve smluvních podmínkách a že na tom tudíž nic měnit nebudou, nebo slíbit nápravu. Problém s pochopením situace tu máte spíš vy.

Stačí když se budete řídit myšlenkami velkého Iljiče: "... učit se, učit se, učit se"
Víte, co by bylo báječné? Kdyby se lidé řídili svými vlastními radami.

A jestli vážně chcete doma provozovat www server dostupný z internetu, tak doporučuji se poohlédnout po nějakém jiném routeru než základní segment D-Link, TP-Link atd. Potřebujete router, který má nějaký dlouhodobý support, výrobce pravidelně řeší bezpečnostní díry a vydává aktualizace firmware víc než jednou.
Jistě, tenhle router není žádný zázrak. Ale vzhledem k tomu, že z internetu k němu ISP pustí jen TCP na portech 80, 443 a 2222, které jsou na routeru přesměrované dál na ten server, ten router toho nemá moc co zkazit. Mnohem horší bude přístup z lokální sítě a možná i plný přístup k WAN z celé vnitřní sítě ISP – a to nezávisí na tom, že má přidělenou veřejnou IPv4 adresu.

17
Server / Re:VS Code, práce s Podmanem
« kdy: 29. 05. 2020, 12:52:40 »
samozřejmě to nefunguje na Podman
Co znamená, že to nefunguje? Já na tom nic samozřejmého nevidím, Podman je záměrně udělaný tak, aby mohl fungovat alias docker=podman. Je možné, že to rozšíření nekomunikuje s Docekrem přes utilitu docker, ale přes socketové API (Docker API). Podman pro vzdálené ovládání používá varlink. Byly kolem toho nějaké dohady, zda se tam přidá i můstek pro Docker API, nevím, jaký je současný stav.

18
Stále by mě zajímalo ikdybych měl router co umí statické DNS, tak soused můj web server neuvidí, že?

Já tu zkušenost nemám a netuším jak by se to zachovalo, tak proto se ptám jak je to s tím routrem. Bych mu navrhnul ať mi přijde nainstalovat a nastavit router se statickou DNS, že mu to zaplatím když to bude fungovat mě i sousedovi a pokud ne tak nebudu platit nic. Protože jinak ho asi ze židle nezvednu.
Ano, když to spravíte ve své síti tím, že se komunikace do sítě ISP vůbec nedostane (což je příklad toho statického DNS), soused ten váš web stále neuvidí. To statické DNS je ekvivalent toho, že byste si na všech počítačích ve své síti nastavil záznam do /etc/hosts.

To statické DNS řeší jenom to, že když vy ve své síti zadáte tu webovou adresu, přeloží se to na jinou adresu a bude se komunikovat jenom v rámci vaší domácí sítě. Když ale tu adresu zadá soused, váš statický DNS vůbec nevstupuje do hry – u souseda se to zase přeloží na tu veřejnou IP adresu 81.25.21.57, komunikace s ní bude směřovat někam do sítě ISP a tam se ztratí.

Jenom doufám, že toho ISP nenapadne to řešit tak, že bude DNS dotazy na tuhle doménu unášet a přepisovat na tu privátní IP adresu. Sice by to nefungovalo těm, kteří validují DNSSEC, ale obávám se, že to by ISP zase prohlásil za jejich problém.

19
Stále by mě zajímalo ikdybych měl router co umí statické DNS, tak soused můj web server neuvidí, že? To podle mě není cesta.
Přesně tak, ten problém není jen ve vaší domácí síti, ale u všech klientů ISP (podle toho, že ISP píše, že řeší jen provoz z internetu).

Že vše funguje, jak má – asi to funguje tak, jak chtějí, aby to fungovalo. Ale rozhodně to není očekávané chování – když máte veřejnou IP adresu, měla by fungovat skutečně všem, včetně vašich sousedů. Kdyby nefungovala jenom vám, asi by se o tom dalo dohadovat, že ISP je v právu. Ale to, že to nefunguje ostatním jeho zákazníkům, je podle mne neomluvitelné.

Pokud máte dobré vztahy se sousedy, můžete zkusit, aby to reklamovali oni :-)

20
Pokud mu to nesdělíš, a on to neopraví, tak tady můžeš vytvářet libovolné teorie a návody
Sdělovat mu to nebudu já, ale h4kuna. Já jsem jen opravoval vaše chybné tvrzení, že je potřeba se ISP na něco ptát. Ne, nepotřebujeme se ho ptát, jak má řešené veřejné IPv4 adresy, protože to víme – portforwardingem tří portů 80, 443 a 2222 na privátní IPv4 adresu, kterou ISP přidělil zákazníkovi. A není potřeba se ho ptát ani na nic jiného, protože chybu musí opravit ISP, ne h4kuna.

21
Server / Re:uzavření uživatele v domovském adresáři
« kdy: 28. 05. 2020, 11:56:34 »
Pokud potřebuje jen stahovat soubory, nepotřebuje ani shell a můžete ho omezit opravdu jen na práci se soubory. Vše je popsané v článku Jak nahradit FTP pomocí SFTP a zamknout uživatele.

22
Musel jsem změnit port na 2222, protože od IPS mám všechny porty blokované až na 80,443,2222 a asi chceme zkontrolovat kam ten paket dojde.

Pomocí příkazu jsem zkontrolovat že na port 2222 nemám nic.
sudo netstat -nlpt | grep '2222'

pomocí příkazu `ip a` jsem vybral síťovku 'enp59s0' mající ip adresu 192.168.86.34, připojil jsem si zase kabel z antény přímo na počítač.

tcpdump -n 'port 2222' -i 'enp59s0'

telnet 81.25.21.57 2222

Výsledky jsou na obrázku.
Ty dva řádky 122.91.18.119 ignorujte, to je nějaký robot z Asie, asi zkouší nestandardní port pro SSH. Zbytek jsou jenom vaše odchozí pakety, z routeru ISP se ani nevrátili.

Tj. ISP řekněte, že vy ani vaši sousedé u stejného ISP se nemohou připojit na vaši veřejnou IP adresu 81.25.21.57. Můžete přiložit ten výpis tcpdumpu s tím, že pakety od vás na 81.25.21.57 odejdou, ale už se nevrátí zpět s cílovou IP adresou 192.168.86.34. Pokud by se ISP vymlouval, že je to váš problém, argumentujte tím, že to nejde ani u sousedů, kteří jsou k němu také připojení – ale jinde z internetu, že to jde.

Každopádně s ISP vůbec neřešte doménu, to ho možná zmátlo – řešte jen tu veřejnou IP adresu.

Dotyčný ISP má pravděpodobně ten DNAT nastaven jen na vnějším rozhraní do internetu a pakety z vnitřní sítě směrované na veřejné IP adresy jeho klientů se mu někde ztrácí.

23
Buď se tady trefíme do schůdného řešení metodou Monte Carlo (https://en.wikipedia.org/wiki/Monte_Carlo_method) a nebo se stejně musíš zeptat
ISP má špatně nastavenou síť. Není na co se ho ptát – je potřeba mu říct, že si má síť opravit. A vzhledem k tomu, že ISP se zatím tváří, že neví, co má špatně, je potřeba mu to sdělit.

24
nebo to řešit na svém routeru
Znovu opakuju, že to h4kuna na svém routeru vyřešit nemůže. Může problém obejít, aby se neprojevoval v jeho domácí síti. Ale pro některé jiné zákazníky (a já bych si tipnul, že v tomto případě spíš pro všechny) téhož ISP bude ten problém dál trvat – tj. nedostanou se na ten webserver, tj. například na web matejckovi.eu. Vzhledem k tomu, že zákazníci toho ISP budou pravděpodobně lidé v okolí, třeba sousedé, může to být docela problém. Je spousta webů, které jsou zaměřené na okolí – třeba truhlář asi nebude získávat mnoho zakázek z druhého konce republiky, ale spíš od lidí ze stejné ulice, ze sousední vesnice apod.

25
Jelikož jsem nepochopil proč mi to nefunguje, tak momentálně ani nejsem schopen rozlišit jestli jsem dostal relevantní odpověď (koupí mikrotiku).
Z toho, co jste zatím napsal, si nedovedu představit situaci, kdy by to byl problém v konfiguraci sítě ve vašem domácím routeru – takže koupě Mikrotiku by to neřešila. S Mikrotikem místo toho D-Linku by bylo snazší vypátrat příčinu nebo problém obejít, ale v tuto chvíli by mi to připadalo jako zbytečná investice.

Výstup nslookup a host posílám na obrázku. Udělal jsem to, že jsem tu mašinu připojil napřímo, tzn nehrál v tom roli můj domácí router. Výstupy jsou identické jako když tam router byl.

Jen doplním, že vlastní DNS ani na routru ani na servru nemám.

Sám jsem žádný NAT nekonfiguroval ani vědomě neprovozuji. Router je v továrním nastavení až na přesměrování portů (80/443), právě na server. Nic jiného na routru není.

Chování domény nebo ip v prohlížeči je stejné.

V hosts doménu uvedenou nemám, jak jsem psal bylo by to polovičaté řešení pro konkretní počítač, ale pro mobil to cesta není.
Podle toho výpisu se doména u vás překládá správně. Mimochodem, odpovídá vám lokální DNS resolver – tohle řešení se často používá při validaci DNSSEC. Takže kdybyste si na svém routeru tu doménu unesl, jak tu někteří doporučují, na tomhle konkrétním počítači by vám přestala fungovat, protože by odpovědi nebyly podepsané.

Každopádně to není problém DNS ale konfigurace sítě.

Zkusil bych tedy následující. Stejně jako jste zkoušel to DNS, spustit následující příkaz:

Kód: [Vybrat]
tcpdump -n 'port 4444'Pokud by to zařízení mělo víc fyzických rozhraní (třeba LAN a WiFi), bude nutné ještě pomocí parametru -i určit, které rozhraní se má použít (to, kam připojujete přípojku od ISP).

Tím zapnete zachytávání paketů na portu 4444 (nestandardní port, takže tam snad nebude žádný jiný provoz).

V druhé konzoli pak zadejte jen
Kód: [Vybrat]
telnet 81.25.21.57 4444Žádné spojení se samozřejmě nemůže podařit navázat, protože na tom portu 4444 snad nic neposlouchá, ale jde jen o ty pakety při pokusu o navázání spojení.

V konzoli tcpdumpu by se mělo objevit něco takového:
Kód: [Vybrat]
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens3, link-type EN10MB (Ethernet), capture size 262144 bytes
08:32:02.512559 IP 192.168.86.34.48142 > 81.25.21.57.4444: Flags [S], seq … length 0
08:32:02.512660 IP 192.168.86.34.48142 > 192.168.86.34.4444: Flags [S], seq … length 0
Sledování pak ukončíte pomocí Ctrl+C.

Předpokládám, že tam budou jen dva pakety (dva řádky po té hlavičce). Důležité jsou ty dvě IP adresy vždy na začátku řádku. První paket je odchozí z vašeho počítače na veřejnou IP adresu. Druhý je ten samý paket po té, co prošel NATem u ISP a vrací se na váš router. Důležitá je jeho zdrojová IP adresa (ta první) – pokud tam bude 192.168.86.34 (tedy ta vaše privátní IP adresa, kterou vám přidělil ISP), je to špatně. Odpověď na tenhle paket se totiž nemůže dostat k NATu vašeho ISP, aby se tam adresy přeložily zpět. Pokud by tam byla jiná IP adresa (měla by to být adresa NATu ISP), je problém jinde, než si myslím :-)

Pokud se to potvrdí, je problém na straně ISP – dělá jen DNAT (přepíše cílovou IP adresu), ale nedělá SNAT (nepřepíše zdrojovou IP adresu, takže pak nemůže fungovat komunikace ze stejné sítě, ze které byl ten paket odeslán). Tohle řešení, kdy se vedle DNATu dělá také SNAT, aby se paket vrátil zpět na NATující stroj, se často nazývá „hairpin NAT“ (tím SNATem se paket „přišpendlí“ k tomu NATu, aby se k němu vrátila odpověď).

To by bylo to, co pak musíte po svém ISP požadovat – aby pro tu vaši veřejnou IP adresu (ale raději pro všechny veřejné IP adresy, které takhle poskytuje), nastavil hairpin NAT, nebo-li nastavil i SNAT, který změní odchozí adresu paketu tak, aby se odpovědní paket vrátil zpět na NAT ISP a tam se mohl zpět přeložit.

A ještě vysvětlení, proč to celé bez toho SNATu nefunguje – váš prohlížeč(například) pošle požadavek na 81.25.21.57, na NATu ISP se to přeloží na 192.168.86.34. Kvůli chybějícímu SNATu se ale odpověď nepošle na NAT ISP (který by 192.168.86.34 přeložil zpět na 81.25.21.57 – to dělá NAT u ISP automaticky), ale pošle se vašemu prohlížeči přímo, bez překladu. Takže počítač dostane odpověď od 192.168.86.34. Jenže on posílal požadavek na 81.25.21.57, odpověď od 192.168.86.34 nečeká a zahodí ji. Tím pádem se nikdy nemůže navázat spojení.

26
za pul hodiny mam hotovo a vyresen problem ktery op resi.
Ne, ten problém by nebyl vyřešen. Pouze se problém v některých případech obejde.

Je skoro jisté, že ta veřejná IP adresa je nedostupná i od dalších zákazníků toho ISP ve stejné síti; je dost pravděpodobné, že je nedostupná od všech jeho zákazníků. Pak bude h4kuna chtít ukázat sousedům fotky, nebo na serveru zprovoznit web pro místní spolek, a bude znova řešit, proč se tam půlka lidí nedostane.

Predpokladam, ze ty okrajove pripady ho netrapi.
Teď třeba ne, všechny takovéhle hacky jsou jen časovaná bomba.

Zajimalo by me jak dlouho se bude pretahovat s ISP nez to vyresi...
To záleží na schopnostech ISP. Neúspěch by znamenal varování a pro mne by to byl podnět hledat jiného ISP, protože pokud ISP neumí opravit takovouhle věc, jak asi bude řešit jiné problémy? A pokud ISP ten problém vyřeší správně, pomůže to úplně všem, kteří u něj mají veřejnou IP adresu.

Nikde netvrdím, že je problém/chyba v NATu na domácím routeru.
Pokud chyba není v NATu na domácím routeru, byla by chyba pokoušet se to na domácím routeru opravovat.

I kdyby se jednalo o "chybně nakonfigurovaný NAT ISP", tak je o zcela běžnou situaci i u velkých ISP
Ne, není. Velcí ISP neřeší NAT na linuxovém nebo mikrotikovém firewallu a přidělení veřejné IP adresy neřeší tím, že na tomhle odchozím NATu správce ručně přidá pravidlo pro příchozí veřejnou IP adresu. Velký ISP když vám dá veřejnou IP adresu, dopraví ji až na vaše rozhraní. (Velkým ISP nemyslím městskou síťku s tisíci klienty.)

hairpin NAT na domácím routeru to vyřeší (investice v rozmezí 500,- až 1500,-).
Nevyřeší. Už jsem tu několikrát vysvětloval proč.

Btw. dle mě se o chybnou konfiguraci u ISP nejedná
Ta veřejná IP adresa je nedostupná z části (s velkou pravděpodobností z celé) sítě ISP. S největší pravděpodobností jsou tak postižené všechny veřejné IP přidělené zákazníkům toho ISP. To je chybná konfigurace.

v zájmu ISP rozhodně není vytěžování hraničního routeru a linek provozem, který lze směřovat lokálně
To není v zájmu ISP. Ale za prvé tenhle provoz bude minimální oproti jinému provozu; za druhé to není omluva, aby to
nefungovalo; a za třetí si to způsobil sám ISP, když veřejnou IP adresu řeší NATem. Kdyby tu veřejnou IP adresu normálně routoval, tenhle problém by se nestal a ten provoz by se nehnal zbytečně na hraniční NAT a zase zpět.

Ja to mikrotiku riešim jednoducho..
No jo, ale to máte veřejnou IP adresou routovanou až na váš domácí router. h4kuna to tak ale nemá, ISP jeho veřejnou IPv4 adresu NATuje na privátní už někde na svém NATu – a chyba je nejspíš tam.

27
DNSSEC - moc se nebojim, ze by mi ve vlastni siti nekdo neco podvrhoval takze tam ho nebudu resit. Pri pristupu z venku muze normalne fungovat... nevidim zadny rozbijeni, ale moc tomu nerozumim tak si rad necham vysvetlit...
Pokud budete na domácím počítači validovat DNSSEC, těžko budete konfigurovat, že pro jednu doménu validovat nemá. A už vůbec se vám nebude chtít konfigurovat to na každém zařízení zvlášť.

Prechody mezi sitemi - mam to doma obdobne - nekolik wifi (oddelene) a mobilni data na nekterych zarizenich. problemy pri prechodu jsem nezaznamenal
Když se vám stáhne DNS záznam s veřejnou IP adresou přes síť mobilního operátora, a pak přejdete do domácí sítě, nebude vám tam ta veřejná IP adresa fungovat. Jasně, pokud to uděláte s mobilem, systém asi vymaže DNS cache, aplikace s tím počítají a zeptají se znovu. Možná. Ale třeba také to zařízení přepínající se z jedné sítě do jiné bude router, a zařízení za ním už se o žádném přepnutí nedozví a DNS cache nevymažou.

8.8.8.8 jako fallback kdyz nenajdu lokalni zaznam funguje. zadny problem jsem nenasel
Jako fallback. Ale někdo má tenhle DNS server nastavený napevno. Třeba v notebooku, protože se s ním připojuje do různých sítí, které mohou mít DNS různě pokažené.

Ano, všechno jsou to zatím spíš okrajové případy, dá se s tím žít. Ale opravdu si chcete tohle všechno rozbít jen kvůli tomu, že ISP má špatně nakonfigurovanou síť? Když to problém vyřeší jenom u vás ale už ne u sousedů? Bral bych to jako poslední možnost, pokud to ISP nebude chtít řešit a není na výběr jiný ISP. Ale nač stahovat kalhoty, když brod je ještě daleko?

28
Zda to nefunguje i od ostatních klientů daného ISP nebo jenom jemu samotnému, to  nemůžeš říci obecně, záleží na tom, jak je síť ISP udělána. Takže to může správně fungovat nejen zvenku (což funguje), ale i ostatním klientům daného ISP (nebo nějaké části) a problém je jen sám se sebou.
Já jsem ale nepsal o všech ostatních klientech ISP. Napsal jsem, že to nefunguje těm klientům, kteří jsou za stejným NATem. No a vzhledem k tomu, že ten ISP asi nemá správně nastavený hairpin NAT, pochybuju, že má každého klienta v samostatné síti.

Zda je problém s hairpin nat na straně ISPíka může zkusit rovnou s tcpdump na tom cílovém serveru a následným pokusem o spojení na tu veřejku, zda uvidí v tcpdump nějaký pokus o příchozí spojení a s jakou zdrojovou IP (pokud budou chodit se zdrojovou IP 192.168.86.34, tak ISP nemá hirpin správně u sebe a ani ten dlink nemá RP strict filtr).
h4kuna má pravděpodobně na svém domácím routeru také NAT. A pokud je to hairpin NAT, přepíše se i zdrojová IP adresa, takže na cílovém serveru uvidí vždy adresu routeru, bez ohledu na to, zda to ISP má nakonfigurované správně nebo špatně.

29
Kde a co to rozbije?
Rozbije to DNSSEC, rozbije to přechody mezi sítěmi (třeba mezi WiFi a mobilní sítí), nebude to fungovat s použitím jiných DNS resolverů (třeba čtyři osmičky).

30
Ja bych na tu malinu prihodil dnsmasq. Nastavil si router at posila klientum jako primarni dns tu malinu a na ni si muzes hrat...
Pokud vim tak se da dnsmasq nastavit tak, ze cte /etc/hosts a co tam nenajde tak je fallback nekam jinam... treba na 8.8.8.8
Pokud je chyba u ISP, může ho ve své síti pomocí DNS obejít (pokud na té doméně není DNSSEC). Ale nebude to fungovat ostatním uživatelům daného ISP, kteří jsou za stejným NATem. Takže bych se nejdřív snažil, aby to ISP spravil, než bych se pustil do polofunkčních hacků DNS, které rozbijí kde co.

Stran: 1 [2] 3 4 ... 254

reklama