Příspěvky

166

/dev/null / Re:Je to plnohodnotná veřejná adresa?

« kdy: 20. 04. 2021, 16:15:12 »

„Veřejná IP adresa“ je služba poskytovaná ISP svému zákazníkovi, která umožňuje skrze internetové připojení poskytované ISP přístup k internetovým službám definovaným zákazníkem a provozovaným na zařízení zákazníka, přičemž přístup je realizován na základě statické globálně routovatelné IPv4 adresy.

Do téhle definice se nevejde například dynamická veřejná IPv4 adresa poskytovaná na síti exUPC. Musí být veřejná adresa vždy statická? Pokud ano, proč?
Do téhle definice se nevejde ani ono opakovaně zmiňované nastavování rDNS.

Chápete rozdíl mezi poskytovatelem a zákazníkem? Jste schopen pochopit, že požadovaný provoz definuje zákazník a poskytovatel na to reaguje tím, zda danou službu umí či neumí poskytnout, případně za jakých podmínek (např. ceny)?

Zákazník (správně) definuje požadovaný provoz a tedy i poptávanou službu, ale poskytovatel není povinen takovou službu poskytnout. Je to ISP, který určuje podobu jím nabízené služby (nebo služeb, pokud je variant víc) "veřejná IP adresa".

Pro jistotu rovnou připomínám, že to neznamená, že ISP musí být schopen poskytnout jakoukoli službu definovanou zákazníkem, ale musí být schopen poskytnout alespoň nějakou takovou službu. Podobně jako když nabízí službu připojení k internetu – neznamená to, že vás připojí kdekoli, ale že vás připojí alespoň někde.

Kam spadá "ISP", který neposkytuje ani jednu z variant služby "veřejná IP adresa"? (I takoví existují.)

167

/dev/null / Re:Je to plnohodnotná veřejná adresa?

« kdy: 19. 04. 2021, 21:30:15 »

Pan Silhavy to napsal pekne.
Snad jen bych dodal, ze ja nerikam, jestli je nejaka "verejna IP adresa" ta spravna nebo nespravna. Rikam, jake sluzby se realne nabizeji.

Je mozne a bezne, ze se zakaznik a ISP nedokazou dohodnout, a pak zakaznik odchazi k ISP, kde takovou sluzbu "verejna IP adresa", kterou pozaduje, i dostane. Pokud takoveho ISP najde a pozadovanou sluzbu zaplati.

V pripade obskurniho zarizeni bez podpory classless adresovani preji hodne stesti pri hledani, nebot vetsina ISP takove adresy (souvisly blok /24 z pridelu 192.0.0.0/3) vubec nema prirazene, natoz aby je mela souvisle na jednom L2 segmentu bez dalsiho rozdrobeni. V kombinaci s pozadavkem na prenositelnost mezi ISP Vam uz nebude zbyvat nic nez koupit takovy PI/PA blok adres od nekoho, kdo se ho bude zbavovat. Pokud vubec nekdo takovy existuje. Nasledne se s ISP domluvit na oznamovani prefixu v BGP a nalezitem smerovani.

168

/dev/null / Re:Je to plnohodnotná veřejná adresa?

« kdy: 19. 04. 2021, 18:57:25 »

Jaká náhodná omezení? 

To nejsou žádná náhodná omezení. To je popis reálných služeb.

Neznám jediného ISP, který by klientům nabízel veřejnou IP adresu a myslel tím něco jiného než NAT 1:1 nebo naroutovanou adresu nebo blok adres (jakýmkoli způsobem).

169

/dev/null / Re:Je to plnohodnotná veřejná adresa?

« kdy: 19. 04. 2021, 16:53:57 »

Tady se to nějak rozjelo.

Při veřejné adrese routované do PPPoE tunelu, při routované veřejné adrese (jedné nebo celém bloku) ani při "veřejné adrese" v režimu NAT 1:1 mi nikdo nikde nikdy negarantuje, že si budu moct nastavit reverzní DNS.

Služba "veřejná adresa" taky neimplikuje možnost přenosu té adresy k jinému ISP. To umožňuje až PI blok adres, které se na IPv4 v Evropě už od vyčerpání adres (2012) nepřidělují.

