Which easily can lead to network conflicts in a TAP environment and then it looks like it's more complicated.įact is, if you don't need a tutorial because you know what you're doing, setting up tap takes as much time as setting up tun. Of course if you know how to setup TUN but don't understand what you're doing and simply following a tun tutorial, you will be fighting to setup TAP but not because it's more difficult but because you don't know what you're doing. Setting up TAP requires almost no additional work from the person setting it up. Is a Ferrari "better" than a dump truck? If you are trying to go fast, it may be but if you're trying to haul heavy loads, probably not.Ĭonstraints like "need for access" and "security requirements" must be defined, as well as defining constraints like network throughput and equipment limitations, before one can decide whether TUN or TAP is better-suited to your needs. (This is the consultant's favorite answer, "Well that depends.") "Better" and "Worse" are not definable without a context. Current GHz-level multiprocessors normally outrun the bottleneck of transmission via the internet. If latency is at issue, it might be a good idea to consider other alternatives. There are differences in latency because of the stack layer, but in most end-user scenarios the connection speed of the endpoints is probably a more significant contributor to latency than the particular stack layer of the transmission. This also opens the possibility of address conflicts between the endpoints. It will allow more traffic packets to flow through the VPN tunnel. TAP has the inherent security exposures involved with granting outside access "behind the firewall". This gives the flexibility of communication with other stations on the far-side network, including some methods used by older Microsoft software. TAP - usually allows packets to flow freely between the endpoints. IP Routes to other stations in the subnet are not included, so traffic is not sent across the VPN tunnel and little or no communication is possible beyond the OpenVPN server. TUN connection will create less load on the VPN tunnel, and in turn the far-side network because only traffic to/from the single IP address will cross the VPN to the other side. TUN normally confines VPN access to a single machine (IP address) and therefore (presumably) better security through limited connectivity to the far-side network. TAP may also be required for certain Windows applications. TAP - if you need access to multiple resources (machines, storage, printers, devices) connected via the network at the other end. (examples might be a CUPS connection to a network printer, or a Samba share on another machine MOUNTed on the OpenVPN server.) A little creativity here can help, by making resources "appear" to be local to the OpenVPN server. TUN - if you ONLY need access to resources connected directly to the OpenVPN server machine at the other end, and there are no Windows issues.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |