Archiv pro štítek: sítě

Realizováno! Svařování optických vláken SBS-NEPRON s.r.o. Kaznějov

Svařování optických vláken SBS-NEPRON


Společnost SBS-NEPRON s.r.o. jako součást německé skupiny BurgerGruppe Schonach je zaměřena na montáž elektronických modulů s roční kapacitou 250 milionů osazených součástek a v současné době v lokalitě Kaznějov u Plzně zaměstnává přes dvě stovky lidí.

V rámci rozšiřování společnosti do nové výrobní haly jsme provedli realizaci optické sítě, osazení optických van, kazet, zavaření a uložení optických vláken, děkujeme za čistou a bezproblémovou spolupráci.


 

svarovani-optickych-vlaken-SNSNEPRON-Plzen-4-2017-1600px svarovani-optickych-vlaken-SNSNEPRON-Plzen-1-2017-1600px svarovani-optickych-vlaken-SNSNEPRON-Plzen-3-2017-1600px

Děkujeme za příležitost a těšíme se na další spolupráci.
MOJEservery.cz

Potřebujete realizovat optické sítě ? 
Disponuje vlastní optickou plně automatickou 3D svářečkou.
Optické sítě, svařování optických vláken.
Kontaktujte nás.
Kontaktní e-mail: podpora@mojeservery.cz
Kontaktní telefon: +420 725 714 669

Nabízíme Vám svařování optických vláken
- budování, servis, údržba optických sítí
- svařování optických vláken (kabelů)
- kompletní příprava, svaření, uložení vláken
- svařování multimode (MM), mnohavidová vlákna
- svařování singlemode (SM), jednovidová vlákna
- svařování v terénu (až 200 sváru na baterii)
- množstevní slevy
- disponujeme moderní svářečkou INNO
- průměrný vložný útlum sváru 0.02 dB
- instalační materiál pigtaily, spojky, optické i metal. rozvaděče skladem

Mikrotik mini-howto: Hlavní a záložní zavaděč RouterBOOT

Mikrotik mini-howto?
Krátce ze života sysadmina s RouterOS.

Hlavní a záložní zavaděč RouterBOOT


Zavaděč (bootloader) RouterBOOT je v zařízeních značky Routerboard software (firmware, kód) zodpovědný za inicializaci hardware po sepnutí napájení, vyhledání dostupného úložiště (NAND flash) a následné načtení operačního systému RouterOS do paměti a předání mu řízení. Pokračování textu Mikrotik mini-howto: Hlavní a záložní zavaděč RouterBOOT

Mikrotik mini-howto: EoIP a šifrování s IPsec

Mikrotik mini-howto?
Krátce ze života sysadmina s RouterOS.

EoIP a šifrování s ipsec

Proprietární EoIP protokol Mikrotiku pro tunelování L2 provozu je na systému RouterOS velmi populární zejména pro svojí velmi snadnou konfiguraci, prakticky přidáte pouze na každé stráně (zařízení) remote-address a shodné tunnel-id a můžete začít tunelovat, jednoduché, nekomplikované.

Článek: 
Jak funguje EoIP a je možný proti Linux serveru ?
www.mojeservery.cz/linux-eoip-tunel-proti-mikrotik/

Jednou z nevýhod EoIP je nešifrovaný provoz, přirozeně je možné zabalit celý provoz a transparetně šifrovat oba konce přes IPsec, který je podporován v Mikrotiku, bohužel většina administrátorů tuto konfiguraci neřeší, mají k IPsecu “odpor”, vetšinou z důvodu neznalosti jeho problematiky, lidé se bojí toho co neznají.

Proto Mikrotik přidal podporu šifrování do EoIP skrze IPsec (dle informací k 15. výročí protokolu), a to tak snadno, že pouze vyplníte ipsec-secret (pre-shared key, heslo, ideálně netriviální), Mikrotik následně sám nakonfiguruje dynamické ipsec peery (strany tunnelu), nakonfiguruje policy s výchozím šifrováním na sha1/aes128cbc, hotovo a máte šifrováný L2 tunnel, jednodušší už to nebude, takže šifrujte !

