Page 2 sur 5

VPN + agrégation / bonding de lignes ADSL et/ou cable

Publié : mer. 8 oct. 2014 16:27
par vhnet
Dommage qu'OVH est arreté son offre internet only, c'etait une bonne idée

VPN + agrégation / bonding de lignes ADSL et/ou cable

Publié : mer. 8 oct. 2014 16:46
par dsebire
d'ailleurs ils vont faire du VDSL en collecte FT mais a 50€/mois (au lieu de 30), trafic illimité

VPN + agrégation / bonding de lignes ADSL et/ou cable

Publié : mer. 8 oct. 2014 16:52
par X-System
Dommage qu'OVH est arreté son offre internet only, c'etait une bonne idée
Mon forfait Orange, je l'ai inscrit en fin 2003 ou début 2004. Je garde toujours ce forfait à chaque déménagement. Dans mon forfait, c'est écrit "Internet Max" :D

http://assistance.orange.fr/internet-max-1115.php

VPN + agrégation / bonding de lignes ADSL et/ou cable

Publié : sam. 11 oct. 2014 17:02
par augur1
avec cette solution, si on veut accéder de l’extérieur à un serveur @home, obligé d'avoir un client vpn sur l'ordi ou le smartphone distant ?
:hello:

VPN + agrégation / bonding de lignes ADSL et/ou cable

Publié : sam. 11 oct. 2014 20:23
par vhnet
:hello:
Alors la réponse est : "pas forcement" !

En gros, j'avais fait de mon serveur OVH mon point de sortie/entrée uniquement pour le tout venant !
A savoir que :
une personne voulait acceder a une machine de mon LAN, elle entrait l'adresse du serveur OVH, qui redirigeait vers le tunnel d'agregation.
si le tunnel etait HS ou qu'un lien etait tombé, il faisait un bete routage vers mon IP publique Free.

Coté chez moi, je n'acceptait les connexions qu'en provenance du serveur OVH ou de rare IP que je connaissait.

Mais oui, il est aussi possible d'utiliser un VPN.

VPN + agrégation / bonding de lignes ADSL et/ou cable

Publié : sam. 11 oct. 2014 20:35
par augur1
Ok, super !

@home j'ai besoin de :
Ftpes sur le 21 et les cnx passifs
Https pour Razuna

... et d'un VPN compatible cisco ou juniper en IPssec PSK / IPKE pour me connecter à la Fibaro HC2 via Blackberry, iPhone de waf et pc portable.

VPN + agrégation / bonding de lignes ADSL et/ou cable

Publié : sam. 11 oct. 2014 20:59
par vhnet
Alors attention si le WAF rentre en ligne de compte.

Moi j'avais fait une regle firewall special WAF !
A savoir qu'elle surfait sur le net avec son PC/tablette/iphone via la Freebox en direct ou l'autre cnx, jamais via l'agregation !
Comme ca pas d'emmerde quand ca tombait en panne de temps en temps

VPN + agrégation / bonding de lignes ADSL et/ou cable

Publié : sam. 11 oct. 2014 21:02
par augur1
Yep :
- Lan : agrégé
- wifi pour waf : via Ap ubiquiti ou routeur linksys en ddwrt

;)

VPN + agrégation / bonding de lignes ADSL et/ou cable

Publié : jeu. 13 nov. 2014 11:42
par augur1
Tuto ESXi / Pfsense / VPN ... sur Kimsufi
-> http://www.dmilz.net/share/ESXi_Kimsufi_2.0.pdf

VPN + agrégation / bonding de lignes ADSL et/ou cable

Publié : jeu. 17 sept. 2015 23:48
par augur1
Mise à jour du 22 janvier 2015
=> http://unix.ndlp.info/doku.php/informat ... sl_bonding

Le soft pour ne pas se faire ch*** la bi** à config / louer / administrer serveurs en data center & co
=> http://speedify.com/features/

VPN + agrégation / bonding de lignes ADSL et/ou cable

Publié : ven. 18 sept. 2015 11:18
par augur1
Le soft pour ne pas se faire ch*** la bi** à config / louer / administrer serveurs en data center & co
=> http://speedify.com/features/
Si vous voulez tester : http://speedify.com/referral/sign-up/?s ... Qj4AElwN41

