Spojení dvou internetových připojení do jednoho

8.6.2009 08:27 | Přečteno: 4049× | | poslední úprava: 8.6.2009 13:19

Byl jsem postaven před problém kdy jsem potřeboval u notebooku mobilní (stačí v Praze) připojení s co nejrychlejším uploadem, i za cenu nějaké práce a dalších výdajů. Chvíli jsem hledal, přemýšlel a radil se. Výsledek průzkumu byl takový, že použiju 2 mobilní připojení. Přes každé z nich povede VPN tunel k serveru, který bude připojen na rychlou linku. Tyto dva vpn tunely pak budou spojeny do bondu a veškerý provoz z notebooku bude routován přes bond na server na druhém konci tunelů.
Připojení k internetu tak bude dostatečně rychlé a zároveň chráněné, kdyby jedno spojení vypadlo.

Výběr ISP

Zadání je takové, že potřebuju mobilitu a co nejrychlejší upload.
Na lupě mě nedávno rozrušil článek o WiMAXu od Radiokomunikací-pokrytí super, rychlost taky, ale nejedná se o mobilní WiMAX. Takže tudy ne přátelé.
Vodafone - nejlepší co mají má FUP 3GB za měsíc, takže tady nic.
T-mobile - má 3G, ale taky FUP 10GB za měsíc - děkuji nechci.
U-fon - FUP, FUP, FUP, bez FUPu (ale jako zařízení si musíte koupit místo modemu telefon). Achjo.
O2 - jednou FUP a jednou bez FUPu. CDMA i UMTS/HSDPA. V Praze chystají pro CDMA i Rev.A. Na výběr dávají z několika USB modemů, všechny by měli jít napájet z USB. K některým lze najít návod na rozběhání v linuxu i zde na Ábíčku.

Ač je nemusím. Vítězem je O₂

Jako prozatimní použiju pracovní cdma modem APE-540h a právě dorazivší cdma/umts modem Anydata ADU-630WH koupený na aukru, provizorně domáci wifi. Je možné že v reálném provozu budu používat 2x ADU-635WH, který O2 aktuálně nabízí. Oproti 630WH má podporu pro CDMA Rev.A

Rychlosti jednotlivých připojení
CDMA:

UMTS:

Server

Nejprve jsem zkusil Snajpu a jeho vpsfree.cz, které prezentuje i zde, ale OpenVZ se ukázalo jako nepoužitelné - není možné nahrát moduly do jádra.
Takže jsem hledal a našel VS hosting na Xenu - hukot.cz. Server stojí 350 korun na měsíc, moduly jdou načíst v pohodě, rychlost připojení (4,34 MB/s - debian iso stahované z ameriky) by měla stačit.
Takže server máme, zprovozníme ho, nainstalujeme OpenVPN, ifenslave a nezapomenem na mc ;)

Rozdělení provozu podle cílového portu

S tato část mi dala zabrat. Pomohl až Michal Kubeček. Potřebujeme označkovat pakety VPN, pro každý tunel jinou značkou. Podle této značky pak rozlišíme jakým rochraním budou pakety odcházet. Výsledek vypadá asi takto:

iptables -A OUTPUT -t mangle -p udp --dport 5000 -j MARK --set-mark 1
iptables -A OUTPUT -t mangle -p udp --dport 5010 -j MARK --set-mark 2

ip route add default dev ppp0 table 1
ip route add default dev ppp1 table 2

ip rule add priority 1000 fwmark 1 table 1
ip rule add priority 1001 fwmark 2 table 2

OpenVPN

Instalace by měla být bez problému, stejně tak konfigurace. Dokumentace je vcelku slušná.
Vygenerujeme certifikáty pro server a dva pro klienta (pro každé připojení jeden).

Konfigurák OpenVPN serveru může vypadat nějak takto:

dev tap0
 # druhy server ma tap1

tls-server
dh dh1024.pem
ca ca.crt
cert server.crt
key server.key

port 5000
#	druhy server ma 5010

user nobody
group nogroup

verb 3
log server1-pri.log
status server1-pri.status

script-security 2
# bez toho mi to vracelo chybu (jakou uz ale nevim)

a klienta:

dev tap0
#   druhy klient ma tap1
remote ip.adresa.server.ru

tls-client
ca ca.crt
cert client1-pri.crt
key client1-pri.key
port 5000
#   druhy klient port 5010

user nobody
group nogroup

verb 3
log client1-pri.log
status client1-pri.status

script-security 2
local 192.168.1.14

Použil jsem tap, protože bonding funguje na vrstvě Ethernetu (tun pracuje s IP pakety). Opravte mě jestli se pletu - s tun by to udělat vůbec nešlo.