Ukázka konfigurace EoIP s IPsec

Používáme RouterOS version: 6.37.1 (stable)

Pozn.:
IPsec u EoIP potřebuje explicitně specifikovat local-address u EoIP tunelu kvůli konfiguraci ipsec peerů a také vypnout fastpath funkcionalitu jinak není možné IPsec povolit na EoIP.

Příklad síťové topologie:

mikrotik-minihowto-eoip-ipsec-2016

Konfigurace:

Router R1:
/interface eoip add name="EOIP-R2" local-address=1.1.1.2 remote-address=2.2.2.2 tunnel-id=10 allow-fast-path=no ipsec-secret=ozCafWutIvFikamNekUlhedeipdobus5
Router R2:
/interface eoip add name="EOIP-R1" local-address=2.2.2.2 remote-address=1.1.1.2 tunnel-id=10 allow-fast-path=no ipsec-secret=ozCafWutIvFikamNekUlhedeipdobus5

A to je vše, snadné, tak šifrujte !

Děkujeme za Váš čas, MOJEservery.cz

Svařování optických vláken jako služba.

Optické sítě, svařování optických vláken


Svařováním optických vláken představuje dnes nejběžnější způsob spojování optické trasy, jedna se o poměrně složitou a zejména přesnou operaci prováděnou speciálním zařízením, tzv. optickou svářečkou (fusion splicer).

Tavné svařování řadíme do kategorie permanentního spojení pomocí technologie elektrického oblouku, jde o nejkvalitnější spoje z hlediska velmi nízkého útlumu v přenosové optické trase.

Nabízíme Vám svařování optických vláken

  • budování, servis, údržba optických sítí
  • svařování optických vláken (kabelů)
  • kompletní příprava, svaření, uložení vláken
  • svařování multimode (MM), mnohavidová vlákna
  • svařování singlemode (SM), jednovidová vlákna
  • svařování v terénu (až 200 sváru na baterii), svařování z plošiny
  • množstevní slevy při vaření vetšího množství vláken
  • disponujeme moderní svářečkou INNO
  • průměrný vložný útlum sváru 0.02 dB
  • instalační materiál pigtaily, spojky, optické i metal. rozvaděče

Operace při svařování

  1. Rozebrání optického kabelu, příprava, “stripování” ochrany
  2. Zalomení vláken a jejich důkladné očištění
  3. Založení vláken do optické svářečky
  4. Proces sváření
  5. Kontrola sváru, změření útlumu
  6. Ochrana sváru a zapečení
  7. Uložení vlákna

Chcete svařovat ? Kontaktujte nás.

Technické konzultace, implementace, nacenění řešení.
Kontaktní e-mail:  podpora@mojeservery.cz
Kontaktní telefon: +420 725 714 669

fusion-splicer-innoview-0-2016 fusion-splicer-innoview-1-2016 fusion-splicer-innoview-2-2016 fusion-splicer-innoview-4-2016 fusion-splicer-innoview-5-2016 fusion-splicer-innoview-6-2016

Realizováno! Konfigurace switche pro mikro datacentrum.

Realizováno!

Konfigurace switche pro datacentrum


Moderní komplexní sítě či sítě se složitější logikou a nároky se dnes neobejdou bez chytrých switchů (neuvažujeme o MPLS a další nadstavbách nad vrstvy), oddělení vzájemně nesouvisejících síťových provozů (traffic, datové toky) od sebe a zmenšování L2 broadcast domén pomocí VLAN je základní technika, která dnes jíž nepřekvapuje. Pokračování textu Realizováno! Konfigurace switche pro mikro datacentrum.

Realizováno! Konsolidace LAN, výstavba VPN pro AROMATERAPIE a.s.

Realizace VPN, konsolidace sítě LAN


