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 - M_D

Stran: 1 ... 13 14 [15] 16 17 ... 19
211
Pokud ten router měnil, tak starej snad nevyhodil. Co si ho zapnout na stole, podívat se, co je tam nastaveno a opsat to v maximánlí míře do toho nového? Pokud to není nějaká extra obskurnost, tak by to mohl zvládnout i né moc znalý človíček.

212
Sítě / Re:RB433AH jako domácí router
« kdy: 01. 06. 2020, 13:32:47 »
U toho 10 let starého RB433AH bych počítal, že bude chtít vyměnit kondíky na desce, vysychají a pak se RBčko seká. Dále nepřehládnout, zda je to v krabičce a s nějakou osazeeou wifi kartou, jinak cena může stoupnout. Taktéž zvážít, zda 3 Ethernet 100 Mbps porty celkem stačí.

213
Popis na jejich webu daného problému je zde: https://wiki.mikrotik.com/wiki/Hairpin_NAT
To je dobrý začátek. Ještě kdyby někdo měl návod, jak se to nakliká ve WinBoxu, myslím, že by to mělo větší naději na úspěch.
Blbý je, že to pokud neznáš reálii daného zapojení u ISP, tak to naslepo úplně napsat nejde, když nevíš IP rozsahy, použité interfejsy. Jen obecně princip, což je na té wikině, to si je třeba přizpůsobit. U Mikrotiku k tomu byla ještě jedna stránka pro blbější, ale nejde dohledat. To by muel tazatelasoň přihodit traceroute 8.8.8.8 od sebe a souseda, pro inspiraci.

Add to obětovat 4 večejné IP adresy (/30) kvůli zákazníkovi se nechce. Tohle bývá důvod, zvláště pokud to vypadá, že celý veřejný rozsah daného ISP je jendo /24. Ale k tomu dochází, pokud stavíš síť operátora jako normální sít koncovou a ne jako přístupovou. Při správně udělané přístupové síti spotřebuji přesně jednu IPv4 adresu na zákazníka a ne /30. Rozsah /30 si můžu dovolit i firemní přípojky za jinou cenu. Dle pohledu to vypadá, pokud jde o Comfeel s.r.o., že jde o typického ISP okresního formátu bezdrátového typu, co z malého nadšení OSVČ vyrostl do s.r.o s okresního rozsahu a vedle ISPíkařiny má i další činnosti, takže to už bude víc jak one-man-show, tak snad se podaří. :-)

Takovýchto je v republice. A v řadě míst není moc co jiného na výběr. Ale s většinou se dá domluvit. Ale je fakt, že u řady to nakonec dopadlo tak, že tady máte přihlášení na winbox, nastav si to a my se na to podíváme - a od té doby to používají. :-)
Jinak k tomu NAT 1:1 pro doručování veřejné IPv4 adresy k zákazníkovi. Upřimně, tato technika se používá běžně i u ISP, co jsou velikostně 100k+ zákazníků. A v poslední době jsme musel řešit i pár přípojek v sousedním Německu - i ve starých zemích, jako firemní přípojku sehnat něco, kde dostanu pevnou veřejnou IPv4 adresu až na pobočkový router, tak to je dneska někde zázrak. A další země, .... NO COMMENT

214
Uff, je to těžký. Asi začínám věřit, že nechápe, co po něm chceš. :-)

Pokud ještě komunikuje, tak mu budeš muset vysvětlit, co přesně chceš a když to pochopí, tak to asi i udělá (a když to udělá dobře, tak to začne fungovat tvým sousedům i tobě).

Řekl bych, ře chceš k svému webu doma přistupovat hlavně pomocí prohlížeče, do kterého zadáš to https://matej...., Což aktuálně funguje správně těm, co k němu přistupují odněkud od jiných operátorů, takže základní DSTNAT dělá débře. Nefunguje to lidem, co jsou jeho zákazníci. Aby to fungovalo, tak musí donastavit, aby se vedle toho DSTNAT prováděl současně i SRCNAT pro spojení přicházející z jeho sítě na té NAT bráně. Dovoluješ si předpokládat, že použivá Mikrotik/RouterOS, aspoň toto řada měnších ISP. Popis na jejich webu daného problému je zde: https://wiki.mikrotik.com/wiki/Hairpin_NAT

215
Windows a jiné systémy / Re:SRV záznam pro active directory
« kdy: 29. 05. 2020, 18:03:02 »
Tomu používat sambu4 jak default resolver pro vše bych se spíše snažil vyhnout. Ten INTERNAL_DNS umí jen odpovídat na záznamy, co potřebuje AD k provozu pro danou doménu. Cokoliv jiného jen tupě forwarduje dál, ani nekešuje, nedělá rekurzi, ... Jen co nezná, tupě přeposílá dál dle volby v cfg dns forwarder = ... a ještě celkem pomalu.
Korektnější je mít v klientech jako DNS nějaký relativně normální resolver, co případně se pro danou sub jen sáhne na Sambu, takže je obtěžována jen relevantníma dotazy.