2 lignes de campagne en 8 Mb :
-> FREE avec TV allumée, PC sur fbx en RJ45
-> SOSH, PC en Wfi N sur lbx dans la cave

[center]Image[/center]

Serveur de Francfort :
[center]Image[/center]

Serveur de Paris (OVH) très jolie courbe Karotz :D
[center]Image[/center]

Envoi FTP vers Free : débit de ~ 230 Ko/s :sol:




VPN + agrégation / bonding de lignes ADSL et/ou cable

Publié : ven. 18 sept. 2015 20:23
par augur1
A tester également, à la place de pFsense pour faire du bonding Wan : Zeroshell
-> http://www.zeroshell.net/fr/

... des avis avant test ?

VPN + agrégation / bonding de lignes ADSL et/ou cable

Publié : dim. 20 sept. 2015 00:31
par vhnet
Très bon zeroshell j'avais commencé l'agrégation ADSL avec y a 5 ans

VPN + agrégation / bonding de lignes ADSL et/ou cable

Publié : dim. 20 sept. 2015 10:52
par augur1
:jap:

Un ami qui fait de l'aggreg depuis quelques années me disait qu'à présent, son serveur etait un Crazy Fish chez Ikoula, avec 2 ip en plus (24€ ht le tout).
Avec ovh / online / soyoustart, il devait a chaque fois entrer des capchat lors de recherches sur google : pour lui, les blocs ip de ces derniers Ient blacklistés...

Qu'en pensez vous ?
Que faire si je m'oriente vers un so you start ou new vps 2016 avec 2 ip en plus ?

VPN + agrégation / bonding de lignes ADSL et/ou cable

Publié : dim. 20 sept. 2015 13:04
par vhnet
Je ne sais pas si avec les VPS 2016 tu peux avoir plus de 1IP...

J'ai jamais eu ce problème de captcha avec mon serveur OVH.

rien ne t'empeche a la limite de prendre un VPS (3€ht) pour tester...

VPN + agrégation / bonding de lignes ADSL et/ou cable

Publié : dim. 20 sept. 2015 13:35
par augur1
Pour le moment les VPS 2015 et 2016 ne peuvent pas avoir davantage d'IP.
Le Kimsufi KS2 sur lequel je bricole, acquis en 2014 ne peut pas avoir davantage d'IP non plus.

La possibilité d'avoir des IP supplémentaires sur les VPS 2016 est à venir.

Si jamais une IP vennait à être blacklisté, comment faire pour la remettre en whitelist ?

VPN + agrégation / bonding de lignes ADSL et/ou cable

Publié : dim. 20 sept. 2015 14:35
par poulpito
:jap:

Un ami qui fait de l'aggreg depuis quelques années me disait qu'à présent, son serveur etait un Crazy Fish chez Ikoula, avec 2 ip en plus (24€ ht le tout).
Avec ovh / online / soyoustart, il devait a chaque fois entrer des capchat lors de recherches sur google : pour lui, les blocs ip de ces derniers Ient blacklistés...

Qu'en pensez vous ?
Que faire si je m'oriente vers un so you start ou new vps 2016 avec 2 ip en plus ?
ca a été vraii pendant un moment
depuis 1an ~ no soucy pour online toute ma maison s'en sert comme proxy web (pour blocage youtube princiapelement et autre genre fnac spectacle qui veut pas te filer une place
alors que depuis la connect proxy c'est direct)

VPN + agrégation / bonding de lignes ADSL et/ou cable

Publié : jeu. 24 sept. 2015 23:50
par augur1
Ovh propose sa solution, avec un boitier : http://korben.info/agreger-plusieurs-co ... hebox.html

Ou via une distri basée sur OpenWRT sous linux : https://github.com/ovh/overthebox-openwrt

VPN + agrégation / bonding de lignes ADSL et/ou cable

Publié : ven. 25 sept. 2015 15:45
par kalistyan
Multi-Link Virtual Public Network
MLVPN is Open Source and licensed under the BSD License.

https://github.com/zehome/MLVPN