Úspěšně realizováno!

Pro zákazníka 1. AROMATERAPEUTICKÁ KH a.s. jsem provedli konsolidaci lokální počítačové sítě (LAN), připojení první vzdálené pobočky pomocí technologie VPN, napojení na VoIP ústřednu, konfigurace firewallu a zavedení základní bezpečnostní politiky. Pokračování textu Realizováno! Konsolidace LAN, výstavba VPN pro AROMATERAPIE a.s.

Řešení Hotel stack platform

hotel-rack-stack-hotel-logo-720  Hotel stack platforma


Co je to hotel stack ?

Hotelové prostředí v moderním pojetí dnes reprezentuje komplexní, živý a náročný „organismus“, dobře naladěný hotel poznáte během okamžiku, orchestrování hotelů dnes představuje manažerský kolotoč a bez kvalitního informačního zázemí se nelze obejít.

Jaká je však skutečnost technologického zázemí dnešních hotelů ?

Z naší praxe za 20 let pohybu v hotelovém segmentu musíme bohužel konstatovat, že zcela tristní !

Staré dosluhující systémy, bez podpory aktualizace software, často zcela bez zálohovacích nástrojů pro ochranu dat, hardware prvky za morální životností netrpělivě čekající na „křemíkové nebe“, v provozu často dva i více fyzických serverů, každý s využitím na zátěže  ~10%, energetická efektivita škoda mluvit a pravidelný restart 1x denně/týdně je dobrý standart. A co sítě ? Zde začíná teprve velmi slušný cirkus, plochá LAN, chaoticky vyzařující a vzájemně se rušící hotelové wifi, často sporadicky fungující wifi pro hosty, vouchery?, tickety? sms platby? haló je rok 2016, bezpečnost hotelové sítě, firewall, VPN, propojení lokalit, nic, nic, jen sprostá slova a VoIP, magie, která v komerčním prostředí funguje zcela spolehlivě, jen hotely mají 20+ staré ústředny, čest jejich památce, proč když začít je tak snadné.

Zní vám to povědomě ?

Proč hotel stack ?

Platforma hotel stack představuje naši evoluční odpověď na konsolidaci IT prostředí hotelových provozů, ucelená modulární platforma odbavující veškeré služby hotelu od datové konektivity pomocí metalických i optických sítí, bezpečnostní firewall s VPN, řešení pro výkonné bezdrátové sítě s centrálním řízením wireless controllerem, nástroje pro virtualizaci serverů a hotelového software, integrovanou moderní VoIP ústřednu s tarifikací a okamžitému nasazení, systém zálohování a obnovy dat, dohledový kamerový systém s podporou IP kamer, vše doručováno při vysoké efektivitě, modulárnosti, energetické úspoře a chráněno záložním zdrojem UPS s přepěťovou ochranou.

hotel-rack-stack-140-orig-2016

 

hotel-stack-icon-router-2016   Hotel stack Router, Switch

  • LAN, WAN, VPN, Wifi, IPTV podpora, PoE (volitelně)
  • Firewall, bezpečnost, VLAN, oddělení sítí
  • Propojení lokalit do jedné sítě (virtual private network, VPN)
  • Podpora záložního připojení k internetu
  • WIFI controller (komplexní hotelové wifi řešení)
  • Statistiky, www filtrování obsahu, reporting aktivit zaměstnanců

hotel-stack-icon-virtual-server-2016   Hotel stack virtual server

Virtualizace serverů a  operačních systémů přináší efektivní využití Vašich hardware prostředků , k čemu mít 5x fyzický server a každý využívat každý na 20%, když je možné jedno železo a vytížit ho plně, úspory značné v pořízení i provozu.

Reálná agregace z praxe je až 10x virtuálních strojů na 1x fyzický server.
Virtualizační technologie VMware server/KVM.
Možnost přechodu do cloud prostředí datacentra !
Nechcete udržovat vůbec vlastní serveru fyzický server?
Lze hostovat virtuální servery v našem datacentru.
Nabídka: 4x CPU, 16GB RAM, 300GB HDD SSD, Windows 2012R2
Cena:    1650Kč / měsíčně