216
Windows a jiné systémy / Re:SRV záznam pro active directory
« kdy: 29. 05. 2020, 10:26:57 »
Provozuji něco podobného.
Ano, v domain.tld uděláš delegaci na sub (NS & glue A), a v rámci té sub to řídí celé samba a všechny ty SRV záznamy jsou v ní.
Do domain.tld si přidávám položku _kerberos IN TXT "SUB.DOMAIN.TLD", protože máme vše nad kerberosem a tak ať funguje dohledávání správne realm domény.

Pokud to namlátíš ručně přímo do domain.tld (čili ne jako sub.domain.tld), tak to nějak funguje, ale některé věci blbou. To jsem si už dříve ověřil. Pokud to máš v rámci toho domain.tld DNS serveru zadáno ručně vše správně s sub.domain.tld, tak to fuguje OK.

217
Na tvém routeru (ať už pomocí DNS, NATu, routingu, ...) souseda nevyřešíš. To jen řeší, aby to fungovalo tobě samotnému doma.
Pokud chceš ještě zkusit, tak ať soused se zkusí spojit na tu tvoji interní IP 192.168.86.34, zda se spojí na ni OK. To by mělo dle té odpovědi od ISP fungovat, ale neřeší to nic moc, jen ukáže, že vyloženě neblokuje komunikaci mezi svými zákazníky.
Případně si proleť podmínky služby. Že to nefunguje tobě samotnému, tak může ISPík argumentovat, ať si to pořešíš na svém routeru, že tvoje interní komunikace utíká do jeho sítě a dropuje ji. Ale ta nefunkčnost od souseda je už jiná. Nicméně někteří ISP vzájemnou komunikaci mezi svými zákazníky blokují, pokud oba nemají veřejnou IP. Ale to by měl mít v podmínkách.

Add ta routa v tom DLinku, pokud nedovolí nastavit, že ta routa má jít do LAN, tak to takto pro sebe neohneš. Už jen to, že nedovolí libovolnou masku, ale upraví ti /32 na /24, tak to ukazuje, že je ten router v možnostech dost omezen. Podobně i to, že asi neumí ani ty varianty hairpin NATu.

218
Nu, DNS odpovídá OK.
Nefunguje to proto, že ISP nedělá (ať již z blbosti nebo úmyslně) správně otočení provozu pro tu veřejnou IP adresu zpět. Buď žádat nápravu po něm nebo to řešit na svém routeru, to druhé má výhodu, že lokální provoz mezi domácím klientem a serverem nemusí pochodovat přes celou síť ISP, ale odehraje se jen v rámci domácí LAN.
Ten Dlink asi neumí hairpin NAT, protože se hodně lidí ptá jak na něj a žádná rozumné odpověď.
Router umí nastavit statické routy. Takže bych zkusil použil tu. Na routeru nastavit, že IP 81.25.21.57 má směrovat na bránu 192.168.1.666, předpokládám, že tu 192.168.1.666 nahradíte IP toho cílového serveru v lokální síti. Na tom cílovém, serveru si přidáte tu veřejnou IP adresu. Takže v linuxu z příkazové řádky něco jako: "ip a a 81.25.21.57/32 dev eth0 label eth0:0" a uvidí se, zda začne ta IP z lokální LAN odpovídat. Je třeba nahradit to eth0 patřičně jménem nějaké síťovky v tom routeru. Když to bude pak fungovat, je vhodné se podívat, jak se takový alias nastavit, aby platil i po restartu, což je dáno použitou distribucí.

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

220
Nu, pokud tam chce lézt i z mobilů a podobných, tak na domácí lince bych se spíše snažil obejít bez toho duálního DNS (ať už pomocí funkce v routeru nebo v tom serveru), kdy by pro lokální klienty vracel přímo interní IP. Řada věcí dneska se snaží už lokální resolvery DNS servery dodané od DHCP ignorovat a pokud odpovídají, tak použijí nějaké veřejné, DoH. ... Tohle se dá "spolehlivě" použít na firemní síti, kde klienti nemají vůbec přístup ven a nemají jinou možnost, než použít lokální resolver.
Spíše bych senažil o stav, aby ta veřejná IP korektně fungovala i z vnitřku sítě.

221
Vyzkoušejte si, zda se správně překládá i na vašem domácím počítači.

Přes ping to prostě nikam nedojde. Takže nepřekládá.


