Ticket #387 (new)

Opened 9 years ago

Last modified 5 years ago

Vidnost zunanjih IP številk točk

Reported by: stefanb Owned by: kostko
Priority: major Milestone: Next milestone
Component: nodewatcher/core Version:
Keywords: Cc:
Related nodes: Realization state:
Blocking: Effort: normal
Blocked by: Security sensitive: no

Description

Skrbnike točk bi pogosto zanimala IP številka v gostujočem LANu, da se lahko povežejo nanjo (#382)

Prav tako bi znala za stabilnost omrežja biti zanimiva IP številka s katere točka vzpostavi VPN tunel do VPN strežnika. S tem bi lahko ugotovili katere ISPje vse uporablja omrežje in koliko jih mora odpovedati, da bi omrežje razpadlo. To bi lahko bilo objavljeno zamaskirano v obliki "X.Y.*.*", da se vidi ISP, ne pa konkretnega naročnikovega IPja.

Change History

comment:1 Changed 9 years ago by stefanb

Možnost je pa tudi, da skrbnik točke ob njen vpiše podatke o WAN priklopu (ime ISPja, hitrost...)

comment:2 Changed 9 years ago by stefanb

  • Owner set to kostko
  • Component changed from ostalo to baza točk

comment:3 Changed 9 years ago by mitar

  • Summary changed from Vidnost zunanjih IP številke točk to Vidnost zunanjih IP številk točk

Meni se zdi bolje, da avtomatiziramo čimveč lahko. Torej bi v tem primeru raje naredil, da se preko whoisa dobi podatek, komu pripada IP naslov. Ne bi nič maskirali ali kaj, oziroma sploh ne bi objavljali zunanjega IP naslova (razen za skrbnike točk, kjer bi pa ga prikazali polnega).

comment:4 Changed 9 years ago by mitar

  • Milestone set to 3.0b

comment:5 follow-up: ↓ 7 Changed 9 years ago by stefanb

Preden se točka prvič priklopi na VPN strežnik ISP ne bo znan, kar bi lahko otežilo kako odločitev pri načrtovanju omrežja oz. odločanju v katere točke osredotočiti napore (v grozdu točk z več povezavami prek ISPja A je ena točka prek ISPja B lahko precej bolj dragocena od dodatne prek A).

Poleg imena ISPja je pomemben tudi način priklopa (FTTH/kabelska/ADSL/VDSL/UMTS...), ker isti ISP lahko ponuja več načinov priklopa, ki lahko izpadajo neodvisno. Arnes pa je včasih ponujal dostop (v svojem IP range-u?) prek različnih ISPjev, a ne vem če je temu še tako.

Novim/pending točkam bi bilo dobro ročno nastaviti ta podatek (oz. tudi če točka sploh predvideva VPN uplink).

Mogoče bi morali upoštevati tudi kar celoten traceroute po katerih se vzpostavi VPN povezava, če kak router na poti crkne :)

Nekatera gostiteljska omrežja (predvsem v podjetjih) imajo lahko že sama po sebi priklop na več ISPjev (dual WAN). Točke (firmware-a) to načeloma ne zanima, ker za load balancing ali failover skrbi gostujoče omrežje. No, zaenkrat mislim da takih točk še nimamo v našem omrežju.

comment:6 follow-up: ↓ 8 Changed 9 years ago by stefanb

V bistvu mi je ideja s traceroute, kjer bi avtomatsko vpisali vsak router na poti v bazo zmeraj bolj všeč. Na grafu topologije bi tak routerje predstavili kot male sive krogce, skozi katere bi se združevale VPN povezave do VPN strežnikov.

V primeru da sta neki točki na istem ISPju, ki pa ima recimo težave s povezavo naprej bi se točki lahko peerali (žično, z VPNom) med seboj. Če le ena od njiju vidi kako drugo točko (na drugem, delujočem ISPju) bi prek nje obe lahko bili povezani s celotnim omrežjem. Težava ostane da se dogovorita katera točka bo VPN strežnik in kako odpirati porte do nje skozi gostiteljska omrežja.

comment:7 in reply to: ↑ 5 Changed 9 years ago by mitar

Replying to stefanb:

