Archiv pro štítek: network

Realizováno! Konsolidace LAN vzdělávací středisko Revis Tachov 2017

Konsolidace LAN vzdělávací středisko Revis Tachov


Regionální vzdělávací a informační středisko Revis Tachov působí na Tachovsku od roku 2004 s primárním cílem zvyšovat vzdělanost v regionu formou pravidelných školení a praktických workshopů, v nabídce služeb lze nalézt možnosti pronájmu plně vybavených školících prostor, počítačovou učebnu či možnost ubytování.

Nic z toho by se dnes neobešlo bez fungujícího ICT zázemí, proto děkujeme za poskytnutou příležitost a důvěru při realizaci kompletní konsolidace IT prostřední čítající výstavbu nové metalické i bezdrátové sítě s podporou funkce hotspotu, dodání centrálního úložiště dat a migrace dat z původní Linux serveru včetně konfigurace práv a zálohování, konfigurace zabezpečení LAN, oddělení provozů v sítích, konfigurace služby VPN pro vzdálený přístup a v neposlední řadě přepojení celé organizace na městskou metropolitní optickou síť Tachov a tím získání přístupu k vysokorychlostnímu internetu namísto starého ADSL.

Děkujeme za příležitost a těšíme se na další spolupráci.
Nejlepší podpora pro Vaše IT.
MOJEservery.cz | Exirta s.r.o.

Pokračování textu Realizováno! Konsolidace LAN vzdělávací středisko Revis Tachov 2017

Android-sysadmin-tools: Nástroje systém administrátora #1

Android sysadmin-tools ?
Krátce o nástrojích ze života sysadmina.

Nástroje systém administrátora pro Android


Co není v hlavě, musím být v nohách říká klasické pravidlo ! Systém admin je však tvor od přírody líný a proto šetří své podrážky jak to jen jde a pokud může, tak má ve svém kapesním “android stopaři” pár více či méně šikovných “švýcarských nožů”.

Následující minisérie s předem nedefinovaným počtem dílů ukazuje pár užitečným nástrojů, začněme však od konce, ty provařené (ssh klienti, rdp, vnc, nmap, cidr calc, atd.) jsou důvěrně známe a nebudeme nosit sovy do athén.

Pokračování textu Android-sysadmin-tools: Nástroje systém administrátora #1

Realizováno! Konsolidace firemního ICT prostředí pro DUKE Abraham s.r.o.

Realizováno!

Konsolidace ICT DUKE Abraham s.r.o. Tachov


Společnost DUKE Abraham s.r.o. je ryze české firma působící v oblasti kovovýroby, CNC a obrábění na trhu již od roku 1992, vyniká vysokou kvalitou, flexibilitou, termínem dodání a zejména proto velmi děkujeme za poskytnutou příležitost a důvěru při realizaci kompletní konsolidace firemního ICT prostřední, čítající výstavbu firemní metalické i bezdrátové sítě, výměnu většiny aktivní prvků sítě, dodání nové serverové infrastruktury Dell a migraci fyzických serverů do virtuálního prostřední včetně zálohování celé infrastruktury.

Konsolidováno:

  • Konsolidace serverovny, znovu-zapojení fyzické sítě, popis
  • Výměna aktivní prvků sítě (záruka 5 let na vše)
  • Nové infrastruktura, servery Dell (SLA 5 let onsite)
  • Virtualizační infrastruktura VMware
  • Konfigurace sítě switche, routery, firewall, VLAN, spanning tree, port-security, trunk, optický propoj do druhé budovy
  • Výstavba bezdrátové sítě 2.4/5GHz s oddělením provozu pro zaměstnance, vedení, hosté + MAC access list
  • Aktivní monitoring (dostupnost služeb, SNMP, grafy provozu), včasné odhalení problému, výpadky, viditelnost
  • Oddělení síťového provozu serverů do vlastní LAN/L2 domény
  • Oddělení síťového provozu PC do vlastní LAN/L2 domény
  • Oddělení síťového provozu VoIP do vlastní LAN/L2 domény
  • Oddělení síťového provozu WiFi do vlastní LAN/L2 domény
  • Oddělení síťového provozu CCTV do vlastní LAN/L2 domény
  • Oddělení síťového provozu mgmt do vlastní LAN/L2 domény
  • Oddělení síťového provozu backup do vlastní LAN/L2 domény
  • Pravidelné centrální zálohování dat

Ilustrace nové topologie sítě DUKE-Abraham s.r.o.

Ilustrace topologie sítě DUKE-Abraham s.r.o., realizace MOJEservery.cz 2017
Ilustrace topologie sítě DUKE-Abraham s.r.o., realizace MOJEservery.cz 2017