(Nešlo by použít tun a udělat to na IP vrstvě?)

OpenVPN je potřeba říct že tunel má být má mít odchozí ip adresu pouze příslušného rozhraní, k tomu slouží direktiva local a abysme nemuseli mezi každým spuštěním cdma/umts taky měnit v konfiguráku OpenVPN tuto ip adresu, tak mu to narveme přímo při spuštění v init skriptu:

...
    . /etc/openvpn/vpnconf-to-ip 

    start-stop-daemon --start --quiet --oknodo \
        --pidfile /var/run/openvpn.$NAME.pid \
        --exec $DAEMON -- $OPTARGS --writepid /var/run/openvpn.$NAME.pid \
        $DAEMONARG $STATUSARG --cd $CONFIG_DIR \
        --local $IP \
        --config $CONFIG_DIR/$NAME.conf || STATUS=1
...

a zmíněný skript /etc/openvpn/vpnconf-to-ip dělá to, že z konfiguráku si zjistí port. Z portu zjistí MARK. Z MARKu zjistí do jaké routovací tabulky pakety půjdou, o jaké rozhraní půjde a konečně - jakou má ip adresu. A ten skript vypadá takto (a ano vím že je to prasácky napsaný):

PORT=`grep port /etc/openvpn/$NAME.conf | grep -v \# | cut -d " " -f 2 `
# echo $PORT

MARK_HEX=`/sbin/iptables -L -t mangle |grep "udp dpt:$PORT" | awk '{print $10}' | cut -d "/" -f 1`
# echo $MARK_HEX

# MARK=` echo "ibase=16;obase=10;$MARK_HEX" | bc`
# echo $MARK

TABLE=`/bin/ip rule ls | grep $MARK_HEX | awk '{print $7}'`
# echo $TABLE

INTERFACE=`/bin/ip route ls table $TABLE | grep default | awk '{print $3}'`
# echo $INTERFACE

IP=`/bin/ip address list dev $INTERFACE | grep inet | awk '{print $2}'`
#echo $IP

Bonding

Bondování mi (zatím) funguje bez problémů, takže na serveru stačí spustit:

modprobe bonding mode=0 miimon=10000

ip link set address 00:11:22:33:44:55 dev bond0
ip add add 10.0.10.1/30 dev bond0
ip link set up dev bond0

ifenslave bond0 tap0
ifenslave bond0 tap1

Pro klienta se použijí stejné příkazy, jen se změní ip a mac adresa bondu.

TODO: pohrát si s nastavením miimon, má to vůbec smysl? když jsem zkusil vytánout síťovku tak bonding viděl tap jako stále dostupný, vpn jen do logu psala chybové hlášky ... asi bude lepší udělat monitoring pomocí arp_interval

Konec?

Pak už jen zbývá na serveru rozběhat maškarádu, změnit defaultní routu na klientovi na 10.0.10.1 a fungujeme:

debian:/home/houska# mtr -t -r seznam.cz
HOST: debian                      Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 10.0.10.1                     0.0%    10  156.3 209.3 156.3 295.8  41.4
  2. 89.187.136.66.coolhousing.ne  0.0%    10  198.2 199.2 153.2 230.1  26.8
  3. r2-bb.coolhousing.net         0.0%    10  152.7 189.4 141.3 227.8  29.3
  4. nix.seznam.cz                 0.0%    10  233.7 255.4 149.4 502.2  95.6
  5. www.seznam.cz                 0.0%    10  176.9 221.0 162.5 396.0  65.9
debian:/home/houska#

A ještě test rychlosti obou spojených připojení:

WTF?!

Nevěřím svým očím, takže to zkouším ještě desetkrát a zjišťuju že rychlost naměřená na začátku krát dva se zatím nekoná:
Down (max/avg/min): 454, 240, 138 (kb/s)
Up (max/avg/min): 122, 106, 95 (kb/s)

Zkusil jsem snížit MTU obou bondů na 1400, ale podle 3 zkušebních testů to vůbec nepomohlo.

Zkusil jsem CDMA i UMTS rozběhat pod windows, jestli náhodou nemám na ppp spojeních špatně nastavené MTU, ale i ve windows je 1500.

Zkoušel jsem různé typy bondů, hrál jsem si i s délkou odchozí fronty u tap a bondu (txqueuelen) protože v logu VPNky mám neustále chybové hlášky No buffer size available.

Pak jsem také testoval s pomocí nástroje iperf. U UMTS jsem dosahoval uploadu 360Kbit/s, na CDMA 130Kbit/s. Při obou spojeních společně cca 270Kbit/s. Což by zhruba odpovídalo 2x 130 Kbit/s z CDMA.
Takže daší krok bude zkusit použít 2x UMTS namísto současného CDMA s UMTS