Naopak úplně běžné je v cenících ISP pro rezidentní zákazníky vidět položku:
- veřejná IPv4 adresa v režimu NAT 1:1
- veřejná routovaná IPv4 adresa (jestli je to /32 pomocí PPPoE, /32 pomocí routování jedné adresy a router to tedy musí umět, nebo veřejná adresa přidělená z většího bloku, např. /26, /27, to ceník neřeší a nemůže - od toho jsou technické podmínky)
Někteří ISP si dokonce nechávají zaplatit i za založení a (měsíční) vedení toho rDNS záznamu.

Jste-li business zákazníci, pak obvykle máte k dispozici (a platíte za) blok routovaných veřejných IPv4 adres (/30, /29, /28, /27, ...).

A jelikož je Internet založen na peer to peer konektivitě, implicitní (a správný) předpoklad je, že ISP nefiltruje žádné služby (ledaže by za omezení mohla technologická povaha zvolené realizace služby, např. IPSec ESP/AH se službou realizovanou pomocí NAT 1:1 asi nebude úplně kamarád)...

Zpřístupnění služeb na vybraných portech po žádosti k ISP, nebo dokonce STUN, za službu "veřejná IPv4 adresa" snad nemůže považovat nikdo.

170

Hardware / Re:Vzdálené ovládání PC přes Intel AMT

« kdy: 12. 04. 2021, 15:49:27 »

Tak pokud ta deska skutecne KVM nepodporuje, porad muzete presmerovat vystupy kernelu na seriovou konzoli a stejne tak seriovou konzoli pouzit pro prihlasovani na server, a z Mesh commanderu ji pak ovladat pres SOL. Neni to uplne ekvivalentni KVM, nefunguje to pro graficky rezim, ale mozna by to mohlo poslouzit pro vzdalenou spravu, pokud selze SSH atp.

171

Hardware / Re:Vzdálené ovládání PC přes Intel AMT

« kdy: 12. 04. 2021, 10:23:38 »

Hmm, to vypadá, že tahle konkrétní kombinace AMT firmwaru/desky/CPU/grafiky nepodporuje KVM.

Nemáte tam náhodou nějakou externí grafickou kartu v PCIe? Podle https://www.jetwayipc.com/product/jnf796-q370/ by deska měla podporovat Intel HD Graphics, tedy grafiku v CPU, s čímž by AMT fungovat mělo.

172

Hardware / Re:Vzdálené ovládání PC přes Intel AMT

« kdy: 06. 04. 2021, 12:35:57 »

Ještě k Active features: to je v Mesh Commanderu v sekci System status, na řádek se seznam featur stačí kliknout a pak se objeví seznam checkboxů s povolenými features (já tam mám Redirection Port, KVM Remote Desktop, IDE-Redirection, Serial-over-LAN).

V sekci System status je ještě dobré zkontrolovat User consent (má být nastaveno na "Not required").

173

Hardware / Re:Vzdálené ovládání PC přes Intel AMT

« kdy: 06. 04. 2021, 12:06:28 »

Ještě zkratky:
SOL = Serial over LAN
Remote storage = připojení ISO jako CD
KVM = to, co vy spíš hledáte (Remote Desktop).

174

Hardware / Re:Vzdálené ovládání PC přes Intel AMT

« kdy: 06. 04. 2021, 11:59:19 »

