On Mon, Aug 28, 2017 at 10:48:56PM -0400, Rafael Wolf wrote: > I wanted a TINC tunnel like this, where I have a server on the Internet > with a public IPv4 address as my TINC server. Then I can have clients > connect to it and see each other except that the client at a customer > site would allow me to route behind it so I could see hosts on site beyond > my device on premise. [...] > Internal Devices <-- Customer Site with a rasperry pi --> Internet --> > Public Server <-- Laptop, PC, whatever > > Server with public IPv4 address: [...] > /etc/tinc/devtun/tinc-up > > #!/bin/sh > ifconfig $INTERFACE 192.168.2.1/29 > route add -net 192.168.0.0/24 gw 192.168.2.1 dev $INTERFACE
The route statement is correct. However, "gw 192.168.2.1" does not do
anything when tinc is in router mode. You can leave it out.
> /etc/tinc/devtun/hosts/devtun
> TunnelServer = yes
> Address = 10.0.10.3
> Subnet = 192.168.2.1/32
>
> -----BEGIN RSA PUBLIC KEY-----
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> -----END RSA PUBLIC KEY-----
>
> * Note that I also tried putting in another "Subnet" for the 192.168.0.0
> but it
> didn't seem to do anything.
You should only put in Subnet statements for those address ranges that
belong to that node itself. It seems like 192.168.0.0/24 is the address
range for the internal devices at the customer site, so this does not
belong to devtun.
> Client config (rasperry pi at the client site):
[...]
> /etc/tinc/tinc-up
>
> #!/bin/sh
> ifconfig $INTERFACE 192.168.2.2/29
> # This route breaks networking! Definitely don't use this!
> # route add -net 192.168.0.0/24 gw 192.168.2.2 dev $INTERFACE
You should indeed not add this route. If 192.168.0.0/24 belongs to the
internal network, then adding a route for 192.168.0.0/24 to the VPN
interface will ensure demo can no longer talk to its internal network.
> /etc/tinc/demo/hosts/demo
>
> TunnelServer = yes
> Address = 67.219.201.3
> Subnet = 192.168.2.2/32
> Subnet = 192.168.0.0/24
> Mode = router
>
> -----BEGIN RSA PUBLIC KEY-----
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> -----END RSA PUBLIC KEY-----
[...]
> Got ADD_SUBNET from demo (75.134.104.213 port 54059): 10 3d2ef9c2 demo
> 192.168.2.2/32#10
> Ignoring unauthorized ADD_SUBNET from demo (75.134.104.213 port 54059):
> 192.168.2.2/32#10
[...]
> Both server and client can ping each other.
>
> So...why would I be getting that "unauthorized subnet" from the demo site?
Because you are using the TunnelServer option, which implicitly also
enables the StrictSubnets option. Try it without TunnelServer = yes.
> Once I iron out the subnet issue how can I "route" from the server or other
> clients connected to the server beyond the client (which is my pi)?
Your configuration looks correct to me, as long as you remove the
TunnelServer option.
> OH and also...when I have the client config files like this on each host:
>
> server has:
> devtun <-- what I actually fire up with tincd to "listen"
> demo
>
> client has:
> devtun
> demo <-- what I actually fire up with tincd to "connect"
>
> ...does the client really care what the "devtun" config file has in it
> besides the authentication key?
Yes, if you use TunnelServer = yes then it will also use the Subnets
from that file, and will not allow devtun use any other Subnet.
Otherwise, no.
> ...does the server really care what the "demo" config file has in it
> besides the autnetication key?
Yes, it also reads the Subnets because TunnelServer = yes, and it reads
the Address statement so it knows how to connect to demo.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <[email protected]>
signature.asc
Description: PGP signature
_______________________________________________ tinc mailing list [email protected] https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
