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

Envie de tchacher, n'hésitez pas !
vhnet
Messages : 1748
Inscription : ven. 12 janv. 2018 17:44
Localisation : Vaucluse - 84

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

Message par vhnet »

Dommage qu'OVH est arreté son offre internet only, c'etait une bonne idée
Avatar de l’utilisateur
dsebire
Messages : 12716
Inscription : ven. 12 janv. 2018 17:44
Localisation : Loiret - entre la ville et les champs

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

Message par dsebire »

d'ailleurs ils vont faire du VDSL en collecte FT mais a 50€/mois (au lieu de 30), trafic illimité
Avatar de l’utilisateur
X-System
Messages : 6841
Inscription : ven. 12 janv. 2018 17:44

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

Message 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
PC1 = MW70-3S0 # 2x E5-2689 v4 # 32Go DDR4-2400 ECC reg # RTX 3080 Ti # 2x1To SSD
PC2 = Z170XP-SLI # i7-7700 # 32Go DDR4-2400 # 240Go NVMe # SAS9211-8i # 10 SSD/HDD SATA # LTO-5 SAS
PC3 = T460p # i7-6700HQ # 16Go DDR4-2133 # 940MX # 240Go SSD
Avatar de l’utilisateur
augur1
Messages : 13138
Inscription : ven. 12 janv. 2018 17:44
Localisation : où tout est neuf et tout est sauvage
Contact :

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

Message 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:
vhnet
Messages : 1748
Inscription : ven. 12 janv. 2018 17:44
Localisation : Vaucluse - 84

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

Message 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.
Avatar de l’utilisateur
augur1
Messages : 13138
Inscription : ven. 12 janv. 2018 17:44
Localisation : où tout est neuf et tout est sauvage
Contact :

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

Message 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.
vhnet
Messages : 1748
Inscription : ven. 12 janv. 2018 17:44
Localisation : Vaucluse - 84

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

Message 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
Avatar de l’utilisateur
augur1
Messages : 13138
Inscription : ven. 12 janv. 2018 17:44
Localisation : où tout est neuf et tout est sauvage
Contact :

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

Message par augur1 »

Yep :
- Lan : agrégé
- wifi pour waf : via Ap ubiquiti ou routeur linksys en ddwrt

;)
Avatar de l’utilisateur
augur1
Messages : 13138
Inscription : ven. 12 janv. 2018 17:44
Localisation : où tout est neuf et tout est sauvage
Contact :

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

Message par augur1 »

Tuto ESXi / Pfsense / VPN ... sur Kimsufi
-> http://www.dmilz.net/share/ESXi_Kimsufi_2.0.pdf
Avatar de l’utilisateur
augur1
Messages : 13138
Inscription : ven. 12 janv. 2018 17:44
Localisation : où tout est neuf et tout est sauvage
Contact :

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

Message 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/
Avatar de l’utilisateur
augur1
Messages : 13138
Inscription : ven. 12 janv. 2018 17:44
Localisation : où tout est neuf et tout est sauvage
Contact :

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

Message 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:



Avatar de l’utilisateur
augur1
Messages : 13138
Inscription : ven. 12 janv. 2018 17:44
Localisation : où tout est neuf et tout est sauvage
Contact :

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

Message par augur1 »

A tester également, à la place de pFsense pour faire du bonding Wan : Zeroshell
-> http://www.zeroshell.net/fr/

... des avis avant test ?
vhnet
Messages : 1748
Inscription : ven. 12 janv. 2018 17:44
Localisation : Vaucluse - 84

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

Message par vhnet »

Très bon zeroshell j'avais commencé l'agrégation ADSL avec y a 5 ans
Avatar de l’utilisateur
augur1
Messages : 13138
Inscription : ven. 12 janv. 2018 17:44
Localisation : où tout est neuf et tout est sauvage
Contact :

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

Message 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 ?
vhnet
Messages : 1748
Inscription : ven. 12 janv. 2018 17:44
Localisation : Vaucluse - 84

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

Message 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...
Avatar de l’utilisateur
augur1
Messages : 13138
Inscription : ven. 12 janv. 2018 17:44
Localisation : où tout est neuf et tout est sauvage
Contact :

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

Message 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 ?
Avatar de l’utilisateur
poulpito
Messages : 12402
Inscription : ven. 12 janv. 2018 17:44
Localisation : Grenoble

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

Message 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)
Avatar de l’utilisateur
augur1
Messages : 13138
Inscription : ven. 12 janv. 2018 17:44
Localisation : où tout est neuf et tout est sauvage
Contact :

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

Message 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
kalistyan
Messages : 14259
Inscription : ven. 12 janv. 2018 17:44
Localisation : LYON
Contact :

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

Message par kalistyan »

Multi-Link Virtual Public Network
MLVPN is Open Source and licensed under the BSD License.

https://github.com/zehome/MLVPN
Avatar de l’utilisateur
Zedoune
Messages : 15343
Inscription : ven. 12 janv. 2018 17:44

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

Message par Zedoune »

est-ce que pour UN flux (genre un envoi continu en session TCP) on peut stacker les connexions ?
Avatar de l’utilisateur
augur1
Messages : 13138
Inscription : ven. 12 janv. 2018 17:44
Localisation : où tout est neuf et tout est sauvage
Contact :

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

Message 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.
Avatar de l’utilisateur
Zedoune
Messages : 15343
Inscription : ven. 12 janv. 2018 17:44

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

Message par Zedoune »

j'essaierai à l'occasion, avec la fibre pas trop l'intérêt d'augmenter le débit... ^^'
Avatar de l’utilisateur
augur1
Messages : 13138
Inscription : ven. 12 janv. 2018 17:44
Localisation : où tout est neuf et tout est sauvage
Contact :

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

Message 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.
Avatar de l’utilisateur
augur1
Messages : 13138
Inscription : ven. 12 janv. 2018 17:44
Localisation : où tout est neuf et tout est sauvage
Contact :

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

Message par augur1 »

Avatar de l’utilisateur
augur1
Messages : 13138
Inscription : ven. 12 janv. 2018 17:44
Localisation : où tout est neuf et tout est sauvage
Contact :

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

Message 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/
Répondre