Preden se točka prvič priklopi na VPN strežnik ISP ne bo znan, kar bi lahko otežilo kako odločitev pri načrtovanju omrežja oz. odločanju v katere točke osredotočiti napore (v grozdu točk z več povezavami prek ISPja A je ena točka prek ISPja B lahko precej bolj dragocena od dodatne prek A).

Ne razumem tega. Če pri pregledu točk okoli sebe vidiš, da so vse točke na nekem ISP in imaš ti drugega (verjetno veš pri katerem si), potem pač veš, da lahko tvoja točka prispeva k raznolikosti. Ravno to, da se izpisujejo imena IPSjev (in ne IP) pomaga pri lažjemu načrtovanju omrežja.

Poleg imena ISPja je pomemben tudi način priklopa (FTTH/kabelska/ADSL/VDSL/UMTS...), ker isti ISP lahko ponuja več načinov priklopa, ki lahko izpadajo neodvisno. Arnes pa je včasih ponujal dostop (v svojem IP range-u?) prek različnih ISPjev, a ne vem če je temu še tako.

To je dobra ideja, da se doda kot možnost. Ampak lahko pa tudi hitro zastara, če se ne vzdržuje. Torej razen lokacije so drugi podatki večinoma vsi avtomatsko pridobljeni. Bilo bi super, če bi znali dobiti tudi način priklopa avtomatsko.

Novim/pending točkam bi bilo dobro ročno nastaviti ta podatek (oz. tudi če točka sploh predvideva VPN uplink).

To, če predvideva VPN uplink se vidi iz tega, če ga ima omogočenega v konfiguraciji. :-)

Torej jaz bi rad čimveč stvari pridobival avtomatsko oziroma posredno iz nastavitev.

Mogoče bi morali upoštevati tudi kar celoten traceroute po katerih se vzpostavi VPN povezava, če kak router na poti crkne :)

Ampak ali misliš, da bi to res zbirali centralno na strežniku? Ni to nekaj, kar je boljše pogledati potem direktno na točki? Ker orodij za analizo povezav je veliko, traceroute tudi ne deluje povsod ...

comment:8 in reply to: ↑ 6 Changed 9 years ago by mitar

Replying to stefanb:

V bistvu mi je ideja s traceroute, kjer bi avtomatsko vpisali vsak router na poti v bazo zmeraj bolj všeč. Na grafu topologije bi tak routerje predstavili kot male sive krogce, skozi katere bi se združevale VPN povezave do VPN strežnikov.

Simpatična ideja. Samo jaz sem res zelo skeptičen do tega, da se interna topologija omrežij, kamor je priklopljena točka, sporoča kamorkoli navzven.

Mogoče bi bil sprejemljiv kompromis ta, da se v poročilu preskoči vse interne IP range in prvi zunanji IP.

Aja, seveda bi bilo boljše, če bi to izvajal kar VPN srežnik. Torej da dela traceroute do zunanjega IPja točke in uporabi vse podatke razen zunanjega IPja točke. Torej interno ve kaj je zunanji IP točke, iz njega lahko dobi ISP točke in naredi traceroute do točke in naredi potem ta združevanja točk glede na topologijo Interneta.

V primeru da sta neki točki na istem ISPju, ki pa ima recimo težave s povezavo naprej bi se točki lahko peerali (žično, z VPNom) med seboj. Če le ena od njiju vidi kako drugo točko (na drugem, delujočem ISPju) bi prek nje obe lahko bili povezani s celotnim omrežjem. Težava ostane da se dogovorita katera točka bo VPN strežnik in kako odpirati porte do nje skozi gostiteljska omrežja.

OK, tega jaz ne bi delal na roke. Namreč to bi naj znal delati CloudVPN sam.

Torej se lahko loči monitoring (sporočanje tracerouta in prikazovanje topologije) od tega, da se točke poskušajo med seboj povezati na čimbolj robusten način (WiFi, VPN?).

Last edited 5 years ago by mitar (previous) (diff)

comment:9 Changed 8 years ago by mitar

  • Milestone changed from 3.0b to Next milestone

comment:10 Changed 5 years ago by mitar

Of course we should understand that IPs could be a pretty sensitive information. It is a privacy issue and we might not want to collect them in the first place. So we have to see what are advantages and disadvantages here.

Note: See TracTickets for help on using tickets.