Jak naroutovat

[Ħαℓ₸℮ℵ ␏⫢ ⦚ »]

Zdar, mám 2 připojení k internetu . První má tragický upload (například drátové ADSL), dostatečný download. Druhé připojení má dostatečné rychlé obojí (mobilní interet od českého operátora po prázdninách), ale má FUP. to znamená, že chci, aby přes něj nešel download (jelikož v běžných situací platí informační asymetrie, tedy že download tvoří většinu trafficu)
Tedy
Je možné je zkombinovat, aby přes první šel upload a přes druhý download? Co je k tomu nutné mít ? Je potřeba nějaká akce u providera nebo to kompletně jde udělat bez jeho spolupráce?

Nezajímají mě rady pořídit si lepší spojení,, zajímá mě technická možnost té představy.

[Reklama]

[Radek Zajíc]

Hypoteticky by to slo se dvema L3 VPN:
- z vnitrni site by se provoz posilal ven skrze VPN pres mobilni sit
- z vnejsi site by se provoz na VPN koncentratoru smeroval skrze VPN pres DSL

(pozor na to, ze mobilni operatori pocitaji do FUP i uploadovana data)
Zaroven by tento set-up vyzadoval mit pod kontrolou i VPN koncentrator.

Pak staci:
- na vnitrnim routeru: default route via <vpn-pres-mobilni-sit>
- na vpn koncentratoru: route na vnitrni sit via <vpn-pres-dsl>

Idealne nemaskaradovat na vnitrnim routeru, ale az na vpn koncentratoru nebo pred nim. A samozrejme je potreba dat pozor, aby provoz nesezralo RPF.

[Miroslav Šilhavý]

Je možné je zkombinovat, aby přes první šel upload a přes druhý download? Co je k tomu nutné mít ? Je potřeba nějaká akce u providera nebo to kompletně jde udělat bez jeho spolupráce?

Krátce: Pokud se na tuto otázku vůbec ptáte, tak se tím nezabývejte.

Detailně: Pokud svedete dvě VPN do jednoho bodu (tj. budete mít např. někde na hostingu, u providera další router), pak se obě konektivity mohou seběhnout a můžete se o to pokusit. V praxi se to nepovede - důvodů je víc, podle toho, na jaké vrstvě byste to chtěl řešit. Ve všech případech je ale problémem rozdílná latence a nemožnost rozumně řídit průtok oběma směry.

Pokud máte dvě linky, tak v profesionálním nastavení Vám provider nastaví BGP failover - jedna linka je primární, na druhou se to překlápí až v případě výpadku.

Druhou možností je rozlišit služby - např. brouzdání webu pustit před DSL, poštu přes LTE, ...


...


Zkrátka ptáte se na něco, co není univerzálně řešitelné (kdyby bylo, už by někdo vyráběl kouzelnou škatulku, která by to řešila).

[Filip Jirsák]

Jenom s těmi dvěma připojeními by to šlo udělat jedině v případě, že by ISP, přes kterého půjde upload, nekontroloval, zda jsou zdrojové IP adresy paketů z jeho rozsahů. Pak byste jednoduše pro veškerou komunikaci používal IP adresu ISP, přes kterého má jít download (tj. odpověď by šla přes ISP pro download), ale pakety byste ve skutečnosti odesílal přes ISP pro upload (na něj byste nastavil výchozí bránu).

[Ondrej Nemecek]

Předně bych se ptal, co rozumíme downloadem a co uploadem? Například internetový prohlížeč provede request na server a v rámci toho requestu data posílá i přijímá. Přičemž může převažovat jeden nebo druhý směr a nejspíš ani nejde předvídat, který směr převáží, dokud ten přenos neproběhne. A i kdyby to předvídat šlo (podle hlaviček), nepůjde již existující tcp/ip spojení přerušit a transparentně přehodit za provozu na jinou linku, alespoň pokud moje omezené znalosti postačují. Anebo se pletu a na nějaké nižší vrstvě to možné je? Udělat nějaký bonding přes více poskytovatelů a rámci něj provoz nějak dynamicky řídit?

