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 ... 253
1
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 :-)

2
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.

3
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.

4
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í.

5
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.

6
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.

7
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í.

8
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.

9
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?

10
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ě.

11
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).

12
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.

13
Hm, podle manuálu se zdá, že D-Llink DIR-850L zachytávání paketů neumí. Vyzkoušejte tedy nejdřív, zda není problém v DNS (ve vaší lokální síti). Zkuste si v prohlížeči otevřít http://81.25.21.57 – pokud se objeví váš web nebo alespoň chybová stránka, je problém v DNS. Pokud dostanete stejnou chybu, jako když zkoušíte https://matejckovi.eu, bude chyba spíš v NATu ISP.

V takovém případě bych na chvíli připojil počítač přímo k internetové přípojce (místo toho routeru). Ve Windows bych pak použil Wireshark, v Linuxu tcpdump, zapnout zachytávání paketů na nějaký port, který si vyberete, a pak se na něj zkusit připojit telnetem. Důležitá je zdrojová IP adresa v tom druhém paketu, který přijde a bude mít cílovou IP adresu 192.168.86.34. Pokud bude mít zdrojovou IP adresu také 192.168.86.34, má ISP chybně nakonfigurovaný ten NAT.

14
Buď si pořiďte router, který umí hairpinning (třeba Mikrotik)

leda nejaky vlastni NAT na routeru?

Vzhledem k tomu, že z internetu ta komunikace funguje, s největší pravděpodobností nebude problém v NATu na domácím routeru.

Nejpravděpodobnější jsou dvě možnosti – buď nějaké pokusy s tou doménou v domácí síti, takže se v ní nepřekládá. A nebo chybně nakonfigurovaný NAT ISP, který nefunguje pro přístup z vnitřní sítě ISP k těm NATovaným veřejným adresám.

15
Přes ping to prostě nikam nedojde. Takže nepřekládá.
To, že neprojde ping, neznamená, že se doména nepřekládá. Jako první bych tedy zkusil, zda se u vás opravdu doména překládá či nepřekládá – příkazem host nebo nslookup. Pokud by se nepřekládala – nemáte ji náhodou nastavenou v /etc/hosts nebo v lokálním DNS resolveru, třeba na routeru?

O veřejnou IP adresu jsem zažádal a je to 81.25.21.57, když kouknu na https://www.mojeip.cz/ dostanu 81.25.21.57 a na tuto IP ukazuje i DNS který je u FORPSI viz obrázek. Jen nerozumím tomu proč v routru k poskytovateli mám 192.168.86.34.
To je právě proto, že váš ISP vám tu veřejnou IP adresu mapuje přes NAT. Musí být u ISP nastavený správně, aby tu fungovalo i z vnitřní sítě a od vás.

Nejprve bych ale zjistil, jak je to s tím překladem DNS u vás – zda není problém v tom.

Mě tvrdí že on nic nastavit nemůže, na co ho mám nasměrovat?
Nejprve je potřeba zjistit, zda je chyba opravdu u něj.

Na svém routeru otestujte, že když zahájíte spojení s adresou matejckovi.eu, projde přes router nejprve paket směrem ven, jako adresa cíle je tam nastavená 81.25.21.57.

Tohle ověřím jak? S linuxem umím jestli vám to pomůže. Sítím tak do hloubky nerozumím.
Ideální je nastavit na vašem routeru zachytávání paketů na vnějším rozhraní – pokud to ten router umí. Zvolil bych si nějaký nestandardní port, třeba 1234, nastavil bych na routeru zachytávání paketů na tenhle port a pal zkusil

Kód: [Vybrat]
telnet 81.25.21.57 1234
Mimochodem, vyzkoušejte také ping na 81.25.21.57. Abyste porovnal,jak se to chová, když použijete DNS název a IP adresu.

Stran: [1] 2 3 ... 253

reklama