Apple představil nový MacBook Pro s čipy M4, M4 Pro a M4 Max.
Na GOG.com běží Halloween Sale 2024. Při té příležitosti lze získat zdarma počítačovou hru Return of the Phantom.
Společnost OpenAI spustila internetový vyhledávač ChatGPT search.
Konference OpenAlt 2024 proběhne již tento víkend 2. a 3. listopadu v prostorách FIT VUT v Brně. Začíná ale už v pátek na warm-up party ve Studentském klubu u Kachničky v 17:00. Pokud jste ještě areál FITu nenavštívili, k dispozici jsou pokyny k orientaci. Na programu je 54 přednášek a workshopů. Témata jsou od silně technických témat jako je třeba GCC nebo PostgreSQL po méně technické témata jako eGovernment, nebo třeba detailní analýzu … více »
Byla vydána nová verze 6.9 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 14.0.1. Tor client na verzi 0.4.8.13. Thunderbird na verzi 115.16.0.
Vývojáři free a open source synchronizačního nástroje (a p2p náhrady Dropboxu) Syncthing oznámili, že z důvodu odporu ze strany Google Play ukončují podporu OS Android. Bohužel v rámci toho zmizí i vydání Syncthing na F-Droid, který má slabší uživatelskou základnu. Syncthing je na Androidu implementován formou wrapper aplikace, která spustí Syncthing démon, vyžádá potřebná oprávnění a zpřístupní webové rozhraní démona. Ve srovnání se
… více »V červnu 2022 bylo oznámeno, že z K-9 Mailu se stane Thunderbird pro Android. Trvalo to poněkud déle, než vývojáři předpokládali, ale včera byl první stabilní Thunderbird pro Android 8.0 vydán.
Projekt microDMG Racer na Kickstarteru nevyšel, tak se autor rozhodl uvolnit na ESP32 postavené autíčko i ovladač jako open source.
Byl vydán TrueNAS SCALE 24.10 „Electric Eel“. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Byla vydána nová verze 24.10.29 svobodného multiplatformního video editoru Shotcut (Wikipedie) postaveného nad multimediálním frameworkem MLT. Nově s podporou AI (whisper.cpp) pro generování titulků. Nejnovější Shotcut je již vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
Jak zajistit veřejnou adresu internetovému providerovi navzdoryNatunelovat si ji tam odněkud, kde ji máte, to není zrovna zajistit. To samé s můžu udělat i u IPv4.
Neleze mi tak na rozhraní tuna bordelu. Končí u providera.To není výhoda – jen děláš z nouze ctnost. ISP ti místo NATu může poskytnout firewall, bordel odfiltruje a ty si k sobě necháš posílat jen vybrané služby. Snad jediná výhoda NATu je pocit anonymity resp. utajení vlastní identity (skrytí za společnou IP adresu). Ale tento pocit je falešný a prázdný, protože ISP stejně všechno loguje.
Snad jediná výhoda NATu je pocit anonymity resp. utajení vlastní identity (skrytí za společnou IP adresu)A o Piracy Extensions slyšeli?
Nech si ISP loguje*; mne hlavne vadi, ze ma podla IP poznaju weby.
* nie kazdy ISP loguje tak, aby to na nieco bolo - doma mam garazoveho providera, co ma len WEP sifrovanie, ale kluc vie kazdy, kto ma alebo mal internet (a kopec ludi, co to crackne). ISP si pri pripajani zapisoval MAC adresu PC "pre pripad problemov", ale nijak sa to neprejavilo zakazanim inych MAC adries. Snad kazdy, koho poznam, sa k sieti pripaja aj priamo z nenahlaseneho notebooku, takze keby niekto taky nieco spravil, tak ISP asi len poskytne svoje logy policii a mozno povie ze islo o neopravneny pristup...
A k čemu běžný user potřebuje veřejnou IP?K tomu, aby mohl využívat služeb na Internetu. Namátkou třeba telefonie, sdílení souborů, vzdáleného přístupu. Nebo třeba k tomu, aby nekolidovaly adresní rozsahy s firemní sítí a routy (řeší se níže).
Ten kdo potřebuje veřejnou IP se poohlíží přinejmenším po VPSNe.
Já jsem doma za natem od providera a vyhovuje mi to. Neleze mi tak na rozhraní tuna bordelu.Další, co si plete NAT a firewall.
Věci z venku tuneluji domů skrz VPN, vyhovuje mi to - provider neví co se na spoji děje.Ví to provider na druhé straně.
Nevidím důvod proč mít veřejnou IP jinak než pro účely serveru.Pokud obě strany VoIP nebo třeba Jabberu považujete za servery, tak máte naprostou pravdu.
Používat výrazy jako "vidí každý" je zavádějící. Skutečně každý to tak nevidí, tím si buďte jist.Vidí každý se týkalo plýtvání.
Mám pocit jakoby někdo zažil nějaký problém s nastavením něčeho za natem a tak ho to vzteklo, že celé IPV4 je kvůli tomu na houno a jediné možné východisko je IPV6.Já jsem s IPv4 zažil obrovský problém, když jsem se do jedné sítě pokoušel připojit víc než 4 miliardy zařízení, a bylo to skutečně na houno. A IPv6 je v současnosti asi jediný protokol, který tohle umí vyřešit.
A IPv6 je v současnosti asi jediný protokol, který tohle umí vyřešit.No, treba LISP (byla o nem i prednaska na Internet a Technologie 12) se mi libi vice. Dokonce v Japonsku ho udajne pouzivaji v ostrem provozu jiz na mnoha sitich.
K tomu "vidí každý": Zkuste zajít k ISP, který vám tahá linku kamsi doprostřed pole uprostřed země nikoho a řekněte mu, že potřebujete dvacet IP adres. Reakce jsou jednoznačné - ISP vám řekne: "OK, ale bude to stát šílené prachy a tolik IP adres považujeme za plýtvání, jestli potřebujete, my vám to pronatujeme", majitel, kterému takové řešení navrhnete, vám řekne: "Proč mám platit takové prachy, když ISP říkal, že se to da obejít, tohle považuju za plývání penězi" a konkurence řekne: "Neplýtvejte svými penězi, pane majiteli, my vám to uděláme laciněji!" No a potom člověk týden oživuje po telefonu lokální síť s poloneandrtálcem někde u Černého moře (to narážka na kvality několika konkrétních místních ISP, jakýkoli jiný význam odmítám). I já v takovém stavu vidím požadavek na dvacet IP adres jako plýtvání...
Pokud vidíte pouze servery, máte příliš omezený rozhled. Je spousta zařízení, která servery v pravém slova smyslu nejsou, ale bez veřejné ip adresy jsou jen obtížně k použití: bezpečnostní kamery, zabezpečení objektů, sběr dat, nastavení a ovládání zařízení, sběr meteorologických informací. Jistě - často se to dá obejít natem, ale místo jednoduchého "Zapoj to do sítě" to obvykle znamená sáhodlouhé telefonování s výše uvedeným poloneandrtálcem. A při každé výměně libovolného zařízení se uvedený scénář opakuje.
Jiné řešení - například VPN, kterou mi tady doporučovali - je ještě neschůdnější. Místo debaty s jedním "odborníkem" od ISP (který mívá aspoň rámcovou představu o použitých technologiích) je nutné jednat s dvaceti naprostými laiky a nastavovat jim VPN každému zvlášť (a taky po telefonu).
Používáním natu se navíc zbavujeme technologie, která dokáže mnohé usnadnit: DNS. Jak by se mi líbilo, kdybych měl zařízení v síti přístupná takto:
Ale to ne, nat mě nutí používat tohle:
Pochopitelně nemusím zmiňovat, že na každé elektrárně je číslovací schéma obvykle úplně jiné a závisí jednak na zapojených zařízeních a druhak na tvořivosti ISP, takže předem nikdy netušíte, co se vám na uvedeném čísle portu ozve, případně kde byste měl hledat požadované zařízení.
Já jsem doma za natem od providera a vyhovuje mi to. Neleze mi tak na rozhraní tuna bordelu.Než plácnete takovou blbost a prozradíte na sebe, že tématu ve skutečnosti nerozumíte, přečtěte si alespoň tuto diskusi celou.
Takže potom to vypadá tak, že technik, který se v zařízení vyzná, složitě volá někomu s přístupem, aby mu přečetl, co to má za problém, místo aby se podíval přímo - a nehorší na tom je, že to každému připadá normální.Vám to připadá normální?
Samozrejme zpristupnit takovy centralni bod do Internetu je jednodussi na IPv6 nez pres NAT na IPv4.I kdyz, pokud bude standardnim klientskym zarizenim na IPv6 router se stavovym firewallem (s cimz pocitaji nektere navrhy), tak ten rozdil uz zas takovy nebude.
Jsou to téměř na den dva roky, co jsem zde na abclinuxu napsal zápisek o IPv6 s provokativním názvem "IPv4 nefunguje! Ať žije IPv6". V době, kdy jsem svůj zápisek v blogu psal, jsem se ani nedokázal představit, jak budu jednou za IPv6 ještě vděčný.Jo to já teďka řeším, jak by správně měla fungovat autokonfigurace IPv6 v linuxovém kernelu a v NetworkManageru. Poslední jobovka spočívá v podpoře většího množství routerů, které můžou na síti fungovat nezávisle a dodávat klientům různé informace. V podstatě se tak ze záklaní konfigurace (bez DHCP) vytratil koncept: „Toto je můj server a teď mi dal konfigurační údaje, já je aplikuju a pak prohlásím spojení za nakonfigurované.“ Navíc je ta konfigurace tak vtipně jednoduchá, že už nemusím ani provádět ani útok na ARP, ani být včas na místě s DHCP serverem, ale prostě sousedovi pošlu routu :).
Jestli je něco, co mi na IPv4 opravdu vadí, pak je to NAT.A proto nemáme pro IPv6 implementováno „connection sharing“.
Takže prakticky to znamená, že ISP by měli dávat prefixy << /64 a "last hop" (nebo jak to říct) krabičky defaultně ty rozsahy přidělovat s adresami, aby to fungovalo podobně univerzálně jako NAT?Prakticky to znamená to, že by to fungovalo pouze v sítích, které počítají se sdílením spojení a mají z čeho rozdávat. Mě teda stále ještě láká to celé nějak vochcat přes bridge nebo ndp proxy, ale stále ještě platí, že IPv4 connection sharing je univerzálnější.
BTW má dhcp něco, čím klient řekne "chci rozsah"?O tom právě mluvím, DHCP toto umožňuje. Dostaneš tak informaci o naroutovaném rozsahu. Myslím, že to je jeden z důvodů, proč se počítá s kombinací PPP a DHCP, protože jinak PPP těch pár konfiguračních údajů taky pošle.
Mě teda stále ještě láká to celé nějak vochcat přes bridge nebo ndp proxy...No, po rychle uvaze mi na tom bridge neprijde nic zase tak spatneho. U NDP proxy si jiz nejsem tak jisty (vzniklo by imho vice problemu). Ale i tak mi oboje prijde minimalne jako "fallback" reseni dobre.
Dá se udělat bridge mezi PPP a ethernetem?Je pravda, ze jsem to jeste nikde nevidel (ja toho jeste nevidel ), ale technicky to lze realizovat.
A i tak, k čemu to bude, když od operátora přes PPP dostanu jednu IPv6 adresu?Pak nezbyva nez nasadit IPv6 NAT. Z pavlixova prispevku jsem usoudil, ze toto se bude tykat okrajovych pripadu u hrstky koncovych uzivatelu (napr. v internetove kavarne si chci "nasdilet" net pro moje bluetooth zarizeni) - tedy ne velkoplosnych, kritickych nasazeni, a proto bych se nebal ruznych "silenosti". Pochopitelne bych vsak mnohem radeji tlacil na ISP, aby se vubec nerozdavaly /64 prefixy, ale bez debat vetsi rozsahy (/56) a na pozadani /48 a vic, takze by se zodpovednost prenesla blize ke koncovemu uzivateli (treba na spravce site v kavarne ).
napr. v internetove kavarne si chci "nasdilet" net pro moje bluetooth zarizeniZajímalo by mě, jaký je právě „oficiální“ způsob pro takováto „ilegální“ použití, kdy chci, aby připojená zařízení mohla používat alespoň nějakou omezenou podmnožinu služeb na Internetu. IPv6 maškarádu nemáme, takže nějaká SOCKS proxy?
Že (no, spíš jestli) to půjde "technicky realizovat" je jedna věc. Bridge forwarduje L2 rámce - jak chcete ethernetové rámce mapovat na to, co běhá přes PPP? Neumím si představit, jak to bude v obvyklých scénářích fungovat - bez dalších pomocných nástrojů. Třeba už to, že na PPP není nic jako ARP, tak k čemu bude že to dám do bridge s ethernetem? Přes PPP dostanu 2 adresy - local a remote (v případě IPv4, jak je to definováno pro IPv6 přiznám se nevím) - a ta hromada ethernetových zařízení spojená přes bridge se nakonfiguruje jak? I když na PPP bude běžet nějaký mechanismus pro získání více adres, samotný bridge nic neřeší.Dá se udělat bridge mezi PPP a ethernetem?Je pravda, ze jsem to jeste nikde nevidel (ja toho jeste nevidel ), ale technicky to lze realizovat.
Bridge forwarduje L2 rámce - jak chcete ethernetové rámce mapovat na to, co běhá přes PPP?On by to nebyl bridge jako spis router s proxy ARP (resp. proxy NDP). Ve smeru do ethernetu by se ten stroj tvaril, jako ze ma i tu IP adresu druhe strany PPP linky (odpovidal by na prislusne ARP/NDP pozdavky), ve smeru k PPP neni co resit. Aby to fungovalo, tak by muselo byt korektni pro dany PPP klientsky endpoint pridelit vice IPv6 adres. Pokud by PPP linka mela /64 a adresy se pridelovaly router advertisementem (AFAIK PPP protokol sam pro IPv6 resi akorat link-local adresy), pak by snad slo vyuzit stejny postup s privacy extensions jaky zminuju vyse. Pokud by ta PPP linka vlastni prefix nemela a klientovi by se nejak pridelila /128 (coz mi prijde jako vcelku prirozeny postup, ale nevim, zda se toho nejak da bezne dosahnout), pak by asi nic moc nepomohlo.
...bez dalších pomocných nástrojů.Bez nich by to pochopitelne neslo (teda ja alespon o nicem takovem momentalne nevim - ale vsechna RFC fakt prectena nemam a mit nebudu).
Bridge forwarduje L2 rámce - jak chcete ethernetové rámce mapovat na to, co běhá přes PPP? Neumím si představit, jak to bude v obvyklých scénářích fungovat - bez dalších pomocných nástrojů. Třeba už to, že na PPP není nic jako ARP, tak k čemu bude že to dám do bridge s ethernetem?
On je PPP především (už podle názvu) point-to-point, takže logika toho rozhraní je úplně jiná. To, co uvádíte, jsou už jen důsledky. Nebo se stačí podívat do zdrojáků:
int br_add_if(struct net_bridge *br, struct net_device *dev) { struct net_bridge_port *p; int err = 0; bool changed_addr; /* Don't allow bridging non-ethernet like devices */ if ((dev->flags & IFF_LOOPBACK) || dev->type != ARPHRD_ETHER || dev->addr_len != ETH_ALEN || !is_valid_ether_addr(dev->dev_addr)) return -EINVAL;
static void ppp_setup(struct net_device *dev) { dev->netdev_ops = &ppp_netdev_ops; dev->hard_header_len = PPP_HDRLEN; dev->mtu = PPP_MRU; dev->addr_len = 0; dev->tx_queue_len = 3; dev->type = ARPHRD_PPP; dev->flags = IFF_POINTOPOINT | IFF_NOARP | IFF_MULTICAST; dev->features |= NETIF_F_NETNS_LOCAL; dev->priv_flags &= ~IFF_XMIT_DST_RELEASE; }
a nebo to prostě zkusit.
A dostat adresní rozsah na IPv6 je asi podobný problém jako se nadechnout v lese.Nevím. IPv4 jsem ukecal na /28, z IPv6 jsem si vyhradil jedno písmenko v první číslici, takže to vyšlo na /52. A kdyby to nešlo, pořád je tu sixxs s českým PoPem, což je takřka nerozlišitelné od nativní konektivity.
split-horizon DNS se používá a není to nic vyloženě špatnéhoTady bych úplně nesouhlasil, pokud nemáš namysli specificky to, že se část DNS pouze nezveřejní.
ani kolidujícího s DNSSECTak pokud se to celé podepíše, tak je všechno v pořádku, že.
ale je to holt opruz při nastavováníNenapadá mě rozumný setup, kdy se nejedná o celou samostatnou zónu.
Tady bych úplně nesouhlasil, pokud nemáš namysli specificky to, že se část DNS pouze nezveřejní.Ne, mám na mysli scénář, kdy světově přístupné servery musí být někde hluboko v privátní síti, pak mi jiné A záznamy vracené dovnitř a jiné ven (spolu s DNATem na hraničních routerech) přijdou jako nejčistší řešení.
pak mi jiné A záznamy vracené dovnitř a jiné ven (spolu s DNATem na hraničních routerech) přijdou jako nejčistší řešení.Mě to jako čisté řešení nepřijde vůbec a hlavně hlavně mi to připadá úplně zbytečné.
DNS informace by musely být vevnitř sítě jiné, než venku.Přesně tak jsem to myslel.
... DNS informace se mohou na počítači kešovat (tj. počítač se nezeptá a sáhne do vlastní paměti) ...Hmm, to by asi byl problém. Mno, ipv6 je lepší
Ale IPv6 nepotřebujeme, k čemu je koncákovi veřejná IP?
Ale IPv6 nepotřebujeme, k čemu je koncákovi veřejná IP?Mě asi cyp střelí. Tak já se tady celé roky snažím, vysvětluju proč je špat natně, proč koncový uživatel potřebuje veřejnou ip adresu stejně jako server, a on pak kdosi přijde a poví "K čemu ja koncákovi veřejná IP?" Ať už máte připojenou domácnost, nebo celou firmu, prakticky všichni ISP vás tlačí do pozice koncáka a je nadlidský úkol jim vysvětlit, že tu statickou veřejnou IP adresu (aspoň jednu!) vážně potřebuju a neobejdu se bez ní (O2) a že platit za IPv6 stovku měsíčně je vydřidušství (O2). Pro dalšího ISP jsem sice dost veliký na to, aby moje požadavky na IPv6 bral dostatečně vážně (T-Mobile), ale "teď ještě ne". Požádat o stovku IPv4 ani nezkouším: "Proč si ty elektrárny nepronatujete, to jich máte fakt tolik?". Bez IPv6 jsme v očích ISP všichni jen "koncáky", se kterými se na téma IP adres nemá smysl bavit. Dokud nebude mít veřejnou adresu každé zařízení běžné koncové síti, budeme těmi koncáky všichni a budeme škemrat o přístup na internet. Bez vlastní IP adresy budete vždy odkázaný na služby někoho jiného a odnese to telefonování, šifrování, hraní přes internet a spousta dalších aktivit, které zatím třeba ani vůbec nevznikly, protože všichni jsou obyčejnými "koncáky".
modprobe irony(to fakt nebylo ze začátku komentáře poznat?)
tu statickou veřejnou IP adresu (aspoň jednu!) vážně potřebuju a neobejdu se bez ní (O2) a že platit za IPv6 stovku měsíčně je vydřidušství (O2).O2 poskytuje IPv6 zdarma, platí se jen za statické čtyřky, ne?
ja nevim, mi pripada, ze tu nekdo objevil VPN ;)
považují za ortogonální.Tohle ortogonální je Lennartismus, nebo to pochází z Gnome?
zkus si představit jaké by to bylo kdybys nemusel složitě konfigurovat VPNky a stačilo jen říct, že odsud posud je to spojení šifrované.+1 (akorát s/šifrované/zabezpečené/)
NAT není bezpečnostní opatření. Pravidlo pro NAT vypadá ve firewallu takto:
iptables -t nat -A POSTROUTING -o eth_venkovni -j SNAT --to $IP_VENKOVNI
Toto pravidlo mění obsah paketů putujících ven, ale pakety nikam nezahazuje, normálně je propouští.
Bezpečnostním opatřením, které má schopnost chránit vnitřní síť, je pravidlo
iptables -A FORWARD -i eth_venkovni -o eth_vnitrni -j DROP
kteréžto pravidlo by mělo být na firewallu vždy nějakým způsobem zastoupeno, s NATem však nijak nesouvisí.
V IPv6 se nevytváří NAT, špinavá pracka nenechavého NATu pakety nijak nemění. Zůstává pouze pravidlo
ip6tables -A FORWARD -i eth_venkovni -o eth_vnitrni -j DROP
které funguje úplně stejně jako v IPv4.
Kde tam vidíte nějaké bezpečnostní hledisko NATu?
NAT nemá s bezpečností nic společného, asi se "security by obscurity". Mám si toho idiota vzít osobně, a přidat ještě jeden příspěvek osobnějšího rázu?
NAT není bezpečnostní opatření.To je sice pěkné, ale defakto jako bezpečnostní opatření funguje. Nebo mi napište jak pingnete počítač za děravým natem(masquerade,forward-accept) na nějaké veřejné adrese, z jiné své veřejné adresy.
tava:~# ip r a deka/32 via deravynat dev eth0 tava:~# ping deka -- deka:~# tcpdump -i eth0 icmp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 25:65:54.520197 IP tava > deka: ICMP echo request, id 7246, seq 11, length 64?
Mozna jsem neco prehlednul, ale pokud "deka" bude z privatnich rozsahu, tak ti tyhle pakety hnedka prvni router po ceste zahodi.
<nadsázka>
Ono to někdy ani nemusí vadit. Konkurence, která mě nejvíce štve, má kanceláře hned vedle a máme společného ISP. Konkurenční firma ze sousedního města mi už na paty tolik nešlape, ale taky máme společného lokálního ISP. Konkurence z okresního města je mi ukradená.
S klukama od ISP chodím na pivo. Myslím, že kdy jim jednoho kouska zaplatím, ještě v hospodě mi pomůžou se ke konkurentovi nabourat.
</nadsázka>
Mozna jsem neco prehlednul, ale pokud "deka" bude z privatnich rozsahu, tak ti tyhle pakety hnedka prvni router po ceste zahodi.
Pokud tam vůbec nějaký "po cestě" bude. Pokud se k tomu poslednímu nebude schopen dostat a nikdo, kdo se k němu dostane, mu nebude ochoten pomoci. Pokud nebude povolen source routing. Pokud… Na můj vkus je těch "pokud" trochu moc na to, abych na tom stavěl zabezpečení své sítě.
a ze jich tam muze byt dost, pokud vezmu v uvahu 10.0.0.0/8 nebo i jine rozsahy
Už jsem různých domácích a malých firemních sítí viděl dost a moje zkušenost je taková, že pokud by těch, kdo nepoužívají 10.0.0.0/24, 10.10.10.0/24, 192.168.0.0/24, 192.168.1.0/24 nebo 192.168.2.0/24 bylo více než pět procent, bylo by to pro mne ohromným překvapením. Občas navíc ta adresa prosákne někde v protokolech aplikační vrstvy (namátkou SMTP nebo HTTP).
ktere nejsou privatni, ale cil je v LAN muze pouzivat, pokud bude NAT dobre nakonfigurovany a prelozi je vsechny
To by musel být zatraceně dobře nakonfigurovaný NAT, aby poznal, jestli má paket s cílovou adresou X poslat na stroj s adresou X v lokální síti nebo na stroj s adresou X na druhém konci světa. Tím spíš, že se k němu ten paket obvykle ani nedostane.
Na můj vkus je těch "pokud" trochu moc na to, abych na tom stavěl zabezpečení své sítě.Netvrdil jsem, ze to je bezpecne, nybrz, ze neni tak jednoduche se dovnitr dostat.
Občas navíc ta adresa prosákne někde v protokolech aplikační vrstvy (namátkou SMTP nebo HTTP).Zde predpokladate, ze jste vlastne MiM a nebo strasne blizko stanice, na kterou utocite (ale treba SIP by opravdu prozradil co a jak). Tedy ne pripad, ktery uvedl diskutujici vyse - jsem nekde na svete, mam pouze verejnou adresu cile a chci pingnout nejake stanice uvnitr, o kterych nevim vubec nic.
To by musel být zatraceně dobře nakonfigurovaný NAT, aby poznal, jestli má paket s cílovou adresou X poslat na stroj s adresou X v lokální síti nebo na stroj s adresou X na druhém konci světa. Tím spíš, že se k němu ten paket obvykle ani nedostane.Tohle nejak nechapu. NAT/PAT prelozi vsechno podle tabulky, do ktere to mohu narvat dynamicky (pool nebo porty) a nebo rucne a nebo kombinaci predeslych. NATu je uplne jedno co preklada.
Netvrdil jsem, ze to je bezpecne, nybrz, ze neni tak jednoduche se dovnitr dostat.
A to vám jako správci sítě stačí? Já jsem třeba ochoten smířit se s rizikem, že útočník uhodne 128-bitový klíč k AESu, ale s tímhle rozhodně ne.
Zde predpokladate, ze jste vlastne MiM a nebo strasne blizko stanice, na kterou utocite (ale treba SIP by opravdu prozradil co a jak).
Ne. Já nejsem útočník, který se za každou cenu potřebuje dostat do konkrétní sítě. Já jsem správce sítě, který zvažuje rizika konkrétních modelů útoku. A tohle riziko je pro mne příliš velké, abych nad ním dokázal mávnout rukou.
Tohle nejak nechapu. NAT/PAT prelozi vsechno podle tabulky, do ktere to mohu narvat dynamicky (pool nebo porty) a nebo rucne a nebo kombinaci predeslych. NATu je uplne jedno co preklada.
Uvažujme situaci, kdy ve své maškarádované síti použijete rozsah, který není pro tyto účely rezerovavaný (tj. ne podrozsah 10.0.0.0/8, 172.16.0.0/12 nebo 192.168.0.0/16) a který není rezervovaný ani pro jiné účely (třeba multicast, což by zase vedlo k jiným problémům). Pak musíte počítat s tím, že nastane situace, kdy některý počítač ve vaší síti bude mít aresu X stejnou jako nějaký počítač kdesi venku. Jestliže pak pošlete z jiného počítače ve své síti paket na adresu X, jak si představujete, že NAT-box pozná, jestli má paket odmaškarádovat a poslat ven nebo ho bez maškarády poslat na ten stroj uvnitř? Nemluvě o tom, že se ten paket ve většině případů na NAT-box vůbec nedostane, protože půjde k lokálnímu stroji přímo nebo přes jiný router.
A to vám jako správci sítě stačí?Samozrejme nestaci, reagoval jsem na Jendu - myslim si, ze v realu to fakt v 95% pripadu takhle jednoduse nepujde.
...abych nad ním dokázal mávnout rukou.Tak to kazdopadne. Proste se nejedna o zabezpeceni.
Uvažujme situaci,...Ano, presne tak. Tedy z vnitrni site ho router naroutuje zase do vnitrni site (prelozi a pak routuje diky existenci specifictejsi routy). Z globalni site ten paket pobezi ke skutecnemu cili, a tedy utocnik ma smulu.
Ano, presne tak. Tedy z vnitrni site ho router naroutuje zase do vnitrni site (prelozi a pak routuje diky existenci specifictejsi routy). Z globalni site ten paket pobezi ke skutecnemu cili, a tedy utocnik ma smulu.
Ale v tomhle odstavci přece vůbec nešlo o nějakou bezpečnost nebo útoky. Tady jde o prostou (ne)funkčnost způsobenou tím, že nebude u paketu (zevnitř) jasné, na který z těch dvou strojů se stejnou adresou by se měl routovat. Právě proto existují rezervované rozsahy, u kterých máte jistotu, že na Internetu nikomu přiděleny nebudou.
Mozna jsem neco prehlednul, ale pokud "deka" bude z privatnich rozsahu, tak ti tyhle pakety hnedka prvni router po ceste zahodi.Takže bezpečnost je postavená na doufání, že to někdo po cestě zahodí. Ale co když jsem u stejného ISP hned vedle nebo v racku vedle?
A utocit na souseda mi prijde detinske :-)
Pak nezbývá než doufat, že sousedovi taky. :-)
Já bych to schoval za nat, už jen z bezpečnostního hlediska. A ten kdo sem napíše "security by obscurity" je idiot.Že je NAT bezpečností opatření je nesmysl už z principu. To by totiž znamenalo, že když NAT vypneš, snížíš tím bezpečnost. A já ti garantuju, že bezpečnost proti útokům zvenčí vypnutím NATu jednoznačně zvýšíš.
úplně nový internetPodle nadpisu jsem čekal trochu víc, než jen že IPv6 je hodně IP adres a není potřeba NAT… nechceš se aspoň trochu rozepsat o tom přístroji na fotce?
absurdní představa.co oci nevidi to srdce neboli
zahazuje všechny ty složité a náročné technologie, které z nich dělají odborníkyPopravdě řečeno lidí, kteří jsou zároveň dostatečnými odborníky na to, aby rozuměl NATu a jeho praktickým důsledkům, a zároveň jsou krvavými odpůrco IPv6, asi tak moc nebude. U mě si lidi zvykli, že IPv6 podporuju a prosazuju (i když ne bez výhrad). Ale když má někdo problém s NATem, tak komu volá, že?
ale průser je náš zkorumpovaný dotační systém, ne fotovoltaika.+1
<sip:UŽIVATEL@IP_ADRESA>
.
Tiskni Sdílej: