add ffuplink-package to use the routers-wan connection #125
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced Oct 29, 2017
|
It would be nice to have an underhood construction which can be used by any wizard or sthg. to configure the system. Much more which kind of connection could be used. |
|
at the moment branch "packages/notunnel" of the firmware gets build an can then be tested. |
|
one issue with this code is, that the veth-link to the ffuplink interface is setup via a hotplugscript. this should be converted to a uci-setting, as we have patched the lede-17.01 netifd to support this. |
SvenRoederer
force-pushed
the
feature/notunnel
branch
2 times, most recently
from
56466b2
to
f363ea3
Compare
SvenRoederer
force-pushed
the
feature/notunnel
branch
3 times, most recently
from
95a577d
to
55aa54a
Compare
SvenRoederer
force-pushed
the
feature/notunnel
branch
from
55aa54a
to
21f38cd
Compare
|
This code has been tested and verified to work with
Probably it's morre elegant to put the uci-setting ffberlin-uplink.uplink.auth directly into network.ffuplink.authtype. |
|
merged into Hedy-1.0.0-rc1 |
this is some uplink-type to directly route the freifunk- traffic via the uplink on the wan-interface. So there will be no tunnel at all. include both setup-stages inside the hotplug-script stage 1: WAN * setup up veth-pair * add one end of veth-pair to br-wan * enable interface "ffuplink" stage 2: ffuplink * set default-route for ff-clients via gateway over "ffuplink"-device * via policy-routing in table "olsr-tunnel"
add uci "ffberlin-uplink.uplink.auth"to give each uplink-provider
a way to have the assistent asking for different kinds of
authentication. Following types are supported:
- none: the uplink-type don't need additional parameters
- x509: the uplink-type requires a set of X.509 certificate
(stored in /etc/openvpn/, as for VPN03 and tunnel-berlin)
- pass: todo - just ask for a simple password / psk
- userpass: todo - ask for username and password
to ensure current settings and do not interfer with any previous setup or tunnel-type of ffuplink
- this requires a recent enough netifd (was implemented in 2017-02-11) - also take care of reconfiguring alternative uplink-types and don't have them relying on any assumption of "ffuplink"
implement dedicated ip-rule to manage traffic for ffuplink-interface
this hotplug-script probibits all traffic to nodes on the upstream-network of ffuplink-interface. Only traffic to not directly attached networks is accepted. This script also sets up the default route for all traffic reaching the "ffuplink" routing-table. this all honors the settings of * ffwizard.sharenet * freifunk-policyrouting.enable
On every setup of ffuplink add some ip-rules to route all traffic received on interfaces of zone freifunk out via ffuplink. When shutting down the interface we remove the manually created rules, to not create the same rules over and over again.
as this is done by the tunnel-provider scripts
…-route so add prohibit with prio 19989
to keep it in sync with a "no-tunnel" uplink. As we had no separate ip-rules for ffuplink before, it was put into "olsr-tunnel", which did not made sense at all.
As OpenVPN networkparameters are not configured via UCI, "network_get_subnet" returns noting. In this case we query the IP-config directly. If this also returns nothing valid, we will not setup a policy to protect the uplink-lan and give an error-log.
SvenRoederer
force-pushed
the
feature/notunnel
branch
from
e6fed16
to
e7c0f03
Compare
|
btw: a similar feature seems to be on the way for gluon (freifunk-gluon/gluon#1094) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
add a package to use the wan-connection directly (w/o VPN)