Virtualizace serverové infrastruktury

V rámci konsolidace byla navržena a následně realizována migrace veškerých fyzických serverů do virtualizované infrastruktury technologie VMware s centrálním zálohováním na backup server s umístěním do jiné fyzické lokality.

Ilustrace: Virtualizační stack VMware
Ilustrace: Virtualizační stack VMware

Centrální zálohování dat

Pro fungující a bezpečnou infrastrukturu je naprosto klíčový prvek zálohování dat, pro zálohování byl nasazen centrální server Dell se systémem Linux Debian 9, data v konfiguraci RAID1 a filesystémem BTRFS s podporou snímků (snapshot), podporována je metoda zálohování celých virtuálních strojů tak dat samotných, v neposlední řadě jsou na zálohovacím serveru umístěny aktuální konfigurace síťových prvku.

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

MOJEservery.cz


Switch Edgecore v druhé lokalitě, optický propoj do serverovny.
Switch Edgecore v druhé lokalitě, optický propoj do serverovny.
Zálohovací server Dell, Debian 9, BTRFS filesystem.
Zálohovací server Dell, Debian 9, BTRFS filesystem.
Centrální serverovna DUKE-Abraham po konsolidaci 2017.
Centrální serverovna DUKE-Abraham po konsolidaci 2017.

 

Zaujalo Vás toto řešení ?
Chcete konsolidovat LAN, přemýšlíte serverech, virtualizaci, bezdrátové LAN či VPN ?
Nebo se chcete jen poradit ?
Kontaktujte nás, jsem tu pro Vás. MOJEservery.cz
Technické konzultace, implementace, návrhy řešení.
Kontaktní e-mailobchod@mojeservery.cz
Kontaktní telefon: +420 725 714 669

Ř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: Je tunelování TCP skrz TCP dobrý nápad ?

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

Tunelování TCP skrz TCP


Tunelování spojení, TCP over …. , z praxe dnes běžně známe tunelování TCP spojení např. protokolem PPP což je protokol druhé vrstvy pro navázaní spojení mezi dvěma body, do PPP zapouzdříme na straně odesílatele naše TCP spojení (hlavičku + data) a odešleme, na druhé straně odebereme PPP informace a naše TCP pokračuje v sítí cestou dále k požadovanému cíli, zní to jednoduše a ve většině případů to funguje “par excellence”.

Jenže “neštěstí” nechodí po horách, ale po lidech a stejně je tomu i v telekomunikacích, když honíte duchy v sítí není dobré se obrnit myšlenkou, že tohle se mi nemůže stát aneb jak jsem tunelovali přes VPN tunel (tcp) další TCP tunel a jak to “blblo”.

Něco málo k teorii, TCP ve své podstatě reprezentuje proud dat rozdělený do tzv. segmentů (narozdíl od UDP, které představuje samostatné na sobě nezávisle datagramy, nezaručuje doručení ani pořadí), segmenty jsou opatřeny tzv. sequence number, což je číslo ukazující pořadí segmentu ve streamu a segmenty odesílány jako IP packety k cíli s velikosti MTU.

tcpip-headers-tcp-over-tcp-blog-header-2016

 

Tcp sequence number (SEQ, ACK, FIN)
Tcp sequence number (SEQ, ACK, FIN)

Cíl (na obrázku server) přijme packet a odpovída zpět pomocí příznaku ACK (acknowledge, odpověd), kde jako acknowledge number uvede přijmuté sequence number ze segmentu + 1, popis mechanismu je pro náš účel zjednodušen, ale to podstatné je zachováno, odesílatel (client) se tímto způsobem může dozvědět, že segment (data) byla ztracena a dojde k opětovnému zaslání (resend).

Dobře, co s tím dále ? Internet je “pěkně” divoké prostředí, data procházejí přes uzly které nemáte šanci kontrolovat, různá kvalita linek, zpoždění, ztrátovost, tvůrci TCP s tím počítali, proto je v návrhu TCP vlastnost timeoutu (odesílatel čeká na potvrzení ACK po určitý čas), round-trip-time (RTT), problém je ovšem v tom jak určit kolik RTT má být, pevná hodnota je nevyhovující a proto máme v TCP adaptivní timeout, který korigován “automacticky” během spojení, tak aby vyhověl  i nejpomalejším linkám na trase, hodnota se může pohybovat od řádů sekund až po minuty (RFC2001), což je opravdu velký rozptyl.

TCP “meltdown” problém