Používáme výhradně certifikované servery Dell, IBM, Supermicro, Thomas Krenn, redundantní komponenty, RAID pole.

Podporujeme operační systémy:

  • Microsoft Windows
  • Linux
  • FreeBSD

Podpora pro hotelový software dodavatelů:

  • Agnis
  • Fidelio
  • Deneb
  • Abra
  • GUBI komplexní systém
  • Hores, ALTO
  • Medicus, Septim

Připravené scénáře k okamžitému nasazení na „jedno kliknutí“:

  • ZDARMA!
  • Konfigurace domény pro počítače (uživatelé, skupiny, zásady)
  • Sdílení souborů (CIFS)
  • Poštovní server (email, kalendář, kontakty, synchronizace, webmail, antispam)
  • DNS, NTP

hotel-stack-icon-voip-phone-2016   Hotel stack VoIP

Moderní VoIP ústředna, levné hovory do celého světa.

  • přesměrování hovorů, konferenční hovory, nahrávání hovorů
  • digitální recepční, hlasové schránky
  • podpora tarifikace (rozúčtování hotelovým hostům)
  • podpora pro vrátníky (intercom),  dálkové spínání
  • analogové brány (FXS/FXO), GSM brány
  • hotelové služby, programování modulů na zákázku (moduly úklid hotelu, buzení, objednávka služeb, digitální asistent)

hotel-stack-icon-backup-2016   Hotel stack zálohování, kamerový systém

Zálohování konfigurace celé platformy (router, switch, virtualizační server včetně virtuálních strojů), možnost synchronizovat zálohy na externí zrcadlo pro zvýšení bezpečnosti.

hotel-stack-icon-security-cam-2016 Kamerový systém představuje jednoduchý nástroj pro online 24/7 monitoring a ostrahu objektů, provozů, podpora pro IP kamery s vysokým rozlišením v kombinaci s VPN technologií poskytující zařízení hotel stack router je možné přenášet  a ukládat obraz ze vzdálených lokalit (spojení dva a více hotelů).

hotel-stack-icon-UPS-2016   Hotel stack UPS

Zálohované napájení energie pro platformu, ochrana přepětí sítě.

Hotel stack modulárnost, kompaktnost, podpora

Díky promyšlenému konceptu a v praxi odzkoušenému designu v kombinaci s výběrem kvalitních komponent je hotel stack platforma funkční řešení s přidanou hodnotou.

Modulární koncept, když chcete více nebo i méně, začít se dá i s minimalistickým hotel stackem, který bude s Vámi růst dle Vašich potřeb, chcete něco více docházkový systém, zabezpečovací ústřednu/alarm, definujte sami podobu svého hotelu.

Podpora → poskytuje SLA servisní smlouvu na celý stack na vybrané komponenty záruka 36 až 60 měsíců,poskytuje konfigurace a přizpůsobení, aktivní monitoring a reporting stavu stacku, dále vývoj řešení a aplikací na zakáznku v rámci hotel stacku včetně mobilních aplikací a napojení a třetí strany.

Zamilujte se !
Hotelové IT prostředí jako nikdy dosud...to je HOTEL STACK!
Technické konzultace, implementace, nacenění řešení.
Kontaktní e-mail: podpora@mojeservery.cz
Kontaktní telefon: +420 725 714 669

Hotel stack pro každého, nezáleží na provozu, pokryjeme stejně dobře potřeby škol, městských úřadů, knihoven, výrobních hal, skladů, malých i středních firem, nebojte se zeptat.

hotel-stack-demo1-2016 hotel-stack-demo2-2016 hotel-stack-demo3-2016

Linux mini-howto: Diagnostický nástroj Traceroute

Linux mini-howto?
Krátce o nástrojích ze života sysadmina.

