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>