Možná prvně zkusit na tom svém domácím komplu něoc jako: nslookup matejckovi.eu
zda ti to vrátí správnou IP. Pokud ano, tak pak řešit tne hair pin NAT. ISPík to nemá asi správně u sebe nastaveno, takže buď mu to vysvětlit nebo to řešit na svém routeru.
Pokud router neumí hairpin nat a nechci ho měnit, tak je ještě možnost nastavit v něm statickou routu, kdy tu IP 81.25.21.57 budu směrovat na ten own server (na jeho vnitřní IP) a v serveru si tu veřejnou IP přidám jako alias.

222
Sítě / Re:Interní IPv6 a domény ve veřejném DNS
« kdy: 26. 05. 2020, 21:35:59 »
Daný ISP je už historie, respektive pohlcen firmou Starnet a nahrazeno jejich službami. Ta je asi jedna z mála, co provozuje vlastní plné resolvery.
Jinak podobné služby používá hodně ISP. Těch, co si to řeší ve vlastní režii, tak ubejvá. Pár nejmenších to řeší redirectem na Google a spol. Ty větší přestává bavit se o svoje rekurzory starat, tak skočí na nějakou takovou nabídku.
Apropo, třeba u O2 tomu familiárně říkají "pračka DNS". Aspoň dle slov technika, s kterým jsme něco řešili (a dle jeho slov je to nasazeno jen na rezidentní zákazníky, ne na business linky).
Whalebone asi neexistující fomény neunáší, to jsem nepostřehl. Spíše tím blábolem chce naznačit, že když služba nevydělává, tka ji za malý bakšiš můžou nakoupit jinde, než se s ní dřít.
Ale tohle je už dost jinde od původního dotazu...

223
Sítě / Re:Interní IPv6 a domény ve veřejném DNS
« kdy: 25. 05. 2020, 20:24:44 »
A pokud používají službu subjektu, který je schopen začít celou doménu dropovat proto, že v ní potkal pár 10.x.y.z, tak doména dokáže zmizet pro slušnou řádku přípojek (pokud využívají DNS od svého operátora).
Mohl byste být konkrétní, kdo něco takového dělá?
Z ISPíka kolega nevyrazil, koho konkrétně používá. Díval jsem se, že v Česku je vidět cca 3 až 5 firem, co tu nabízí takováto profi DNS řešení jako službu. A jak jsem pochopil, dostat se na u nich na DNS blacklist je ještě jednodušší, než na mail SPAM list.
Nejvíce je asi vidět Whalebone.

224
Sítě / Re:Interní IPv6 a domény ve veřejném DNS
« kdy: 25. 05. 2020, 08:18:52 »
Add to dvoje DNS, jasný, když k tomu nemám vhodný automatizační nástorj, tak je to na palici mít dvě oddělené DNS. Navíc u některých věcí je problém, pokud mám ve veřejném DNS jeden stroj s veřejnou IP a v interním je s vnitřní. Někteří klienti, co migrují mezi vnitřkem a vnějškem, tak to blbě nesou (ne vždy zcela korektně flushují DNS cache). Takže u takových strjů máme vždy stejné veřejné IPv4/6 v obojím DNS.
K tomu dávat neveřejné IP (RFC1918 a spol) do veřejného DNS. Nepřehánět, snadno tak sami na sebe můžete dnes udělat atentát. Dneska řada ISP neprovozuje svoje rekurzivní DNS servery, využívá dodaných služeb někoho dalšího, kdo dodává služby DNS resolvingu, včetně filtrování, ochran před útoky a další bla bla bla (a tím nemyslím přesměrování DNS na 8.8.8.8/1.1.1.1). A pokud používají službu subjektu, který je schopen začít celou doménu dropovat proto, že v ní potkal pár 10.x.y.z, tak doména dokáže zmizet pro slušnou řádku přípojek (pokud využívají DNS od svého operátora). Výborná obdoba blacklistů pro SMTP a spol, s podobným důsledkem, zabalená do těch "nejlepších úmyslů". :-)

225
Vývoj / Re:Synchronizacia real-time dat, s datami z RESTu
« kdy: 22. 05. 2020, 14:51:20 »
Tak ono bude i záležet o to, jakou technologií to na straně serveru bude řešeno. Může být to vše v rámci toho WS spojení, můžete mít vedle sebe WS a klasické GET.
Pokud bych tam měl třeba mosquitto MQTT, který v základu umí, že při navázání spojení pošle hned poslední archivovanou zprávu, tak si otevřu WS spojení, přijde mi hned poslední zpráva a pokud z ní odvodím, pro co si sáhnu přes GET do archívu, tak je to to, co popisujete ve svém návrhu.
Pokud budu mít použitu třeba Kafku, kde si jde snadno sáhnout pro X posledních zpráv, tak v rámci navázání WS spojení pošlu i posledních X zpráv a GET API budu mít bokem pro interaktivní listování archivem dle toho, jak uživatle kliká.
Možností je vždy víc...

Stran: 1 ... 13 14 [15] 16 17 ... 19