Diagnostický nástroj Traceroute


Info: Následující krátký jednoduchý text vznikl na základě praktické zkušenosti dotazů a z workshopů, je cílen na mladší generaci síťařů/adminů pro objasnění, že i za tak jednoduchým nástrojem traceroute není žádná magie, není cílem nikoho urazit, pouze osvěta. Děkuji.

Nástroj traceroute umožňuje základní analýzu počítačové sítě formou textového výpisu směrovačů (uzlů) na cestě paketu od zdroje v cíli, jde tedy o velmi efektivní nástroj pro rychlé zobrazení aktuálních cesty (routování) v sítí, standardně je tento nástroj obsažen ve většině Linux/Unix systémech, ve světě Windows má svoji implementaci v podobě nástroje tracert. Pokračování textu Linux mini-howto: Diagnostický nástroj Traceroute

Linux mini-howto: Simulace zpoždění a ztrátovosti paketů v IP sítích

Linux mini-howto?
Krátce o nástrojích ze života sysadmina.

Simulace zpoždění a ztrátovosti paketů


V předchozím Linux-mini howto (Je tunelování TCP skrz TCP dobrý nápad ?) jsme na konci článku zmínili formou odkazů informace k této problematice i přes tento fakt a existenci Google přišlo pár dotazů jak na to, pojďme to v rychlosti proběhnout.

Diagnostika sítí je komplexní, rozsáhlá a složitá disciplína plná záludností, složitých software nástrojů a sofistikovaných drahých měřících přístrojů, přesto se hodí umět si vyrobit kontrolovaně svůj vlastní problém na stole (nemluvíme teď o “muchlání” a kroucení kabelů či nucení kolegů na chodbě běhat skrze bezdrátový spoj ;-) ) a to zcela zdarma díky Linux jádru.

Základní kvalitativní parametry sítě

Zpoždění (latency)
https://cs.wikipedia.org/wiki/Latence#V_informatice

Ztrátovost paketů (packet loss)
https://cs.wikipedia.org/wiki/Ztráta_paketů

Linux kernel, IP stack, fronty, netem NIC

Linux jádro má již od verze 2.6 (dobře, vlastně od 2.4.37) implementovanou funkcionalitu pro network emulaci (netem), pokud máte kernel 2.6 a novější, zakompilovanou podporu Network emulatoru do jádra či jako modul a k tomu nainstalovaný obslužný nástroj tc (traffic control) z balíku iproute2 máte vše potřebné.

Networking -->
   Networking Options -->
     QoS and/or fair queuing -->
        Network emulator

CONFIG_NET_SCH_NETEM=m
Jak funguje netem (linux network emulator) ?

Popišme si alespoň základní koncept síťování v Linux, jednoduchá ilustrace nám dobře pomůže k pochopení, na jedné straně máme aplikace komunikující prostřednictvím systémových volání jádra (syscall) s IP stackem, chtějí komunikovat s hostem a.b.c.d, navazovat spojení, posílat data a o moc více se nestarat.

simulate-latency-pktloss-network-linux-network-qdisc-2016

IP stack předává pakety do qdisc (Queueing discipline), což není nic jiného než scheduler (plánovač, kód v jádře systému) fronty, který rozhoduje o tom v jakém pořadí zpracovat pakety, každé výstupní rozhraní má alespoň jeden qdisc (scheduler, frontu), po průchodu frontou přes ovladač síťové karty putují data ven.

Výchozí fronta v Linuxu je většinou FIFO (First-in, First-Out).

root@netem-machine:~# tc -s qdisc
qdisc pfifo_fast 0: dev eth0 root refcnt 2 bands 3 priomap
 Sent 14757932 bytes 163954 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0 

root@netem-machine:~# tc qdisc show
qdisc pfifo_fast 0: dev eth0 root refcnt 2 bands 3 priomap