VPN + agrégation / bonding de lignes ADSL et/ou cable

Publié : ven. 25 sept. 2015 23:43
par Zedoune
est-ce que pour UN flux (genre un envoi continu en session TCP) on peut stacker les connexions ?

VPN + agrégation / bonding de lignes ADSL et/ou cable

Publié : ven. 25 sept. 2015 23:46
par augur1
Http / https / ftp et p2p : bonding / agreg possible.. si par stacker tu veux dire ça ;)

J'up à 230ko/s avec 2 lignes adsl dont la tv allumée sur la box de l'une d'elle.

Cf : http://smpfr.mesdiscussions.net/smpfr/B ... tm#t131185
... si tu veux tester speedify : http://speedify.com/referral/sign-up/?s ... Qj4AElwN41 avec plusieurs adsl et/ou 3G / 4G et/ou point d'accès wifi différents.

VPN + agrégation / bonding de lignes ADSL et/ou cable

Publié : sam. 26 sept. 2015 00:22
par Zedoune
j'essaierai à l'occasion, avec la fibre pas trop l'intérêt d'augmenter le débit... ^^'

VPN + agrégation / bonding de lignes ADSL et/ou cable

Publié : sam. 26 sept. 2015 00:38
par augur1
Non en effet.

D'autant que suivant ces fournisseurs de service d'agrégation, il y a des limites de debits, chacun sa sauce.

VPN + agrégation / bonding de lignes ADSL et/ou cable

Publié : mer. 30 sept. 2015 21:43
par augur1

VPN + agrégation / bonding de lignes ADSL et/ou cable

Publié : dim. 4 oct. 2015 13:44
par augur1
Bonding multi Wan avec routeur Mikrotik via PCC (connection classifier) et Mangle :
-> https://blog.linitx.com/load-balancing- ... nnections/
December 4, 2014
MikroTik therefore designed a new method called PCC (Per Connection Classifier) to get around this problem that allows us to mangle packets and arrange them to use different routing tables, one per line. In this way we can have say three lines, with three default routes, but the PCC mangle rules we will create will force each of the connections into using the different routing tables. No connections get torn down. So, much more reliable. OK – let’s show you then how to do this with some code…

First thing to note is that by default, bridge interfaces were designed for transparently bridging Layer 2 traffic and therefore it is logical that the traffic passing between the bridge ports and the bridge will not normally need to be processed by the Layer 3 firewall rules. To force Layer 2 traffic on a bridge to be processed by the Layer 3 firewall rules, we need to explicitly enable this.
[cpp]
/interface bridge settings
set use-ip-firewall=yes[/cpp]

If the traffic on the ports is encapsulated with PPPoE, then this will also need to be explicitly allowed to go into the Layer 3 Firewall rules as well.

[cpp]/interface bridge settings
set use-ip-firewall-for-pppoe=yes[/cpp]

We need to ensure that any traffic going to our local and internal LAN interfaces on the router bypasses all the ‘line balancing’ rules. This is traffic that is destined for the internal network and will not be required to be mangled by any rules to make it split connections up the multiple backhaul lines. Therefore we must ensure we initially set a rule for all internal traffic to bypass the mangle rules that follow below. We do this with an action of ‘accept’. Assuming all internal traffic is on 192.168.88.0/24 and all internal interfaces are on the default bridge ‘bridge-local’ we would use this:
[cpp]
/ip firewall mangle
add chain=prerouting dst-address=192.168.88.0/24 in-interface=bridge-local action=accept [/cpp]

The above CLI command is in the ‘pre-routing’ chain and therefore is processed before any routing decisions are carried out and will thus capture traffic to the router and traffic being forwarded by the router elsewhere. The above rule tests for all traffic destined for the local internal network (192.168.88.0/24) which is coming INTO the local LAN interface (in-interface=bridge-local). This can only be local L2 traffic going into the router interface. As this is a bridge interface, it may be traffic destined for one of the other ports in the bridge and therefore must not be processed by the following rules. It therefore has an action of ‘accept‘. In this way the rule ‘actions’ but effectively does nothing but stop any further processing of those types of packets. This is because when a mangle rule is actioned, any further and lower down rules are not processed. The only exception is that for certain action types, the value ‘passthrough‘ can be enabled which will allow further rules to be processed.

