Zhang Jun
2016-Nov-02 07:51 UTC
is it possible to let two nodes in different LAN directly connected with another public server ?
pc1(LANa) ----poor connection ----> VPS <--------- PC2(LANb) pc1 and pc2 used to connected directly with tinc, since pc1 used to have WAN IP(pppoe), but the pppoe IP is not WAN IP anymore (ISP changed to let all ADSL user in a LAN). if I let the two pc connect to a VPS with tinc, can later connections between pc1 and pc2 be directly ? for example, ssh from pc1 to pc2 but not proxyed by VPS. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20161102/03b0216a/attachment.html>
Etienne Dechamps
2016-Nov-02 09:22 UTC
is it possible to let two nodes in different LAN directly connected with another public server ?
Yes, tinc will attempt to establish a direct data tunnel between PC1 and
PC2 even if they don't have a direct metaconnection (ConnectTo) o each
other, and even if they are behind NATs.
If only one side (PC1) is behind a NAT, that should always work. If both
sides are behind NATs, then it will work under the condition that both NATs
support UDP Hole Punching. In other words it will work as long as the NAT
isn't symmetric. See
https://en.wikipedia.org/wiki/Network_address_translation#Methods_of_translation
In addition, if you have UPnP support enabled in tinc, *and* the NAT
supports UPnP (unlikely if the NAT is on the ISP side, i.e. CGN), then tinc
will automatically configure port forwarding on the NAT and the end result
is basically the same as no NAT at all.
Also note that tinc 1.1 might be more effective than 1.0 at circumventing
NATs, because of improved logic such as
https://github.com/gsliepen/tinc/pull/65/commits/9bb230f30f665779eb89dcce077a15360ec50be1
In any case, if tinc is unable to send data packets directly, it will
automatically and transparently fall back to forwarding them via your
central node ("VPS"). To determine what's actually going on you
can use a
sniffer (tcpdump, Wireshark) to look at where the packets are physically
going. Alternatively, on 1.1 you can use "tinc info" commands to
determine
if tinc is sending packets directly or through a relay node.
On 2 November 2016 at 08:51, Zhang Jun <gb2313 at gmail.com> wrote:
> pc1(LANa) ----poor connection ----> VPS <--------- PC2(LANb)
>
> pc1 and pc2 used to connected directly with tinc, since pc1 used to have
> WAN IP(pppoe),
> but the pppoe IP is not WAN IP anymore (ISP changed to let all ADSL user
> in a LAN).
>
> if I let the two pc connect to a VPS with tinc,
> can later connections between pc1 and pc2 be directly ?
> for example, ssh from pc1 to pc2 but not proxyed by VPS.
>
> _______________________________________________
> tinc mailing list
> tinc at tinc-vpn.org
> https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.tinc-vpn.org/pipermail/tinc/attachments/20161102/5d36bc6f/attachment.html>
Guus Sliepen
2016-Nov-02 09:56 UTC
is it possible to let two nodes in different LAN directly connected with another public server ?
On Wed, Nov 02, 2016 at 03:51:15PM +0800, Zhang Jun wrote:> pc1(LANa) ----poor connection ----> VPS <--------- PC2(LANb) > > pc1 and pc2 used to connected directly with tinc, since pc1 used to have > WAN IP(pppoe), > but the pppoe IP is not WAN IP anymore (ISP changed to let all ADSL user in > a LAN). > > if I let the two pc connect to a VPS with tinc, > can later connections between pc1 and pc2 be directly ? > for example, ssh from pc1 to pc2 but not proxyed by VPS.As long as pc1's ISP allows NAT hole punching, tinc should be able to make a direct connection. If it's not possible, tinc will automatically fall back to relaying traffic between pc1 and pc2 via the VPS. Note that if pc2 still has a real WAN IP address, you can just have pc1 ConnectTo pc2, you don't need a VPS in that case. -- Met vriendelijke groet / with kind regards, Guus Sliepen <guus at tinc-vpn.org> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20161102/7675ec6e/attachment.sig>