Výpisem pomocí nástroje tc jsme si ověřili aktuálně nastavený qdisc na zařízení eth0 (ethernet), je patrné, že máme nastavenou frontu typu pfifo (packet FIFO) z následující obrázku je vidět, že pfifo interně implementuje i jednoduchý priority mapping a obsahuje uvnitř tři různé fronty pro přednostní zpracování.

pfifo qdisck

Pokud je fronta plná (linka je zatížená) a nemůže být přijmut další paket ke zpracování, dojde k jeho zahození, frontu lze pro tento účel zvětšit, následkem je většinou zvýšení latence, ale můžeme pozorovat i lepší využití linky.

Pro doplnění představ, v Linux jádře je dnes přes 20 různých schedulerů paketů (red, qfq, prio, mq, cbq, htb, sfq ,…) a nic Vám nebrání napsat si svůj vlastní unikátní pro Vaše potřeby. (http://lxr.free-electrons.com/source/net/sched/ )

Netem, skrze dlouhou okliku a vysvětlení qdisc se vraťme zpět k našemu emulátoru, z předchozích informací je zřejmé, že netem je implementován jako další plánovač paketů se schopností přidávat ke zpracování latence včetně náhodné distribuce, generovat ztrátovost, duplikovat i měnit pořadí paketů(reordering).

Použití je opravdu triviální, ukážeme si, nahrajeme modul netem do jádra, nastavíme na rozhraní eth0 qdisc netem, nastavíme parametry zpoždění, náhodného rozptylu, ztrátovosti a otestujeme.

root@netem-machine:~# modprobe sch_netem
root@netem-machine:~# tc qdisc show
qdisc pfifo_fast 0: dev eth0 root refcnt 2 bands 3 priomap
root@netem-machine:~# 
root@netem-machine:~# tc qdisc add dev eth0 root netem
root@netem-machine:~# tc qdisc show
qdisc netem 8004: dev eth0 root refcnt 2 limit 1000

Zpoždění 200ms , host 10.0.200.1 je součástí directly connected sítě, okamžitě lze vidět nárůst latence zde pomocí ping nástroje.

root@netem-machine:~# tc qdisc change dev eth0 root netem delay 200ms

root@test-machine:~$ ping 10.0.200.1
PING 10.0.200.1 (10.0.200.1) 56(84) bytes of data.
64 bytes from 10.0.200.1: icmp_seq=1 ttl=64 time=0.295 ms
64 bytes from 10.0.200.1: icmp_seq=2 ttl=64 time=0.268 ms
64 bytes from 10.0.200.1: icmp_seq=9 ttl=64 time=0.230 ms
64 bytes from 10.0.200.1: icmp_seq=10 ttl=64 time=200 ms
64 bytes from 10.0.200.1: icmp_seq=11 ttl=64 time=200 ms
64 bytes from 10.0.200.1: icmp_seq=12 ttl=64 time=200 ms

Zpoždění 500ms ± 100ms, je vidět zpoždění ± s velkým rozptylem (ne realtime jádro s tím asi dost bojuje).

root@test-machine:~# tc qdisc change dev eth0 root netem delay 500ms 100ms
root@test-machine:~$ ping 10.0.200.1
PING 10.0.200.1 (10.0.200.1) 56(84) bytes of data.
64 bytes from 10.0.200.1: icmp_seq=24 ttl=64 time=0.242 ms
64 bytes from 10.0.200.1: icmp_seq=25 ttl=64 time=0.272 ms
--- aplikace netem ---
root@test-machine:~$ ping 10.0.200.1
PING 10.0.200.1 (10.0.200.1) 56(84) bytes of data.
64 bytes from 10.0.200.1: icmp_seq=1 ttl=64 time=453 ms
64 bytes from 10.0.200.1: icmp_seq=2 ttl=64 time=479 ms
64 bytes from 10.0.200.1: icmp_seq=3 ttl=64 time=502 ms
64 bytes from 10.0.200.1: icmp_seq=4 ttl=64 time=491 ms
64 bytes from 10.0.200.1: icmp_seq=5 ttl=64 time=553 ms
64 bytes from 10.0.200.1: icmp_seq=6 ttl=64 time=532 ms
64 bytes from 10.0.200.1: icmp_seq=7 ttl=64 time=534 ms
64 bytes from 10.0.200.1: icmp_seq=8 ttl=64 time=490 ms
64 bytes from 10.0.200.1: icmp_seq=9 ttl=64 time=450 ms

Ztrátovost  10% (10% paketů bude náhodně zahazováno) + latence 100ms, náhodu lze ještě ovlivňovat korelací kdy je závislá na předchozím výsledku v %, je to trochu chaotické, ale vlastně méně chaotické, protože zmenšujeme náhodnost generátoru).

