abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

včera 11:33 | Pozvánky

Konference LinuxDays 2017 proběhne o víkendu 7. a 8. října v Praze v Dejvicích v prostorách FIT ČVUT. Konference OpenAlt 2017 proběhne o víkendu 4. a 5. listopadu na FIT VUT v Brně. Organizátoři konferencí vyhlásili CFP (LinuxDays, OpenAlt). Přihlaste svou přednášku nebo doporučte konference známým.

Ladislav Hagara | Komentářů: 0
včera 06:00 | Nová verze

Byla vydána verze 1.3.0 odlehčeného desktopového prostředí Lumina (Wikipedie, GitHub) postaveného nad toolkitem Qt. Z novinek lze zmínit nový motiv ikon nahrazující Oxygen (material-design-[light/dark]) nebo vlastní multimediální přehrávač (lumina-mediaplayer).

Ladislav Hagara | Komentářů: 2
26.6. 17:33 | Bezpečnostní upozornění

Před šesti týdny byly publikovány výsledky bezpečnostního auditu zdrojových kódů OpenVPN a nalezené bezpečnostní chyby byly opraveny ve verzi OpenVPN 2.4.2. Guido Vranken minulý týden oznámil, že v OpenVPN nalezl další čtyři bezpečnostní chyby (CVE-2017-7520, CVE-2017-7521, CVE-2017-7522 a CVE-2017-7508). Nejzávažnější z nich se týká způsobu, jakým aplikace zachází s SSL certifikáty. Vzdálený útočník může pomocí speciálně

… více »
Ladislav Hagara | Komentářů: 1
26.6. 06:55 | Zajímavý projekt

V Edici CZ.NIC vyšla kniha Průvodce labyrintem algoritmů. Kniha je ke stažení zcela zdarma (pdf) nebo lze objednat tištěnou verzi za 339 Kč (připojení přes IPv4) nebo 289 Kč (připojení přes IPv6).

Ladislav Hagara | Komentářů: 8
26.6. 06:33 | Zajímavý software

Byla vydána verze 2.2.0 svobodného správce hesel KeePassXC (Wikipedie). Jedná se o komunitní fork správce hesel KeePassX s řadou vylepšení.

Ladislav Hagara | Komentářů: 0
26.6. 06:11 | IT novinky

Vývojář Debianu Henrique de Moraes Holschuh upozorňuje v diskusním listu debian-devel na chybu v Hyper-Threadingu v procesorech Skylake a Kaby Lake od Intelu. Za určitých okolností může chyba způsobit nepředvídatelné chování systému. Doporučuje se aktualizace mikrokódu CPU nebo vypnutí Hyper-Threadingu v BIOSu nebo UEFI [reddit].

Ladislav Hagara | Komentářů: 0
24.6. 01:23 | Komunita

Phoronix spustil 2017 Linux Laptop Survey. Tento dotazník s otázkami zaměřenými na parametry ideálního notebooku s Linuxem lze vyplnit do 6. července.

Ladislav Hagara | Komentářů: 3
23.6. 22:44 | Nová verze

Po třech měsících vývoje od vydání verze 5.5.0 byla vydána verze 5.6.0 správce digitálních fotografií digiKam (digiKam Software Collection). Do digiKamu se mimo jiné vrátila HTML galerie a nástroj pro vytváření videa z fotografií. V Bugzille bylo uzavřeno více než 81 záznamů.

Ladislav Hagara | Komentářů: 1
23.6. 17:44 | Nová verze

Byla vydána verze 9.3 open source alternativy GitHubu, tj. softwarového nástroje s webovým rozhraním umožňujícího spolupráci na zdrojových kódech, GitLab. Představení nových vlastností v příspěvku na blogu a na YouTube.

Ladislav Hagara | Komentářů: 3
23.6. 13:53 | Nová verze

Simon Long představil na blogu Raspberry Pi novou verzi 2017-06-21 linuxové distribuce Raspbian určené především pro jednodeskové miniaturní počítače Raspberry Pi. Společně s Raspbianem byl aktualizován také instalační nástroj NOOBS (New Out Of the Box Software). Z novinek lze zdůraznit IDE Thonny pro vývoj v programovacím jazyce Python a především offline verzi Scratche 2.0. Ten bylo dosud možné používat pouze online. Offline bylo možné používat pouze Scratch ve verzi 1.4. Z nového Scratchu lze ovládat také GPIO piny. Scratch 2.0 vyžaduje Flash.

Ladislav Hagara | Komentářů: 2
Chystáte se pořídit CPU AMD Ryzen?
 (6%)
 (31%)
 (1%)
 (9%)
 (44%)
 (9%)