V předchozích řádkách bylo nastíněno zjednodušené pozadí fungování TCP, představme si situaci, mějme TCP spojení (např. VPN) a uvnitř další TCP spojení, uvažujme problém na trase (pktloss/ztrátovost), nižší vrstva TCP (VPN) začne žádat o znovu zaslání dat (retransmission) a prodlužovat svůj timeout (RTT), spojení je blokováno, vyšší vrstva TCP (zapouzdřené TCP) začne timeoutovat a opět žádat o resend a prodlužovat svůj RTT, hodnota RTT zapouzdřeného TCP je nižší než hodnota skutečného TCP, vyšší vrstva tedy generuje více požadavků na znovu zaslání dat než může nižší vrstva TCP (skutečné) obsloužit, této situaci se říka TCP meltdown (utavení, roztavení, zhroucení).

TCP meltdown má vliv na výkon  sítě, či může véct k úplnému rozpadu spojení, v našem případě jsme měli problém s OpenVPN a PPTP, na použití TCP bylo trváno zákazníkem kvůli politice jeho firewallu, nakonec přechod k UDP a vhodná úprava konfigurace firewall ukázalo průchodné řešení.

Na každý pád to znamená zajímavou zkušenost, není úplně snadné tento problém hledat, klon konfigurace do vašeho prostředí většinou nevede k cíli protože vše funguje, co je dobré vědět a velmi pomohlo k porozumění problému, je možnost simulovat zpoždění i ztrátovost přímo Linux routerem (nástroj tc, iptables), odkazy přiloženy a pochopitelně tcpdump/wireshark.

simulate-delayed-and-dropped-packets-on-linux

dropping-packets-in-ubuntu-linux-using-tc-and-iptables

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

Linux mini-howto: Telnet ověření dostupnosti služeb

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

Telnet ověření dostupnosti TCP/IP služeb


Telnet jako nástroj a protokol byl před mnoha a mnoha lety zatracen a nahrazen zejmána kvůli bezpečnostním nedostatkům protokolem ssh, což je zcela v pořádku, v mnoha současných distribucích není již dnes ani nainstalován a přitom byl běžný. Pokračování textu Linux mini-howto: Telnet ověření dostupnosti služeb

Linux mini-howto: Jak zabít TCP spojení s nástrojem tcpkill

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

Nástroj tcpkill

Přijde čas od času k duhu, vytvořit TCP spojení je snadné a umí to každý, ale co dělat pokud chceme konkrétní spojení zabít? Trochu Nerudovská otázka: „Kam s ní“, že? Na procesy máme kill, ale co s tcp, navazané je, firewall jsem opravili a teď ho ukončeme.

Tak jednoduché to zas není, k uzavření socketu je potřeba  znát TCP ACK(Acknowlegment) a SEQ(Sequence numbers), je nutné tyto informace extrahovat z paketu spojení (odposlechnout, spoof) a zaslat TCP RST(reset).

Nástroj tcpkill funguje přesně popsaným mechanismem, syntax je shodný s nástrojem tcpdump, autorem tcpkill je Dug Song.

# tcpkill -i eth0 { expression }
# tcpkill -i eth0 port 21 // zabije odchozí spojení na port 21(FTP)
# tcpkill host 192.168.1.42 // zabije odchozí spojení na host 192.168.1.42

Hotovo!

Vypadá to jednoduše, popsaný mechanismus ukončení tcp spojení (tzv. passive, pasivní) má jeden drobný neduh, v případě tcp spojení ve stavu idle(wait, keepalive) není co ochytit (nejsou data, není co spoofovat), takové spojení se Vám tímto nástrojem nepodaří zabít.

Příště se podíváme na nástroje killcx, cutter a bude-li čas i low-level hack s netstat,lsof a kill.

Užívejte moudře, díky za pozornost. František Havel.

Linux: Redhat tahák pro příkaz ip

Nemůžete si stále zapamatovat syntax “nového” nástroje ip pro práci se sítí v Linuxu? (proč “” nástroj ip, byl představen již pro linux jádro 2.2, ale zvyk v podobě ifconfig je železná košile).

Přirozeně můžete dokumentaci najít v manuálových stráchkách, ale při hledání jednoduché referenční příručky jsem narazil na RedHat tahák (cheat sheet), chtěl jsem něco co lze vytisknout, pověsit a mít to stále na očích až se to člověku vryje paměti a našl jsem, tak posílám dále.

PDF pro tisk rh_ip_command_cheatsheet_1214_jcs_print.

Tak trénujte. Díky František Havel

rh_ip_command_cheatsheet_1214_jcs_print-page-001

rh_ip_command_cheatsheet_1214_jcs_print-page-002