root@test-machine:~# tc qdisc change dev eth0 root netem delay 100ms loss 10%

root@test-machine:~$ ping -q -c 10 10.0.200.1
PING 10.0.200.1 (10.0.200.1) 56(84) bytes of data.
--- 10.0.200.1 ping statistics ---
10 packets transmitted, 9 received, 10% packet loss, time 9026ms
rtt min/avg/max/mdev = 100.222/100.298/100.371/0.163 ms

root@test-machine:~$ ping -q -c 10 10.0.200.1
PING 10.0.200.1 (10.0.200.1) 56(84) bytes of data.
--- 10.0.200.1 ping statistics ---
10 packets transmitted, 6 received, 40% packet loss, time 9013ms
rtt min/avg/max/mdev = 100.197/100.239/100.295/0.185 ms

Základní představu o konceptu netem a jeho využití jsme snad představili, studujte dokumentaci, další pěknou věcí, která stojí za vyzkoušení je poškozování paketů (netestovali jsme bohužel), není špatné si pro přehled projít i zdrojový kód netem, pěkné je nasazení netem i na příchozí provoz pomocí modulu IFB (pouze otočí in přes pseudo device na out a na něm udělat netem) v ukázkách dokumentace nejdete jak netem protáhnout i jen specifický traffic přes tc filter, omezit rychlost apod … prostě studujte.

V našem případě při testování a hledání problémů s TCP over TCP jsem si postavili script který měnil hodnoty zpoždení a ztrátovosti od malých až po extrémní, tak aby jsme donutili TCP prodlužovat adaptivní timeout a sledovat pomocí tcpdump/wireshark co se děje uvnitř spojení.

Děkuji za pozornost.
František Havel, MOJEservery.cz

Zdroje:

http://man7.org/linux/man-pages/man8/tc-netem.8.html

http://lxr.free-electrons.com/source/net/sched/sch_netem.c

http://www.linuxfoundation.org/collaborate/workgroups/networking/netem

http://info.iet.unipi.it/~luigi/dummynet/

Linux mini-howto: DHCP Option 82 ?

Linux mini-howto?
Krátce o nástrojích ze života sysadmina.

DHCP Option 82 ?


Ve stručnosti řečeno DHCP volba 82 (option) je “DHCP Relay Agent Information Option”, dobře, máme to, končíme, … ;-), protože nedávno jsme řešili tuto konfiguraci v zákaznické síti tak alespoň slov o této možnosti.

DHCP protokol je technologie pro automatizovanou konfiguraci zařízení připojeným do sítě, používá protokol a porty UDP/68,UDP/69, přiřazení konfigurace má 4 fáze.

Princip a činnost DHCP
Princip a činnost DHCP

 

  1. Discovery – klient se připojí do sítě a pomocí broadcast požádá o konfiguraci sítě.
  2. Offer - DHCP server odpoví, rezervuje si IP adresu pro klienta ze svého adresního rozsahu (pool) nabídne ji klientovi.
  3. Request - klient si vybere IP adresu (DHCP server může nabídnou více IP adres) a informuje server o vybrané IP (opět broadcastem)
  4. Acknowledge - DHCP server potvrdí platnost vybrané IP adresy a zašle další informace, bránu, DNS servery, dobu zápůjčky IP adresy (lease time) a případné další informace dle konfigurace.