Celkem 853 hlasů
 Komentářů: 65, poslední 1.6. 19:16
    Rozcestník

    Dotaz: Propojeni vice VPN siti

    14.3. 14:07 Tom
    Propojeni vice VPN siti
    Přečteno: 1535×
    Dobry den,

    chtel bych ze zeptar, respektive pozadat o doporuceni, jak nejvhodneni nakonfigurovat nasledujici situaci:

    Mam jednu hlavni LocalLAN (192.168.1.0/24) s verejnou IP, a dale mam nekolik RemoteLAN (10.1.X.0/24), ktere jsou k internetu pripojeny pres ADSL (O2) Potreboval bych se z LocalLAN naprimo pripojovat na jakykoliv pocitac v jakekoliv RemoteLAN.

    Rozsahy v RemoteLAN jsou vzdy 10.1.X.0/24, kde X by identifikovalo tu konkretni RemoteLAN.

    Takze:
    RemoteLAN1:
    10.1.1.1 - router
    10.1.1.2 - PC1
    10.1.1.3 - PC2
    
    RemoteLAN2:
    10.1.2.1 - router
    10.1.2.2 - PC1
    10.1.2.3 - PC2
    
    atd....
    
    Tech RemoteLAN by ale melo byt vice, klidne 10-20 (teoreticky klidne 254), do kazde muzu pridat OpenWRT router, ktery by mohl fungovat jako VPN klient.

    Jak na to? Nasel jsem zatim navody na Site-to-Site OpenVPN. Je to to co potrebuji?

    Muzete me prosim nasmerovat, jak se toto resi "spravne"? Co bych mel nastudovat?

    Dekuji

    Tom

    Odpovědi

    14.3. 14:30 Sten
    Rozbalit Rozbalit vše Re: Propojeni vice VPN siti
    Site-to-site VPN je jednoduchá, stačí na routerech rozjet point-to-point VPN (OpenVPN tun), nasměrovat rozsah druhé strany do správného tunelu (pomocí konfigurační volby iproute) a vše bude fungovat.
    16.3. 05:30 Michal
    Rozbalit Rozbalit vše Re: Propojeni vice VPN siti
    Urcite potrebujes site-to-site VPN, nejlepe OpenVPN.

    Otazka je jak nakonfigurovat ty vzdalene site. Jelikoz jich je tolik tak bych se skoro priklanel k zneuziti OpenVPN tls-server / tls-client namisto pro site-to-site obvyklejsi "shared secret" konfigurace. Budes mit jeden spolecny CA certifikat a pro kazdy router tim podepises jeho vlastni SSL certifikat. Tim padem se routery s platnym certifikatem budou moct pripojit na server.

    Dalsi problem je routovani do tech vzdalenych siti. V klasickem site-to-site ma kazda strana seznam rozsahu te protistrany v OpenVPN konfiguraku, ale s tls-server/tls-klient to tak primocare neni, takze budes muset na serveru pouzit "client-config-dir" a v tom hlavne volbu "iroute" (oboji viz manpage pro openvpn). Pripadne nejake dynamicke routovani (OSPF) ale to je az dalsi level.

    Drzim palce ;)
    Max avatar 16.3. 09:36 Max | skóre: 65 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Propojeni vice VPN siti
    Zajímalo by mně, proč se tu doporučuje OpenVPN a né standardní IPSEC? Jaký to má oproti IPSECu přínos, který nevidím?
    Zdar Max
    Měl jsem sen ... :(
    16.3. 09:43 NN
    Rozbalit Rozbalit vše Re: Propojeni vice VPN siti
    Asi zadny, ale je to snazsi na konfiguraci. Ja s IPSekem problem nemam, ale ne kazdy bezny spravce vi co je SA, Phase 2 etc.
    18.3. 12:28 Michal
    Rozbalit Rozbalit vše Re: Propojeni vice VPN siti
    Protože OpenVPN "just works" zatímco IPsec "just sucks".

    Tak třeba:

    - v Linuxu se IPsec tunel netváří jako network interface, což značně komplikuje spoustu věcí - provoz routovacích daemonů, nastavení firewallu, tcpdump, ... OpenVPN prostě vytvoří tun0 a s ním si můžu dělat co chci stejně jako s každým jiným interfacem a vidím v něm jen vnitřní provoz toho tunelu.

    - u IPsec je potřeba na obou stranách nastavit stejné parametry spojení, což je někdy netriviální zařídit. OpenVPN si to mezi sebou obě strany domluví samy.

    - IPsec tunel je potřeba konfigurovat zvlášť pro IPv4 a IPv6, OpenVPN tunel může přenášet oba protokoly.

    - za jedním NATem může být jen jeden IPsec client protože IPsec NAT-traversal mode má o fungování běžných NATů dost zkreslené představy. OpenVPN přes NAT funguje jako každé jiné TCP nebo UDP spojení.

    - na druhou stranu OpenVPN nejede proti "profesionálním" VPN bránám (Cisco, F5, ...). Tam je třeba použít IPsec ale je s tím vždycky víc sraní než je nutné. Už třeba kvůli rozdílné terminologii různých výrobců.

    Podle mě IPsec vymysleli někde na akademické půdě páni teoretici a zahrnuli tam řešení mnoha neexistujících problémů, čímž to celé mega zkomplikovali, a bohužel se jim to povedlo protlačit jako standard.

    Zatímco OpenVPN vymyslel někdo z praxe na pragmatické vyřešení VPN a povedlo se mu to na jedničku.

    18.3. 13:53 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Propojeni vice VPN siti
    Silně mi to připomíná litanie lidí, kteří jsou zvyklí na Windows (které jim "just work"), o Linuxu nic nevědí a dozvědět se nechtějí, ale mají naprosto jasno v tom, že "just sucks", protože se chová jinak než ty Windows, na které jsou zvyklí.
    18.3. 14:19 Peter Golis | skóre: 54 | Bratislava
    Rozbalit Rozbalit vše Re: Propojeni vice VPN siti
    Windows just work, kde?

    To neplatí ani pri počítači zakúpenom s predinštalovaným Windows. Pribalený bloatware ten Windows znefunkčňuje.
    18.3. 14:32 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Propojeni vice VPN siti
    Zkuste si to přečíst pořádně. Netvrdil jsem, že to tak skutečně je, jen že takové věci někteří lidé píší.
    18.3. 14:39 Peter Golis | skóre: 54 | Bratislava
    Rozbalit Rozbalit vše Re: Propojeni vice VPN siti
    Kde také veci kto píše? Rád by som sa pozrel či sa náhodou nejedná o vyjadrenia PR firmy Microsoft.
    Max avatar 18.3. 15:37 Max | skóre: 65 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Propojeni vice VPN siti
    Trochu mysli, než něco napíšeš. Je naprosto evidentní, co tím autor chtěl říci a řekl. Vzhledem k tvé reakci jsi to nepochopil, tak se nad tím znovu trochu zamysli.
    Zdar Max
    Měl jsem sen ... :(
    18.3. 15:42 Peter Golis | skóre: 54 | Bratislava
    Rozbalit Rozbalit vše Re: Propojeni vice VPN siti
    Pýtal som sa kde k tomu prišiel, a odpoveďou mi je že tomu nerozumiem. Tomu sa hovorí trefná odpoveď, ale žiaľ na nevyslovenú otázku.

    Nepracuješ náhodou ako konzultant vo firme Microsoft?
    Max avatar 18.3. 16:01 Max | skóre: 65 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Propojeni vice VPN siti
    Tvá otázka je úplně mimo mísu a úplně irelevantní. Navíc byla zodpovězena hned při vyřknutí (říkají to lidé s windows, kteří neznají linuch, pokud s tím máš problém, neventiluj ho na linux foru, ale jdi si počíst na win forum).
    Zdar Max
    Měl jsem sen ... :(
    18.3. 17:17 Peter Golis | skóre: 54 | Bratislava
    Rozbalit Rozbalit vše Re: Propojeni vice VPN siti
    Pýtal som sa kde, a to reálne nebolo zodpovedané.

    A ohľadom linuchu, znie to ako eunuch. Je ten výraz z PR príručky MS rovnako ako tvrdenie "Windows just work"? S tým sa naozaj ventiluj v práci.
    Max avatar 18.3. 17:46 Max | skóre: 65 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Propojeni vice VPN siti
    O co ti vlastně ve skutečnosti jde? Můžeš něco dodat k tématu, nebo se jen toužíš bavit o ničem?
    Zdar Max
    PS: linuch je naprosto běžný výraz (asi CZ/SK výroby, nevím, stejně jako nevím, kde jsi přišel k té MS úchylce)
    Měl jsem sen ... :(
    18.3. 23:05 Peter Golis | skóre: 54 | Bratislava
    Rozbalit Rozbalit vše Re: Propojeni vice VPN siti
    Pokiaľ nedokážeš identifikovať alebo pochopiť jednoduchú otázku, a stále strielaš naučené frázy z PR príručky, tak som sa trafil. Žiaľ.

    PS: Móda nahradzovania písmena x písmenom ch nie je CZ/SK výroby, ale jedná sa o pubertálny h4x0r speak. Ale to je škoda rozoberať s človekom ktorý spomína linuch na linuxovom fóre.
    Max avatar 18.3. 15:58 Max | skóre: 65 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Propojeni vice VPN siti
    Z tvého komentáře mám pocit, že máš zkušenosti jen s klientským řešením pro uživatele, né jako řešení na propojení dvou sítí (poboček) mezi sebou.
    Osobně utíkám od OpenVPN a začínám nasazovat místo něj IPSEC i pro klienty (lidi s tabletem, notebookem apod.). Teď jen dolaďuji drobné věci, abych mohl dopsat dva díly k článku a pak to vydám.
    To, že píšeš nepravdy (více IPSEC klientů za stejným natem není problém, funguje to jak fík) znamená, že do toho evidentně zas tak moc nevidíš.
    Jinak IPSEC na propojení poboček používáme hafec let a bez problémů (dokonce jsem s jednou firmou provozoval NAT over IPSEC - měli jsme shodné segmenty na obou stranách a plně ok, i na rozdílným sw). To se o OpenVPN ale nedá moc říci.

    Každopádně z tvého komentáře je cítit něco jako "IPSEC neznám, přijde mi složitý a hloupý, OpenVPN rulez"
    Zdar Max
    Měl jsem sen ... :(
    vandrovnik avatar 18.3. 20:27 vandrovnik | skóre: 16
    Rozbalit Rozbalit vše Re: Propojeni vice VPN siti
    Na články se těším - zatím používám všude OpenVPN, tak třeba si konečně troufnu se posunout :-)
    22.3. 07:43 bigBRAMBOR | skóre: 30
    Rozbalit Rozbalit vše Re: Propojeni vice VPN siti
    IPSec mezi pobočkami ok, ale kdyz jsme jeste meli data od O2 (uz to je pár let), nemohli se klienti připojit(L2TP/IPsec), na standardním datovém tarifu neprošlo AH a ESP (pokud se jim dokoupila veřejná IP šlo to). OVPN jde protlačit prakticku všude, dost často třeba přes port UPD/53 na sítích kde je provoz placený.

    zkoušel nekdo softether? přijde mi zajímavé mít jeden server a moc se za stejných podmínek možnost připojit asi 4 různejma klientama.
    Max avatar 22.3. 23:56 Max | skóre: 65 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Propojeni vice VPN siti
    L2TP over IPSEc mám rozjetý také. Mám server za NATem a kvůli tomu jsem musel použít linux a zapomenout na freebsd. Funguje mi i komunikace klient NAT - NAT server, funguje mi i více klientů za stejným NATem. Funguje to na Androidu, Linuxu, iPhone i Windows (u win je potřeba v registrech zapnout ignorování checksumů).
    Právě kvůli problému s checksumama u L2TP provozu člověk nemůže použít FreeBSD (pfSense), protože by default jeho kernel toto neumožňujě a patche existují pro starší kernely.
    To byl jeden z důvodů, proč jsem nakonec nasadil IKEv2, který je spolehlivější a má lepší fci na udržení spojení / reconnect apod. (MOBIKE atd.)
    Další věcí je, že doba limitů celkem pominula, takže v dnešní době není problém IPSEC nasadit, jako tomu bylo v době minulé.
    Další věcí je, že do IPSECu probublává podpora kolem TNC (Trusted Network Control) a tím příprava na větší nasazení BYOD zařízení.

    Pokud jde o softether, tak ten jsem po zběžném shlédnutí zavrhnul. Tváří se všemocně, ale není to tak. Pro Win podporuje třeba jen L2TP over IPSEc (už jsme si výše řekli, kde je s ním problém), nebo SSTP (moc neznám).
    Donedávna byla podpora managementu jen z windows, teď přibyl i MAC OSX.
    Teprve koncem minulého roku přibyla podpora TLS 1.2.
    Celý projekt mi přijde ještě relativně mladý a ve vývoji.
    Výhodou IKEv2 je, že je podpora ve všem a v některých zařízeních nabízí právě možnost ověření, zda je klient aktuální, má AV apod. věci, nebo mít víceúrovňové ověřování
    Zdar Max
    Měl jsem sen ... :(
    pavlix avatar 19.3. 15:03 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Propojeni vice VPN siti
    Protože OpenVPN "just works" zatímco IPsec "just sucks".
    No nevím, mně přijde IPsec na Linuxu daleko jednodušší na správu než OpenVPN, navíc se využijí všechny výhody kernelové implementace. Ale jako chápu, že samotný standard je trochu komplikovanější a hůže se adaptuje na dnešní svět zkripleného internetu, ve kterém je nejvyšším dosažitelným ideálem posílat všechno včetně TCP přes 443/TCP stream, protože to proleze všude. :D
    23.3. 14:31 Karlík
    Rozbalit Rozbalit vše Re: Propojeni vice VPN siti
    "Podle mě IPsec vymysleli někde na akademické půdě páni teoretici ..."

    Zdaleka ne, koukněte se do příslušných RFC (a je jich pěkná řada, viz odkaz). Uvidíte tam Naval Research Laboratory, Trusted Information Systems, zaniklé firmy Piermont Information Systems a Daydreamer, Qualcomm, Cisco, NIST, BBN, Airespace a řadu dalších. Slyšel jsem ale pomluvu, že se na návrhu angažovala NSA. Ta se obávala, že lidu do rukou šifrování nepatří, ale vývoj zarazit nemohla, když jej finančně podporovala Clintonova nadace. Tak aspoň výsledek učinili uživatelsky/administrátorsky co nejnepřítulnější.

    https://en.wikipedia.org/wiki/IPsec
    23.3. 17:49 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Propojeni vice VPN siti
    Nebude náhodou jednodušší vysvětlení to, že IPsec vznikal v době, kdy maškarády ještě nebyly zdaleka tak rozlezlé a nikoho nenapadlo, že jejich rozšíření nabude dnešních rozměrů? V té době na aktuální potřeby celkem pohodlně stačil CIDR a počítalo se s tím, že v dlouhodobějším horizontu problém nedostatečné velikosti adresního rozdahu IPv4 vyřeší IPv6. Autoři (a nejen oni) holt podcenili míru pasivní rezistence vůči IPv6 od velkých hráčů na trhu.
    6.4. 00:16 frr | skóre: 32
    Rozbalit Rozbalit vše Re: Propojeni vice VPN siti
    Tento názor plně sdílím. Za posledních asi 20 let mám s IPSecem několik zkušeností, které končívaly flintou do žita po 2-3 dnech tápání v tmách "jaktože to sakra nechodí, nebo nevysvětlitelně hnije, když je to všecko správně nakonfigurované". S jednou výjimkou: kdysi dávno, Cisco proti Ciscu, konkrétní vyselektovaný release IOSu, GRE tunely zvenčí zabalené do IPSecu.

    S OpenVPN většinou tak půlden studia konfigurace pro konkrétní scénář, a nakonec to chodí/chodilo. Na routing mezi pobočkami nad OpenVPN tunely jsem svého času použil nikoli OSPF, ale BGP. Chodilo to prostě líp - na trasách, kde end-to-end "detekce linku" nebyla spolehlivá, popř. nefungovala vůbec.

    Nicméně je pravda, že jsem si v IPSecu zatím neosahal IKE v2 a už delší dobu jsem mu nevěnoval pár dní svého času. Možná se karta přece jenom obrací. Nechtěl bych ustrnout na starých zkušenostech, které třeba už tak docela neplatí.
    [:wq]
    6.4. 07:19 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Propojeni vice VPN siti
    S OpenVPN většinou tak půlden studia konfigurace pro konkrétní scénář, a nakonec to chodí/chodilo.

    Aspoň do chvíle, než se podíváte, jak to vlastně chodí. Třeba když se začnete zajímat o to, proč se čas od času všem na chvíli pozdrží veškeré pakety, a zjistíte, že je to tím, že openvpn dělá všechno v jednom threadu, takže zatímco čeká na autentizaci proti LDAPu, všechen provoz musí počkat. Tenhle konkrétní problém s autentizací je sice teď už opravený, ale primární problém přetrvává, takže při větším počtu uživatelů nejsou latence a hlavně jitter žádná sláva.

    7.4. 08:04 frr | skóre: 32
    Rozbalit Rozbalit vše Re: Propojeni vice VPN siti
    Pravda je, že já jsem vždycky mohl spočítat pevné pobočky na prstech jedné ruky a cestující klienty řekněme na prstech všech čtyř chapadel. A měl jsem zvlášť instanci pro "cestující klienty" a zvlášť další dvě instance pro "páteřní" VPN tunely. Váš komentář je asi nejobsažnější co do informací ohledně OpenVPN, co jsem tady v podobných debatách zatím zaznamenal - děkuji :-)
    [:wq]
    pavlix avatar 6.4. 12:56 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Propojeni vice VPN siti
    Nevím. Nastavil jsem Strongswan na jedné straně, nakopíroval konfiguraci na druhou, spustil a jelo to. Pravda je, že mě vůbec nenapadlo se zabývat čímkoli jiným než IKEv2.
    7.4. 07:59 frr | skóre: 32
    Rozbalit Rozbalit vše Re: Propojeni vice VPN siti
    A navíc jste měl ten luxus, že jste si mohl zvolit konkrétní implementaci v konkrétní verzi, a použít ji na obou koncích. Já měl většinou za úkol rozjet proti sobě dvě různé implementace, sice nepochybně obě open-source původu, ale "zapečené" v nějakém black-box firmwaru, do kterého jsem nemohl sahat.
    [:wq]
    pavlix avatar 7.4. 09:28 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Propojeni vice VPN siti
    Ano. Na tom se nejlépe otestuje technologie samotná bez vlivu toho, co za bullshit si kdo vymyslel.
    8.4. 07:49 frr | skóre: 32
    Rozbalit Rozbalit vše Re: Propojeni vice VPN siti
    Tohle je možná jádro pudla. Já mám skoro vždycky shůry dáno heterogenní prostředí = různé OS platformy. Takže pak sjednocujícím prvkem je OpenVPN. A kouzelné na ní je právě to, že OpenVPN service funguje navzájem proti sobě mezi různými OS platformami a dokonce mezi různými verzemi OpenVPN, pokud nešponujete vývojově nové fičury.

    Jistě máte na jazyku odpověď, že IPSec je taky "jenom jeden", že to je přeci standard, a případné vzájemné nefunkčnosti jsou otázka pečlivého vzájemného testování a release engineeringu jednotlivých různých implementací...
    [:wq]
    pavlix avatar 8.4. 22:34 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Propojeni vice VPN siti
    strongSwan

    the OpenSource IPsec-based VPN Solution

    runs on Linux 2.6, 3.x and 4.x kernels, Android, FreeBSD, OS X and Windows
    Tady nevnímám od OpenVPN zase až takový rozdíl.
    10.4. 09:08 frr | skóre: 32
    Rozbalit Rozbalit vše Re: Propojeni vice VPN siti
    Tak jo :-) Až budu příště stavět "otevřenou" VPN, tzn. budu mít možnost zvolit si software na obou koncích, zamyslím se nad IPsecem. Díky za všechny informace.
    [:wq]
    Max avatar 10.4. 11:55 Max | skóre: 65 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Propojeni vice VPN siti
    Mno,
    ještě jsem snad neměl problém s IPSECem vůči různým implementacím. Ale je pravda, že jsem toho zas tak moc nezkoušel. Asi jen tyto kombinace (ikev1):
    ZyWALL vs Mikrotik
    ZyWALL vs ZyWALL
    ZyWALL vs Astaro (i v režimu NAT over IPSEC)

    a ikev2 (i ikev1 + L2TP):
    windows 7,10 vs strongswan
    iphone vs strongswan
    android vs strongswan
    Zdar Max
    Měl jsem sen ... :(
    Max avatar 9.4. 14:44 Max | skóre: 65 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Propojeni vice VPN siti
    Právě kvůli heterogennímu prostředí jsem byl nucen nasadit IPSEC. OpenVPN je jen pro pár platforem, IPSEC je implementován snad ve všem.
    Zdar Max
    Měl jsem sen ... :(
    19.3. 10:07 hydrandt | skóre: 34 | blog: Kanál | Šanghaj
    Rozbalit Rozbalit vše Re: Propojeni vice VPN siti
    Ja na tohle pouzivam tinc, respektive chaosvpn (dela management konfigurace pro tinc).

    Ale openvpn/ipsec poslouzi stejne tak dobre. Vyhoda tinc je v tom, ze v siti neni centralni uzel.
    I am Jack's wasted life.
    19.3. 14:36 Petr Šobáň | skóre: 79 | blog: soban | Olomouc
    Rozbalit Rozbalit vše Re: Propojeni vice VPN siti
    Píše že má O2 připojení přes ADSL tak nechápu kde je problém O2 Používá IPv6 takže každý PC za tím ADSL má veřejnou IPv6 na kterou se dá dostat.

    Takže si akorát v firewalu povol patřičné porty a máš to....

    PS. Jinak můj comtrend umí IPsec a viděl jsem to i u jiných adsl modemů takže proč to nepoužít.... (Já to nepoužívám používám IPv6 takže nevím jak mod je IPsec v comtrendu spolehlivý.)
    21.3. 21:55 Tom
    Rozbalit Rozbalit vše Re: Propojeni vice VPN siti
    Dobry den, omlouvam se ze reaguji az tak pozde (moc prace...)

    Kazdopadne uz mi to funguje. Zvolil jsem OpenVPN, konfigurace byla nakonec opravdu jednoducha a dela to to co potrebuji. Poupravil jsem jiz bezici Client-Server konfiguraci, pridal client-config-dir s iroute, pro kazdy router vlastni certifikat a statiske routovani na hlavni gateway.

    ad IPSEC) Urcite si rad prectu ten Maxuv planovany clanek, treba se to ukaze jako vhodnejsi. Zatim ale o IPSEC vim jenom to ze existuje... :)

    ad O2 a IPv6) No, s tim jsem na tom momentalne podobne jako s IPSEC.... takze nula. Asi by to bylo i idealni, ale to me teprve ceka. Ale v IPv6 vidim jeden problem, ktery by mi hodne vadil - dost se mi hodi byt schopen vedet jakou IP ma jake zarizeni v dane vzdalene lokaci. S IPv4 je to idealni, s IPv6 si to moc nedovedu predstavit.

    Diky vsem za rady i diskuzi.

    Tom
    23.3. 14:09 Tom
    Rozbalit Rozbalit vše Re: Propojeni vice VPN siti
    Takze precijenom problem...

    Kdyz se pripojim z jakehokoliv PC v lokalni LAN na jakykoliv pocitac v RemoteLAN pomoci SSH, tak se bez problemu pripojim, na vzdalenem PC muzu normalne pracovat, ale po cca 20-30 vterinach se spojeni "zasekne". Zadna hlaska v konzoli, proste prestane reagovat. Ping jede bez vypadku paketu

    Kdyz se na stejny pocitac prihlasim primo z OVPN serveru, tak spojeni drzi bez problemu. Stejne tak spojeni z RemoteLAN -> Local LAN je v poradku, SSH drzi.
    PC v LocalLAN: 172.17.128.0/23
    OVPN Server 172.17.129.6
    OVPN tunel 10.10.0.1 -> 10.10.0.240
    
    PC v RemoteLAN: 10.128.240.0/24
    
    Na hlavnim routeru v LocalLAN (pFsense) jsem pridal novou gateway (OVPN server 172.17.129.6) a staticke routovani pro 10.128.240.0/24 pres tuto novou gateway.

    Toto mam v server.conf:
    
    port 2194
    proto udp
    dev tun
    sndbuf 0
    rcvbuf 0
    ca ca.crt
    cert server.crt
    key server.key
    dh dh.pem
    tls-auth ta.key 0
    topology subnet
    server 10.10.0.0 255.255.255.0
    #ifconfig-pool-persist ipp.txt
    
    client-to-client
    client-config-dir /etc/openvpn/ccd
    
    push "route 10.128.240.0 255.255.255.0"
    push "route 172.17.128.0 255.255.254.0"
    
    route 10.128.240.0 255.255.255.0 10.10.0.240
    
    #push "redirect-gateway def1 bypass-dhcp"
    push "dhcp-option DNS 172.17.129.1"
    push "dhcp-option DNS 172.17.128.15"
    keepalive 10 120
    cipher AES-128-CBC
    comp-lzo
    user nobody
    group nogroup
    persist-key
    persist-tun
    status openvpn-status.log
    verb 3
    crl-verify crl.pem
    
    client CCD:
    
    ifconfig-push 10.10.0.240 255.255.255.0
    iroute 10.128.240.0 255.255.255.0
    push "route 172.17.128.0 255.255.254.0 10.10.0.1"
    
    
    Toto je client.conf
    client
    dev tun
    proto udp
    sndbuf 0
    rcvbuf 0
    remote x.x.x.x 2194
    resolv-retry infinite
    nobind
    persist-key
    persist-tun
    remote-cert-tls server
    cipher AES-128-CBC
    comp-lzo
    setenv opt block-outside-dns
    key-direction 1
    verb 3
    
    
    Mate nekdo tuseni kde muze byt problem? Co hledat? Sledoval jsem logy ssh/sshd, ale tam je jenom uspesne prihlaseni, po tom "zaseknuti se" zadna chyba nezapise.

    Tom.

    Max avatar 23.3. 23:01 Max | skóre: 65 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Propojeni vice VPN siti
    A není to problém ssh klienta? Zkus :
    /etc/ssh/ssh_config
    ...
    Host *
      ServerAliveInterval 240
    
    Zdar Max
    Měl jsem sen ... :(
    5.4. 23:32 Tom
    Rozbalit Rozbalit vše Re: Propojeni vice VPN siti
    Dobry den, tak s drobnym zpozdenim, ale uz to funguje. Problem byl nakonec na hlavnim routeru (pfSense) ktery mel zapnute blokovani provozu ruznych subnetu na stejnem rozhrani. Ted uz to jede, spojeni se drzi bez problemu.

    Ale ukazal se jeste jeden "problem" ktery bych pokudmozno rad vyresil. Chtel jsem vyzkouset jestli z te RemoteLan pujde PXE boot ze serveru v LocalLan. Nejde... Na tom TFTP serveru je v logu toto:
     RRQ from 172.17.129.6 filename pxelinux.0
     tftpd: read: Connection refused
    
    To 172.17.129.6 je lokalni adresa VPN serveru. To je v poradku? Nemela by tam byt spis lokalni adresa toho vzdaleneho pocitace?

    Pri konfigurovani toho OpenVPN serveru jsem iptables nastavil takto:
    iptables -I INPUT -p udp --dport 3194 -j ACCEPT
    iptables -I FORWARD -s 10.10.0.0/24 -j ACCEPT
    iptables -I FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
    iptables -t nat -A POSTROUTING -s 10.10.0.0/24 -j SNAT --to 172.17.129.6
    
    Jde nejak zaridit, aby se ty vzdalene pocitace hlasily svoji skutecnou adresou? Pomuze to tomu PXE? Nebo se to musi udelat uplne jinak?

    Dekuji. Tom

    12.4. 14:50 frr | skóre: 32
    Rozbalit Rozbalit vše Re: Propojeni vice VPN siti
    > Jde nejak zaridit, aby se ty vzdalene pocitace hlasily svoji skutecnou adresou?

    Co třeba zrušit ten SNAT ? :-)

    Mimochodem... jak vypadá výsledná sada IPtables pravidel? Býval jsem zvyklý dávat spíš IPtables -A než IPtables -I (tady je to asi jedno, když včechny řádky mají -j ACCEPT). Taky nevidím, jakou má který chain "default policy".

    Pokud je "connection refused" v logu přímo od tftpd démona, tak TFTP klienta poslal k šípku sám démon, nikoli iptables. Otázka je, co máte za tftpd. Pokud je omezení přístupu zařízeno přes standardní "wrapper", co máte v /etc/hosts.allow a hosts.deny ? Chodí Vám to PXE aspoň napřímo z lokálního subnetu kolem TFTP serveru?

    [:wq]
    10.4. 23:06 Andrej | skóre: 44 | blog: Republic of Mordor | Zürich
    Rozbalit Rozbalit vše Re: Propojeni vice VPN siti
    chtel bych ze zeptar, respektive pozadat o doporuceni, jak nejvhodneni nakonfigurovat nasledujici situaci: …

    IPv6.

    (O2 IPv6 poskytuje, takže tradiční výmluva na poskytovatele v tomto případě odpadá, a neexistuje žádný racionální důvod zabývat se v roce 2017 omezeními protokolu IPv4 z roku 1975.)

    ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
    12.4. 11:32 Tom
    Rozbalit Rozbalit vše Re: Propojeni vice VPN siti

    Ano, verim ze IPv6 by mi to asi par veci vyresilo, ale :

    1. potrebuji byt schopen znat IP adresy tech vzdalenych zarizeni. Proste mi nekdo zavola ze neco nekomunikuje, tak at to muzu rovnou z telefonu treba aspon pingnout. U IPv4 nemam problem i kdyby tech zarizeni bylo treba 500. Ale jak "vydedukovat" IPv6 adresu jen tak z hlavy to netusim....
    2. nekde mame zarizeni ktere IPv6 snad ani neumi....
    Nevim jestli tohle jsou take tradicni vymluvy, ale pro toto pouziti mi prijde IPv4 v poradku.
    S tim jak to ted funguje jsem v zasade spokojen. Kdyby zafungoval ten PXE boot a zobrazovani lokalni IP vzdaleneho zarizeni, tak by to byl prijemny bonus.
    Jde toho nejak docilit pri teto konfiguraci OpenVPN? Mozna na to bude stacit nejak zmena treba v iptables, mozna to nepujde uz z principu... Nevim, proto se ptam a hledam nejakou radu.
    Dekuji
    Tom
    Josef Kufner avatar 12.4. 12:00 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Propojeni vice VPN siti
    Ale jak "vydedukovat" IPv6 adresu jen tak z hlavy to netusim....
    Od toho máme DNS. Klidně můžeš zónový soubor generovat z nějaké databáze zákazníků, kde můžeš mít i fyzickou polohu zařízení (GPS souřadnice), komu patří a co tam zhruba běží. Z telefonu není problém se k takové databázi dostat přes triviální webové rozhranní, které si v PHP spíchneš za večer, a/nebo použiješ Adminer Editor. Vedle zónového souboru můžeš z toho generovat i GPX pro navigaci, až tam pojedeš. Při troše šikovnosti by se dal udělat i CardDAV export, že bys pak měl v mobilu u kontaktu na zákazníka i seznam jeho zařízení a rovnou odkazy na jejich administraci.
    Hello world ! Segmentation fault (core dumped)
    12.4. 14:04 Tom
    Rozbalit Rozbalit vše Re: Propojeni vice VPN siti

    No, jako namet na dlouhe zimni vecery pekny.. :-) Ne, vazne, to co popisujete by bylo moc hezky, ale je to mnohem, mnohem dal nez momentalne dokazu dohlednout.

    Jestli dobre chapu ty navrhy na IPv6, tak bych vlastne vubec nemel resit VPN, ale vyuzit verejne dostupnosti tech lokalnich IPv6 adres?

    To ale neni to jedine o co mi jde. Nejedna se o skutecne zakazniky, ale o nase vlastni pobocky, ktere bych chtel mit ve VPN, veskery provoz smerovat tim VPN tunelem. Pristup na ty pobocky chci opet pouze tim tunelem. Takze nejaka forma VPN stejne musi probehnout. Koukam ze OpenVPN umi IPv6, takze tudy by to asi slo, ale ... co to zarizeni, na kterem jde nastavit pouze IPv4? Jak se na nej pripojim? . Nebo dodavatel toho zarizeni kvuli monitoringu a administraci.  Tam to proste neprojde at je to problem technicky nebo uzivatelsky (ani bych se nedivil, kdyby tento dodavatel IPv6 odmitl jenom proto ze se mu nevejde do bunky v Excelu...) A ja s tim proste nemohu nic udelat.

    Takze rozhodne dekuji za podnety, ale presto bych se rad vratil k te otazce, jak to vyresit pomoci IPv4 a OpenVPN. Jak rikam, momentalne to funguje tak jak potrebuji, kdybych dostal radu (nebo napovedu?) jak upravit konfiguraci tohto stavajiciho reseni aby zafungoval te PXE boot a zobrazovani lokalni IP vzdalenych zarizeni, tak bych byl rad. Nebo jsem prave narazil na omezeni IPv4 pres ktere nejede vlak?  IPv6 si opravdu musim odlozit na neurcito.

    Dekuji.

    Tom

    Josef Kufner avatar 13.4. 00:14 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Propojeni vice VPN siti
    Co popisuju bych udělal i kdyby to bylo jen na IPv4. Tak jako tak musíš vědět kde kdo co má a jak k tomu. Navíc určitě máš nějaký monitorovací nástroj, který by také mohl posloužit.

    VPN bych si klidně udělal jednu servisní na nějaký dobře dostupný server (přes tu by nešel běžný provoz) a mezi pobočkami tahat tunely napřímo, pokud mají veřejné (a nejlépe i pevné) IP adresy. Celé to je jen o nastavení routování – taková pěkná rozcvička s čísílkama (VPN udělá tunel jako malý subnet a na obou stranách potřebuješ mít v síti správné routy; dev tun, topology subnet).

    S PXE bootem mám takové mlhavé tušení, že je tam někde schované omezení na lokální segment sítě. Ale tahat to po VPN je stejně ptákovina, neboť pak bez VPN a přípojení k Internetu nebude fungovat vůbec nic. Dej do každé sítě lokální mirror.
    Hello world ! Segmentation fault (core dumped)
    19.4. 10:44 frr | skóre: 32
    Rozbalit Rozbalit vše Re: Propojeni vice VPN siti
    K tomu PXE mezi subnety: podle mého je potřeba vyřešit dvě věci:

    1) pokud není v satelitní LANce její vlastní BOOTP/DHCP server, tak na routeru (OpenWRT?) nakonfigurovat aspoň DHCP relay na centrální server (patrně skrz VPN).

    2) DHCP klienti v satelitní LANce musí skrz DHCP dostat správnou default gateway na svůj lokální router (OpenWRT?). Pokud tato satelitní LANka nemá svůj vlastní DHCP server, tzn. jede to z různých satelitních LAN skrz relay na společný centrální DHCP server, je potřeba rozlišit toto v "master" konfiguraci centrálního DHCP serveru. DHCP dotaz obsahuje myslím hned několik identifikátorů, na které by šlo pověsit rozlišení gatewaye, ze které dotaz přišel (a návaznou dodávku odpovídající konfigurace v odpovědi).

    Jakmile dostane DHCP klient (PXE stack v BIOSu) správnou IP gateway, nemá už problém dobouchat se přes TFTP napříč mezi subnety (a skrz VPN) až někam do centrály na TFTP server, kde koupí pxelinux.0 a další potřebné věci.
    [:wq]
    18.4. 22:42 Tom
    Rozbalit Rozbalit vše Re: Propojeni vice VPN siti
    Tak konecne uspech. Konfiguraci OpenVPN jsem ponechal beze zmeny, chtelo to jenom ubrat s iptables. Zrusil jsem ten SNAT na OpenVPN serveru, tim se vzdalene pocitace prestali hlasit IP adresou serveru ale IP adresou konkretniho tunelu. Pak jsem tedy zrusil jeste MASQUARADE na tom OpenWRT klientovi a konecne vidim puvodni IP kazdeho konkretniho stroje. Staticke routy jsem doplnil pouze na hlavnim routeru v LocalLAN. Spojeni mezi sitemi funguje obousmerne. Dokonce i ten PXE boot se rozbehl. Ten nemam na regulerni bootovani, ale spis jsem chtel ze site spoustet instalatory. PXE menu se mi zobrazi, vic jsem zatim nezkousel, ale predpokladam ze ted uz by to mohlo fungovat. To mne teprve ceka, snad to bude pouzitelne.

    Ted uz resim jenom prenastaveni DNS na tom OpenWRT routeru po navazani vpn spojeni, ale to uz snad nejak vybojuju.

    Tak jeste jednou diky vsem za rady a komentare.

    Tom
    19.4. 09:48 frr | skóre: 32
    Rozbalit Rozbalit vše Re: Propojeni vice VPN siti

    Ohledně PXE bootu: třeba u Debianu (a Ubuntu a spol) stačí na distribučním mirror serveru najít (naklikat) příslušný podadresář, z něj vzít soubory "linux" a "initrd.gz", a do /tftpboot/pxelinux.cfg/default přidáte něco jako

    label jessie
      kernel jessie/linux
      append initrd=jessie/initrd.gz priority=low vga=normal  --
    

    (což jsem tuším kdysi oprásknul z ISO instalačky Debianu z isolinux.cfg).

    Debian netinstall bootne z initial ramdisku minimální prostředí, řekne si o cestu na distribuční server, a dál už tahá potřebné součástky přes FTP nebo HTTP do ramdisku.

    Pokud máte něco s instalačkou ve formátu .ISO (image CD/DVD) tak samozřejmě i image CDčka se dá loadnout do ramdisku a bootnout, a to skrz pxelinuxova pomocníka zvaného "memdisk". Ten pak zajistí emulaci CD-ROM skrz služby BIOSu. Třeba instalačku DOSu takhle bootnete bez problému a dalšího zařizování. Problém nastane ve chvíli, kdy z toho CD nastartuje nějaký trochu schopný kernel, který kašle na služby BIOSu (Linux s CD instalátorem, NT kernel + Win32) a začne se pídit, kde má to CDčko připojeno k hardwaru. A protože kašle na INT13h BIOS services, tak ten disk nenajde.

    I k tomuto problému existují workaroundy, bohužel pod Windows to každopádně znamená minimálně vsunout speciální driver do instalačního média = upravit ISO obraz, případně si hrát s WIM obrazy u moderních Windows, případně si poskládat vlastní Windows PE image... Není to špatná vychytávka, mít své vlastní PXE-bootable Windows PE s pár základními vyprošťovacími a klonovacími utilitami pro Windows :-)

    Jenom mám trochu obavu, jak bootování tlustých ISO obrazů pojede skrz VPNku - záleží, jak tlustou máte konektivitu mezi pobočkami. Nastartovat Windows PE loadnutím ISO image (desítky až stovky MB) do RAMdisku přes PXE+TFTP trvá docela dlouho i v LANce. TFTP je docela otravný protokol v tom ohledu, že tuším ACKuje každý UDP paket = visí to na latenci per-packet odezvy, tzn. na ping round tripu. V tomto ohledu má jednoznačně navrch netbootable instalátor Debianu, který si vše potřebné tahá over TCP (pomocí FTP nebo HTTP) a navíc selektivně jenom to, co potřebuje. BTW, ještě mě napadá, že gPXE/iPXE snad umí jako transport použít i FTP/HTTP... tzn. napadá mě třeba chainloadnout iPXE skrz primitivní PXE+TFTP a teprve pak rozpoutat pravé HTTP netboot inferno :-) A i bez tohoto "dvoufázového PXE" by asi šlo zařídit, že by se do RAMdisku loadnul jenom relativně minimální image Windows PE, který by obsahoval driver nikoli pro RAMdisk, ale pro iSCSI (nebo AoE), a ten by mountnul na dálku blokové zařízení (třeba plný ISO image = instalačku) - takže by se to nemuselo tahat celé nastojato do RAMdisku. Nebo bootnout z RAMdisku PEčka s "podporou sítě" (včetně CIFS) a instalátor spustit ze síťového disku, ale to už si hodně vymejšlím a vidím v tom mnohá úskalí... každopádně na backup/restore třeba skrz gimagex to stačí. (Jenom ten PE image "se vším potřebným" je už docela tlustý.)

    Jinak na "deployment" = hromadnou instalaci má Microsoft své vlastní oficiální/kanonické netbootable nástroje, dřív se to tuším jmenovalo RIS, běží to na Windows Serveru. Něco podobného bych čekal od Symantecu (modernější generace Ghostu).

    ...k tomu DNS pro OpenVPN remote klienty: Windowsum servíruju z OVPN "serveru" cca toto (kráceno, ale je to vlastně učebnicový příklad):

    push "ip-win32 dynamic"
    push "dhcp-option DNS 192.168.5.6"
    push "dhcp-option DOMAIN mydomain.com"
    

    Odhadem na OpenWRT "klientovi" bude ještě nějaká konfigurační práce s tím, aby si ty pseudo-DHCP opšny od OpenVPN klienta převzal a zapracoval ("up" script). Na druhou stranu je to myslím poměrně běžný a logický požadavek, čekal bych, že je to v OpenWRT "hotové".

    [:wq]
    16.6. 11:01 Tom
    Rozbalit Rozbalit vše Re: Propojeni vice VPN siti
    Dobry den, omlouvam se znovuoteviram tento stary dotaz, ale prisel jsem na jeden souvisejici problem, tak snad to nevadi....

    Spojeni sice funguje, vsechno jede, mam primy pristup na vsechny stroje v RemoteLan, ale vsiml jsem si ze kdyz se ten VPN tunel zatizi nejakym vetsim prenosem, tak hodne zvedne ping (1-3s) a zacne naskakovat packet lost. Po ukonceni prenosu se vse vrati do normalu ( ping cca 25ms)

    Docetl jsem se ze by mohlo pomoci zmensit MTU na tom VPN tunelu, tak jseem na server i na klienta pridal
    tun-mtu 1400
    mssfix 1360
    
    tun0 uz ukazuje MTU:1400, ale je to porad stejne.

    Nemate nejaky napad cim by to mohlo byt? co bych mel zkontrolovat? Dekuji. Tom
    16.6. 19:53 frr | skóre: 32
    Rozbalit Rozbalit vše Re: Propojeni vice VPN siti
    Tohle by chtělo doplňující informace. A bohužel docela dost doplňujících informací :-) Úzkým hrdlem může být buď nízká kapacita spoje (a třeba do toho úzkého hrdla ani přímo nekoukají Vaše routery), nebo třeba procesorový výkon některého z VPN routerů po cestě. Zhruba na co koukat:

    - okamžitý CPU load na jednotlivých routerech

    - odkud kam ve Vaší topologii naskočí ten dlouhý delay = na kterém hopu.

    Vyskytují se tu lidi s praktickými zkušenostmi - pokud jim řeknete, jaké jsou kde procesory a při jak rychlém přenosu (kBps/pps) Vám to stropuje, třeba se podělí o názor, jestli to je/není v pořádku.

    Pokud se CPU na routerech flákají, může být ten dlouhý round-trip způsobený dlouhou frontou na vstupu do úzkého hrdla: na egressu, do L3/L2 rozhraní, a to buď na krabičce ve Vaší správě, nebo v krabičce některého providera po cestě = mimo Vaši pravomoc :-(

    Teorie hromadné obsluhy praví, že pokud na nějakou zpracující jednotku (úzké hrdlo) hrnete požadavky v průměru rychleji, než kolik stíhá zpracovat, délka fronty přestane konvergovat k nule, resp. začne od nuly divergovat (k nekonečnu). Jak dlouhá fronta naroste (v počtu požadavků resp. v časových jednotkách = zpoždění) než se začnou pakety zahazovat, to je na routeru dáno nějakým konfiguračním parametrem, a je otázkou, zda je tento konfigurační parametr laditelný administrátorem :-) Fronta o nějaké netriviální délce má dvojí význam: pobere nadrobený/dávkovitý provoz a v jistých mezích (reálná zátěž těsně pod maximem) zajistí optimální využití spoje tím, že některé pakety pozdrží = "vyhladí tok dat v čase" - a druhá věc je, že slušně vychované TCP při mírném přetížení sítě či jednotlivého spoje zareaguje zpomalením přenosu (právě díky zpoždění ve frontě kdesi po cestě), aniž by došlo ke ztrátám paketů. Zpoždění ve frontě interaguje s TCP Window na koncových bodech. Tzn. netvrdil bych kategoricky, že dlouhé fronty jsou zlo. Všechno je relativní, záleží na aplikaci. Ta problematika má spoustu dalších nuancí, viz třeba priorizace (fronty s předbíháním), kde má smysl shapovat/priorizovat (nejlépe přímo na vstupu do úzkého hrdla, nikoli o kus dál), random early detection (říkal jste, že roste ztrátovost?) apod. A zřejmě platí axiom, že surovou kapacitu (průchodnost) ničím nenahradíte, nebo přinejmenším shapingem nenahoníte.

    Pokud by se Vám vyskytla situace, že se procesory flákají, linky se flákají, a přesto vidíte dlouhé latence, tak to by teprve bylo to pravé žůžo :-) Pak začnete zkoumat, co máte kde za síťovky, nakolik efektivně pracují s interrupty a buffery apod. Pokud to má smysl na daném hardwaru řešit.
    [:wq]

    Založit nové vláknoNahoru

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.