For each of the public WAN interfaces, the reply traffic for any connections made directly to them from the public WAN must always go out the same way it came in. This could be traffic such as Winbox or SSH into the Public WAN IPs. We do not wish the reply traffic being potentially sent out of a completely different interface than it came in on just because of our clever PCC mangle rules. As traffic going into the router will go through the ‘input’ chain and traffic leaving the router itself will be going through the ‘output’ chain we now use two sets of rules, one in the input chain, one in the output chain for each public interface we are load balancing upon. In this example we will be demonstrating load balancing across two lines.

We must first mangle connections and then mark with routing marks. (This is because we are not requiring to mangle individual packets, but the whole connection). Therefore for these mangle rules, we need to identify the incoming public WAN traffic and to save CPU processing, mark the connection with a ‘connection mark’ only if it hasn’t already been marked (the connection mark ‘no-mark’ is a reserved name and it means that there is no connection mark applied yet). :

[cpp]/ip firewall mangle
add chain=input in-interface=pppoe-out1 connection-mark=no-mark action=mark-connection new-connection-mark=WAN1 passthrough=no
add chain=input in-interface=pppoe-out2 connection-mark=no-mark action=mark-connection new-connection-mark=WAN2 passthrough=no[/cpp]

Having now got the incoming new connections marked with a connection mark of WAN1 or WAN2 as appropriate, we now need to ensure that the outgoing connections will go the same way back out again. We do this by giving all those outgoing connections a routing-mark and it will be those different routing marks that will force the traffic to use the different routing tables, one per WAN interface.

[cpp]/ip firewall mangle
add chain=output out-interface=pppoe-out1 connection-mark=WAN1 action=mark-routing new-routing-mark=WAN1 passthrough=no
add chain=output out-interface=pppoe-out2 connection-mark=WAN2 action=mark-routing new-routing-mark=WAN2 passthrough=no[/cpp]

We now need to perform the PCC ‘magic’ that will split the internal connections equally amongst all WAN lines. Here, the following rules take the internal LAN traffic that is outgoing and will split the traffic connections into two ways. Every unique combination of destination address and source address will be given a different connection mark (and will in turn, go out of a different WAN connection). There are a number of different PCC methods to determine how to split the connections. One popular one is on ‘destination IP and port’. However if you do that, a client device may open up many threads of connections to a remote server and each one will go out of a different outgoing WAN connection. With connections to HTTPS SSL based websites, such as banking sites, this may lead to major problems. We are going to just use the destination and source address to split the connections between the two lines as our unique indicator that these are connections we can detect and are to be pushed up the multiple and different WAN lines. Once again we use the ‘no-mark’ connection mark test as once a connection has been marked, there is no need to do it again and this saves on CPU power. We can only apply routing marks in the output and prerouting chains. As we need to identify traffic that is being forwarded by the router, not any traffic that is destined for it and the output chain is only for traffic that has been generated by the router itself, the prerouting chain is the only one suitable. However the prerouting chain actually contains two types of traffic, forwarded traffic (which we want to capture) and traffic destined for the router itself (which we do not want to capture for marking).

Therefore, to only mark outbound forwarded traffic we can use a rule that tests for ‘dst-address-type is NOT local’. I.e. that the traffic is not destined for a network address which is on the router. Note also that the PCC mangle rule states either ‘:2/0’ or ‘:2/1’. This equates to ‘divide the traffic connections by two’ and that will then leave you either with no remainder (the ‘/0’ part) or with 1 as a remainder (the ‘/1’ part). In this way the traffic is split into two unique sets of connections by the PCC rule. If you were splitting the traffic three ways, the 3 rules would have ‘3/0’, ‘3/1’ and ‘3/2’ in them. I.e. 3 divided by 3 is one, remainder zero (the ‘3/0’), 2 divided by 3 is zero with a remainder of two (the ‘3/2’) and 1 divided by 3 is again zero, but with a remainder of one (the ‘3/1’).
[cpp]
/ip firewall mangle
add chain=prerouting connection-mark=no-mark dst-address-type=!local in-interface=bridge-local per-connection-classifier=both-addresses:2/0 action=mark-connection new-connection-mark=WAN1
add chain=prerouting connection-mark=no-mark dst-address-type=!local in-interface=bridge-local per-connection-classifier=both-addresses:2/1 action=mark-connection new-connection-mark=WAN2[/cpp]