V praxi by podle mě mohlo fungovat rozdělení provozu dle protokolu anebo dle cílového serveru. Na základě analýzy stávajícího provozu by to šlo nastavit tak, aby byly linky průměrně vytíženy dle záměru (pokud se například ukáže, že většinu provozu představuje YouTube a to ve směru download, mohu jej nasměrovat na linku s neomezeným downloadem).

[Reklama]

[Ħαℓ₸℮ℵ ␏⫢ ⦚ »]

No to je zajímavý problém. To s tím určení, co je upload a download myslíš i takové detaily jako TLS handshake, kdy střídavě to jde tam a odtam? To by mě zajímalo jak tady tohle udělat.

Případně jde zařídit, aby obě připojení měla stejnou IP?

Dotaz je spíš takový, jestli něco vůbec takovéhle je teoreticky možné a jak se vypořádat s vzniknuvšivími problémy.

[Miroslav Šilhavý]

Dotaz je spíš takový, jestli něco vůbec takovéhle je teoreticky možné a jak se vypořádat s vzniknuvšivími problémy.

Na to je krátká odpověď: není to reálné, proto to nikdo nedělá.

[Filip Jirsák]

No to je zajímavý problém. To s tím určení, co je upload a download myslíš i takové detaily jako TLS handshake, kdy střídavě to jde tam a odtam? To by mě zajímalo jak tady tohle udělat.

TLS handshake na to nemá žádný vliv. Podle vašeho popisu je rozlišení download vs. upload směr putování paketu – download jsou pakety jdoucí k vám, upload pakety od vás. V rámci jednoho TCP/IP spojení tedy máte download i upload.

Download a upload by se dal rozlišovat i podle toho, odkud je navázáno spojení – za prvé asi budou všechna spojení navazována od vás, za druhé když to řešíte kvůli kvalitě a FUPu, jde právě o ten směr paketů, ne odkud bylo navázáno spojení.

Případně jde zařídit, aby obě připojení měla stejnou IP?

Ne.

Dotaz je spíš takový, jestli něco vůbec takovéhle je teoreticky možné a jak se vypořádat s vzniknuvšivími problémy.

Teoreticky to možné je. Jak už tu padlo, buď si někde v internetu pořídíte vlastní uzel (např. VPS), odkud bude navazována skutečná komunikace s cílovými zařízeními, a obě připojení použijete jen pro připojení k tomu uzlu (např. přes VPN). Nebo – pokud ISP pro upload nekontroluje zdrojové IP adresy paketů – můžete jako zdrojovou IP adresu použít tu IP adresu od ISP, kterého chcete použít pro download (tím pádem odpověď půjde přirozeně tudy), ale pakety od sebe odesílat přes ISP pro upload (pokud nebude kontrolovat zdrojovou IP adresu, tak paket projde).

Každopádně pokud se na to takhle ptáte, měl byste si spíš najít někoho, kdo to případně dokáže realizovat.

Na to je krátká odpověď: není to reálné, proto to nikdo nedělá.

Multi-homed sítě jsou běžná věc a pravidla pro řízení provozu bývají mnohem složitější, než upload jednou linkou a download druhou.

[Miroslav Šilhavý]

Na to je krátká odpověď: není to reálné, proto to nikdo nedělá.

Multi-homed sítě jsou běžná věc a pravidla pro řízení provozu bývají mnohem složitější, než upload jednou linkou a download druhou.

Ehm, přečtěte si tazatelovy dotazy. To, co on chce - tj. spojit dvě linky a nic moc neřešit - to prostě jednoduše nejde.
Proto preferuju krátkou odpověď než filozofování na téma řízení provozu (nad DSL a LTE ).

[Filip Jirsák]

Ehm, přečtěte si tazatelovy dotazy.

Nápodobně.

To, co on chce - tj. spojit dvě linky a nic moc neřešit - to prostě jednoduše nejde.

Jenže tazatel chce něco jiného. On chce použít jednu linku pro upload a druhou pro download. „Nic moc neřešit“ nebo „jednoduše“ v tazatelově příspěvku také hledám marně – naopak výslovně psal, že ho zajímá, zda je to technicky možné.