Poznámky

HINT: pokud to někdo bude rozbíhat, tak doporučuju natvrdo nastavit DNSku dostuponou odkudkoliv, třeba OpenDNS.

TODO:
- modem APE 540h mi stále zatuhává - vyřešit (očůrávka - zasunout modem, spojit ppp, počkat až se resetne sběrnice, odpojit a pak zase spojit)
- pohrát si s udev aby se usb_modeswitch spouštěl automaticky, ač to mám nastavené pořád se tomu nechce
- pohrát si s udev aby se po zapojení modemu vytvořilo nějaké rozumné linky na tty. Např. /dev/ttyANYDATA0cdma pro cdma prvního modemu, /dev/ttyANYDATA1umts pro umts druhého modemu.
- firewall

       

Obrázky

Komentáře

[snajpa]

Nejprve jsem zkusil Snajpu a jeho vpsfree.cz, které prezentuje i zde, ale OpenVZ se ukázalo jako nepoužitelné - není možné nahrát moduly do jádra.

Jo, sypu si popel na hlavu, že jsem to nikam na webovky nenapsal, že se OpenVZ nehodí k čemukoliv co pracuje na nižší vrstvě než aplikační (až na pár vyjímek). Je to daň za nízkou režii pro virtualizaci.

[houska]

Mám půjčené druhé UMTS, díky patří JeDovi.

[trekker.dk]

Použil jsem tap, protože bonding funguje na vrstvě Ethernetu (tun pracuje s IP pakety). Opravte mě jestli se pletu - s tap by to udělat vůbec nešlo.

Nemělo tady být s tun by to vůbec nešlo?

(Btw. zkus ten blogpost nabídnout Robertovi, třeba ti to vydá jako článek)

[houska]

opraveno, dik

taky me to napadlo, chtelo by to nejaky obrazky atd. ... mozna az to dodelam

[Grunt]

No, nevim. Mám na starosti jednu menší síť a tento princip tunelování by se mi zrovna moc nezamlouval. Když už tak ECMP(Equal Cost Multi-Path) Routing. Ten používám i já.

[houska]

Rozlévání trafficu funguje per connection, nikoliv per packet. zdroj

coz je v mem pripade problem

[Grunt]

Jo, přesně tak

coz je v mem pripade problem

Proč?

[houska]

protoze to delam pro jedinou aplikaci, ktera posila data po UDP

[otasomil]

Moc pekne napsany clanek. Nicmene platit za dve pripojeni hmm to je trochu luxus.

[Limoto]

Přesně, navíc, když jsou stejně obě nechutně pomalý...

[otasomil]

No tak z pohledu zabezpeceni spojeni v pripade vypadku je toto reseni OK. Ovsem za dvojnasobnou cenu jen kvuli vyssimu uploadu tak to je vo nicem.

[cezz]

Kedysi som skusal podobne riesenie. (3x adsl) 

V pripade vypadku jednej linky vykazoval ping cca 30% packet loss, kedze bonding nevedel detekovat vypadok linky (afaik tap nema potrebne ioctl) ale inak v podstate spolahlive.

Co sa tyka rychlosti ak si dobre spominam bolo to 3x rychlost jedneho spojenia minus cca 20%. A pokial viem, dalo sa nejako urcovat v akom pomere bude bonding rozhadzovat packety do jednotlivych tunelov (toto opat nemal ako zistit system sam) ale ja som nepotreboval, kedze linky boli identicke, mozno by si sa este mal skusit pohrat s tym. Inak ich tusim rozhadzoval rovnomerne do oboch, cim sa prakticky cakalo na ten pomalsi. Ale to uz bolo dost davno, teraz uz si naozaj nespominam.

 

[houska]

bonding umi detekovat vypadlou linku bud pres
- mii monitor - mrkni se na mii-tool tzn jestli je kabel fyzicky pripojen
- arp monitor - pta se jestli mac adresa existuje

mrkni do manualu

[cezz]

To samozrejme vie, ale vtedy ide o realne sietovky kdezto tu sa bavime o  tun / tap device.

[houska]

... pro ktery ten druhy monitoring neni problem

[cezz]

No neviem, uz si nespominam, ako sa to presne spravalo, ale asi ano, ten arp monitoring by to mal po nejakom timeoute zistit.. Kazdopadne ani som to nejako neriesil a vypadky som detekoval na inej urovni aj s notifikaciou a tak.

[houska]

jj je to presne jak rikas snazi se na tom rozhrani udelat arp dotaz z na tu zadanou ip adresu, timeout se zadava pri loadovani modulu