By default ‘passthrough=yes‘ is enabled on mangle rules such as those above. Now that we have marked the two way split in connections, we now need to attach a Routing mark to those two connections so that we can direct each connection to two different routing tables rather than the usual ‘main’ routing table (we have yet to create two new routing tables called WAN1 and WAN2 which will use these routing marks):

[cpp]/ip firewall mangle
add chain=prerouting connection-mark=WAN1 in-interface=bridge-local action=mark-routing new-routing-mark=WAN1 passthrough=no
add chain=prerouting connection-mark=WAN2 in-interface=bridge-local action=mark-routing new-routing-mark=WAN2 passthrough=no[/cpp]

The traffic will now be able to be split two ways, with each alternate connection being redirected to two different routing tables, WAN1 and WAN2. These two new routes are created as follows:
[cpp]
/ip route
add dst-address=0.0.0.0/0 gateway=pppoe-out1 routing-mark=WAN1
add dst-address=0.0.0.0/0 gateway=pppoe-out2 routing-mark=WAN2[/cpp]

The traffic being generated by the router itself however will not have any routing marks and also, ‘next hop’ calculations are only possible by the ‘main’ routing table therefore we will still need ‘normal’ routing table entries for the default routes going out the multiple WAN connections. We need two in this case. We apply different distances to them so that if there is a WAN line failure, the traffic will go out the second line instead.

[cpp]/ip route
add dst-address=0.0.0.0/0 gateway=pppoe-out1 distance=1
add dst-address=0.0.0.0/0 gateway=pppoe-out2 distance=2[/cpp]

If the routing table gateways are remote IP addresses, rather than dynamic PPPoE interfaces as per the example above, ensure you also add ‘check-gateway=ping’ to each of those routes to ensure that the main routing table can calculate the state of the upstream gateway and change the routing table to route out of the other interface correctly in case a gateway goes down!

If the router will be applying a NAT Masquerade function and you do not have a static IP on the public WAN interfaces, use an action of ‘masquerade’. If however you have static IPs assigned to each WAN interface, it is better to use an action of ‘src-nat’ and to input the correct specific IP address assigned for that interface.

Example for dynamic IPs:

[cpp]/ip firewall nat
add chain=src-nat out-interface=pppoe-out1 action=masquerade
add chain=src-nat out-interface=pppoe-out2 action=masquerade[/cpp]

Example for static IPs of 1.2.3.4 and 4.3.2.1:
[cpp]
/ip firewall nat
add chain=src-nat out-interface=pppoe-out1 action=src-nat to-addresses=1.2.3.4
add chain=src-nat out-interface=pppoe-out2 action=src-nat to-addresses=4.3.2.1[/cpp]

Once all the above rules are applied, you should then begin to see traffic being very roughly distributed across the multiple lines. Remember that as the traffic is based on connections, rather than raw packets, the traffic will never be completely even. Any one client’s connection may have a high traffic demand and that will be seen to increase just the one physical WAN connection to a greater throughput figure compared to the other. This is normal and to be expected. The more client connections made and the more WAN lines added into the ‘load balancing’ set will even these ‘irregularities’ out over time. Also, if any one line has a different speed than another, any connections made up that slower WAN link will cause the client to have a slower experience. Remember, this is not ‘line-bonding’ but ‘load balancing’! If possible, try to join together similar types and speeds of WAN lines, but luckily with PCC it’s not essential. The example below shows how the internal LAN is connected to ether1 and the upstream WAN connections are pppoe-ou1 and pppoe-out2. The internal network is uploading approximately 838k from various client connections and the load is roughly balanced across the two lines, 401k and 426k each:
Aussi :
-> http://mikrotikbook.blogspot.fr/2014/04 ... using.html
-> https://aacable.wordpress.com/2011/06/0 ... t-by-zaib/