tinc - Feb 2019 - Problem with connecting another subnet

>> The setup looks like this:
>> web <- tinc "tiosp" -> gateway <- tinc
"tiutl" -> backup
Which lan ips do all your computers have? network addess will be fine.


ALBI...

On 8.2.19. 22:39, albi wrote:
>>> The setup looks like this:
>>> web <- tinc "tiosp" -> gateway <- tinc
"tiutl" -> backup
> Which lan ips do all your computers have? network addess will be fine.
>
>
> ALBI...
Hi Albi,

web:
  tinc tiosp: 172.16.1.10
  local: 10.0.0.5
gateway:
  tinc tiutl: 172.16.0.5
  tinc tiosp: 172.16.1.5
  local: 10.0.0.10
backup:
  tinc tiutl: 172.16.0.11
  local: 10.0.0.101

I'm using something similar to Amazon's VPCs, where a logical group of
instances has a local subnet from the cloud provider. This local subnet
is always 10.0.0.0/24. As there are multiple VPC's, these private local
subnets dont collide.

Web is in a logical group / local subnet / in its own VPC with other
instances (more webworkers and loadbalancers and things like that).

Gateway and Backup are together in their own VPC with other instances
(like a gitlab and what not).

I'm using Ansible to roll out tinc. The connect_to's always have static
public IPs in their tinc host config files, while others may only have
private IPs there, for example:

root at backup-1:~# cat /etc/tinc/tiutl/hosts/monitoring_1
Address = 10.0.0.102


Do you think that could be the cause for the problem..?

As said, the tincs themselves are working perfectly as expected. My idea
is that if one node wants from one tinc to another tinc, it has to go
via the gateway, which will then route the packet (on the gateway I want
to do fancy firewalls later).

So the webworkers (web) and loadbalancers and so on are in one tinc
(which works), while gateway (which is in one AWS VPC with backup,
monitoring, gitlab and so on) is also in that tinc. gateway is a
connect_to in _every_ tinc I want to set up.

What is still totally puzzling me is that the packets from web _reach_
backup, but backup doesn't know how to answer...  So in the setup for
web, I seem to have done something right :P But I can't spot the
difference between backup and web :(

>
> _______________________________________________
> tinc mailing list
> tinc at tinc-vpn.org
> https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Mit freundlichen Grüßen,


Peter Thurner

--

Blunix GmbH - Consulting for Linux Hosting 24/7

Glogauer Straße 21
10999 Berlin, Germany

P: +49 30 / 120 839 90
W: https://www.blunix.org

AG Charlottenburg, HRB 174906 B
CEO: Peter Thurner


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL:
<http://www.tinc-vpn.org/pipermail/tinc/attachments/20190209/5ec955ff/attachment.sig>

> I'm using something similar to Amazon's VPCs, where a logical group
of
> instances has a local subnet from the cloud provider. This local subnet
> is always 10.0.0.0/24. As there are multiple VPC's, these private local
> subnets dont collide.
I do not know what Amazon does, and it looks like I do not want to know
it :-)

Am I correct? web, gateway and backup have NO direct lan connection and
you want to connect them via tinc.

If you need the "Amazon way" AND you have no double ips, you can use
tinc in switch mode and use your 10.0.0.5/10/101 ips directly.
But switch means every broadcats will be transportet to every tinc node.

Normaly you would use 3 different local networks, 10.0.1.x, 10.0.2.x,
10.0.3.x, then you can use tinc in router mode (default).
Again you can just use your local 10.0.x.y ip for tinc and route all
10.0.0.0/16 traffic to tinc. Which is done automaticly if you use /16
for tinc network. To be exact, /16 ist far to much, but should work.

If you want extra ips for tinc, you choose one network, lets say
172.16.0.0/24 and just give every node one ip of this network. Then you
can ping each tinc server with this ip but not the 10.0.0.x ips.

I think gateway will not need 2 ips, you can do alot, but it does not
make things easier :-)


ALBI...