Mimochodem, přesně tenhle princip se používá (i když typicky u jednoho ISP) tam, kde není dostupná kapacitní přípojka, ale je potřeba mít kapacitní download. Download jde přes satelit (který má dostatečně kapacitní pásmo), a uplink může jít třeba přes vytáčené spojení.

Proto preferuju krátkou odpověď než filozofování na téma řízení provozu (nad DSL a LTE ).

Kdo tady psal o řízení provozu? Vždyť je to triviální – pakety odesílat jednou linkou, a nechat si je posílat (download) druhou linkou. Nic víc tazatel nepotřebuje.

[Miroslav Šilhavý]

Kdo tady psal o řízení provozu? Vždyť je to triviální – pakety odesílat jednou linkou, a nechat si je posílat (download) druhou linkou. Nic víc tazatel nepotřebuje.

Ehm, a že jste mu poradil.

[Filip Jirsák]

Ehm, a že jste mu poradil.

Ano, poradil. O VPN už psal někdo přede mnou, bylo by zbytečné to opakovat, takže jsem v komentáři č. 3 uvedl ještě druhou možnost.

Zato vaše „rady“ jsou fakt užitečné. Pivotal nepsal nic o tom, že přes to chce pořádat videokonference, takže vaše poznámky o rozdílných latencích a nemožnosti řídit průtok oběma směry jsou úplně mimo.

[_Jenda]

Na to je krátká odpověď: není to reálné, proto to nikdo nedělá.

Nefunguje takhle wifi v autobusech a vlacích? Mají tam 3G/LTE připojení od různých operátorů, tlačí se to přes všechny a na druhé straně je jeden koncentrátor ze kterého to padá do netu.

[Ħαℓ₸℮ℵ ␏⫢ ⦚ »]

Nefunguje takhle wifi v autobusech a vlacích? Mají tam 3G/LTE připojení od různých operátorů, tlačí se to přes všechny a na druhé straně je jeden koncentrátor ze kterého to padá do netu.

Tím koncentrátorem myslíš co? Něco jako VPN v dáli(po té, co to z autobusu přes LTE dojde na internet), který to z těch výstupních míst LTE konektivit zase shrábne do jednoho?

A jaký by to mělo význam ten koncentrátor? Předpokládám, že pro každého připojeného člověka-zařízení jde upload a download přes jednu konkrétní LTE linku.


Další

kapacitní přípojka, ale je potřeba mít kapacitní download. Download jde přes satelit (který má dostatečně kapacitní pásmo

co je kapacitní  pásmo, kapacitní download a kapacitní přípojka?

[Filip Jirsák]

kapacitní přípojka, ale je potřeba mít kapacitní download. Download jde přes satelit (který má dostatečně kapacitní pásmo

co je kapacitní  pásmo, kapacitní download a kapacitní přípojka?

V ČR se to nabízelo v době, kdy připojení k internetu vůbec nebylo běžné, domácnosti – pokud teda vůbec měly nějaké připojení – se připojovaly vytáčeným připojením přes telefonní linku, firmy měly třeba ISDN. Kdo potřeboval víc, potřeboval, aby k němu fyzicky vedl kabel nějakého ISP. Pokud někde bylo potřeba víc než ta telefonní linka, firma to mohla zaplatit a zároveň by kabel byl neúměrně drahý (protože by se musela udělat nová přípojka dlouhá několik kilometrů), bylo možné použít to satelitní připojení. Typický provoz koncového uživatele je dost asymetrický, mnohem víc je downloadu než uploadu (proto je možné nabízet asymetrické ADSL/VSDL, kde je poměr download:upload 10:1 nebo i víc). Takže pro upload stačila ta telefonní linka (která měla, když to šlo dobře, 56 kbit/s), download šel přes satelit (protože dostat signál ze země na satelit není taková sranda, jako dostat ho ze satelitu na zem, takže uplink přes satelit by byl výrazně dražší záležitost).

Kapacitní pásmo, přípojka, linka atd. tedy bylo myšleno to, že vám nestačila kapacita/rychlost vytáčeného připojení 56 kbit/s, ale potřeboval jste nějakou závratnou rychlost, třeba 512 kbit/s nebo 1 Mbit/s nebo dokonce ještě víc…