No pozor, Serial-over-LAN dělá to, co to podle názvu naznačuje. Výstup ze sériového portu to přeposílá po síti, vstup ze síťového ovládání to přeposílá do sériového portu.
Pokud nemáte v bootloaderu/Linuxu podporu ovládání skrze sériovou konzoli (v grubu, kernelu, resp. getty - návod je např. na https://wiki.archlinux.org/index.php/working_with_the_serial_console), tak po připojení skutečně nic neuvidíte.

Jen "Remote Desktop" zobrazuje obsah obrazovky (tj. to, co vidíte na připojeném monitoru). A ten Remote Desktop je potřeba povolit.


Návod na povolení "SOL/Storage Redirection/KVM" (může se lišit podle verze AMT) je např. na
https://us.dfi.com/Uploads/DownloadCenter/67e0b69e-f55d-403c-89e1-71d648801cdd/DFI-EC70A-SU-Embedded-System-Manual.pdf?timestamp=1510537884.32584
(stránky 60-61)

175

Hardware / Re:Vzdálené ovládání PC přes Intel AMT

« kdy: 05. 04. 2021, 19:54:39 »

Na tech screenshotech z Mesh Commanderu uplne chybi Remote control. Je to v AMT preboot prostredi povolene?

176

Sítě / Re:Google Play nefunguje po IPv6

« kdy: 02. 04. 2021, 12:13:24 »

Asi neviem citat, protoze z konfigurace z neznameho prvku (proc autor nenapsal, co je to za switch a za OS?) neni uplne jasne, jestli je SLAAC skutecne funkcni, a dump z wiresharku tu neni. Z textu taky jednoznacne nevyplyva, ze "ostatni" funguje - jedna se o aplikace nebo o webove stranky?

Zaroven neni jasne, jestli se jedna o stranku play.google.com v browseru (jaky browser? Je to chrome v androidu nebo nativni browser? Ve starsich verzich Androidu to byly dve ruzne veci) nebo o aplikaci Google Play.

Jak jsem psal, v puvodnim prispevku je prilis malo informaci.

Chtelo by to tcpdump s ukazkou RA a idealne i pripojeni k Google Play z browseru a z aplikace.

177

Sítě / Re:Google Play nefunguje po IPv6

« kdy: 02. 04. 2021, 08:58:34 »

A jeste neco - jaky Android (verze) a na jakem zarizeni?
Funguje IPv6 na dualstackovane siti?

Napriklad jeden levny tablet od Vodafone vubec IPv6 nepodporoval.

178

Sítě / Re:Google Play nefunguje po IPv6

« kdy: 01. 04. 2021, 19:49:46 »

Malo informaci.

Android nepodporuje DHCPv6. Ani pro pridelovani adres, ani pro pridelovani DNS. Z konfigurace neni uplne jasne, jestli je v siti povolena autokonfigurace metodou SLAAC - DNS v router advertisementech asi posilate, ale samo o sobe to nestaci. Ukazte wireshark dump nejakeho router advertisementu.

Je dobre mozne, ze nejaky cil je IPv4-only. Z te konfigurace switche neni jasne, jestli je LAN IPv6-only, nebo dual-stackovana. Pokud IPv6-only, mozna by pomohlo nasadit DNS64/NAT64. Google Public DNS podporuje i DNS64, pokud pouzivate standardni prefix 64:ff9b::/96 - https://developers.google.com/speed/public-dns/docs/dns64

Nenapsal jste, jake je to pripojeni - je to nativni IPv6 konektivita? Je v ceste nejaky tunel (napr. PPPoE)? V nastaveni switche nevidim nastaveni MTU. MTU jine nez 1500 pritom muze byt pro nektere sluzby dost velky problem.

179

Hardware / Re:Vzdálené ovládání PC přes Intel AMT

« kdy: 30. 03. 2021, 21:37:45 »

Tak jsem vyzkoušel instalaci v Linuxu pomocí NPM. Je to teda NPM hell...

Kód: [Vybrat]

$ mkdir meshcommander
$ cd meshcommander/
$ npm init # pojmenujte projekt jinak nez meshcommander
$ npm install meshcommander 
$ node node_modules/meshcommander/
MeshCommander running on http://127.0.0.1:3000.

A následně v browseru otevřít http://127.0.0.1:3000, přidat počítač a připojit se - a Remote desktop po Connectu funguje na první dobrou.

180

Hardware / Re:Vzdálené ovládání PC přes Intel AMT

« kdy: 29. 03. 2021, 08:06:42 »

Jojo, ale to muze byt konkretni signalizace na konkretni verzi AMT. A je jedno, jestli mam nabootovany Linux nebo jeste bootuje UEFI. Blikajici signalizaci tam mam porad.

Jinak Mesh Commander provozuju na Macu, na Linuxu jsem ho zatim nezkousel. Vyzkousim.