K čemu DHCP option 82 ?

Velké a rozsáhle firemní sítě, IPTV implementace, specializované sítě např. pro řízení, monitoring, atp. často vyžadují nějakou formu centralizovaného řízení přiřazování IP adres, DHCP služba má tu nepříjemnost, že komunikuje pomocí broadcast a tudíž by musel být DHCP server na každém segmentu sítě, což je nepraktické, zde nám přichází na pomoc DHCP Relay Agent (služba typicky běží na lokální routeru nebo chytřejším switchi obsluhující dané segmenty LAN), předává unicastem požadavky na centrální DHCP server a zpracovává odpovědi zpět do LAN.

DHCP option 82, relay agent information šikovně doplňuje informaci pro DHCP server o požadavku ( RFC https://tools.ietf.org/html/rfc3046 ), typicky jde o hodnoty Agent CurcuitID  (pro ethernet switche reprezentuje port ze kterého přišel požadavek) a Agent RemoteID (MAC adresa agenta), informaci je možné dále použít v logice rozhodování o přiřazení konfigurace DHCP serverem, bezpečnosti, analýze kdy, kde a co se nám připojuje apod.

Pozn.: Informací které lze předávat může být více, pomocí sub option, vždy je vhodné mít po ruce dokumentaci od aktivního prvku a např. wireshark/tcpdump, protože chcete mít jistotu a vědět a né jen tušit, protože správné naladění Vám chvilku může zabrat.

Co na to ISC DHCP server ?

Předně je ISC DHCP server trochu ďábelský kus software, mohlo by se Vám hodit PDF https://www.isc.org/wp-content/uploads/2014/08/DHCP-4.3.1-Distribution-Documentation-Aug-4-14.pdf , dále notná dávka trpělivost, logování a tcpdump je velmi vhodný, nelze zde popsat všechny možnosti, principiálně jde o “matchování”

Málá ukázka triviální ukázka od které jsem se odpíchli, ukazuje použití match/podmínky if a proměné agent.circuit-id v tomto případě detekuje číslo portu na sw.

dhcpd.conf
---
class "static-port-A1" {
match if(substring(option agent.circuit-id,4,2)=01:01)
} 

class "static-port-A1" {
match if(substring(option agent.circuit-id,4,2)=01:02)
}
 
shared-network group {
subnet 10.1.0.0 netmask 255.255.0.0 {
        pool {
                allow members of        'keep1';
                range 10.1.1.100 10.1.1.200;
                option subnet-mask      255.255.255.0;
        }
        pool {
                allow members of        'keep2'
                range 10.1.2.100 10.1.2.200;
                option subnet-mask      255.255.255.0;
        }
}
}
# Log
if exists agent.circuit-id
{
 log ( info, concat( " Lease for ",
                     binary-to-ascii (10, 8, ".", leased-address),
                     " Switch port: ", 
                     binary-to-ascii (10, 8, ".", option agent.circuit-id), 
                     " Switch MAC: ",
                     binary-to-ascii(16, 8, ".", option agent.remote-id)));
}

http://henrici.biz/projects/downloads/option82_dhcpd.conf 

https://adamkuj.net/blog/2015/10/09/isc-dhcpd-putting-option-82-vendor-codes-to-use/ 

Překvapivě konfigurace není úplně triviální, zabere dost času ale dává další možnosti a kontrolu, zajímavou možností je také v ISC DHCP serveru spustit event při každém novém přiřazení IP adresy, to lze využít, pochopitelně se ve větší nevyhnete dhcp snoopingu a rozdělení portů na trusted/untrusted, port-security případně IP source guard apod. technikám, útok na druhou vrstvu je překvapivě snadný o to více bolestivý, dhcp option 82 je další možnost, kterou je fajn znát.

A to je vše, užívejte moudře a happy hacking.
František Havel, www.mojeservery.cz