We are using Delphi Berlin 10.2
We have an application that runs on devices with 2 or more ethernet adapters. It's mandatory for us to choose a specific network adapter.
I researched and failed to find a way to do this using Indy, Synapse, or even Winsock.
The connect methods don't offer this option, they offer only destination IP and port.
Is there a way to do this?
You need to bind() the client socket to the local IP address of the desired network interface, then connect() will reach out to the server's IP:port using the network that the interface is attached to.
Indy has properties for that purpose, for instance the BoundIP property of TIdTCPClient.
I'm sure Synapse (and most other networking libraries) has its own equivalent for this, too.
Related
I'm using Delphi 10.2 Tokyo. I have 4 internet sources with 4 LANs. I want to make a program using TNetHttpClient. How do I direct it to use a specific internet source?
Unfortunately, TNetHttpClient does not provide the ability to bind it to a specific LAN. If you need this capability, you will have to find another HTTP library that can do this.
UPDATE:
After doing some reading, it turns out that on Windows at least, binding a socket for an outbound connection only sets the source IP for the socket's packets, but prior to Vista the actual adapter used for making an IPv4 connection is determined solely by Windows' routing tables, the application can't force a specific IPv4 adapter to be used. But for IPv6 traffic, and for IPv4 traffic on Vista+, binding a socket to a specific adapter should work in most cases.
Q175396: Windows Socket Connection from a Multiple-Homed Computer
Strong and Weak Host Models
Using a specific network interface for a socket in windows
For instance, Indy's TIdHTTP has a public BoundIP property for binding its socket to a network interface's IP (on platforms that require an interface name instead, you can use the TIdHTTP.OnSocketAllocated or TIdHTTP.OnAfterBind event to call the TIdHTTP.Socket.Binding.SetSockOpt() method, such as for using the SO_BINDTODEVICE option on Linux).
I've been trying to establish a P2P connections for a couple of weeks. After writing some code and using Indy's components, I've realized that it can not access the peer that is behind the NAT. Furthermore, I've heard about STUN services that provide a client's remote and local IPs and ports. I should say I've already had the other UDP client (server) remote and local IPs, so how can I implement my code and program to work properly? Is there any extra component in Indy's library that I should use?
There is the Ares Galaxy P2P Project I know about some years ago.
There was a recent fork by Christian at https://github.com/CWBudde/AresGalaxy which tries to port it to more modern Delphi versions.
It is a work in progress, but perhaps you may get some very good ideas in this source code, and ask Christian for help/ideas, especially about NAT transversal.
I am developing an P2P application in Delphi XE5 with a PHP remote server as a tracker to make a list of the clients sockets. I am afraid that using UDP Hole Punching would fail at some point if client's NAT decides to close/block that random port it created with in the first message sent to the PHP remote server.
So I with to know How to make a more time persistent port configuration with NAT from the Client (which is written in Delphi). I do not want my user to need to know how to access a router and configure port forwarding himself.
Could I do that and use the server just to store the socket without the PHP-P-H and be sure that at least while the Delphi's application is running the port will remain opened?
If I do decide to use UDP hole punching from remote server, Will the NAT maintain the port opened to user's local PC if no other users connect to it directly (P2P) soon enough?
If I open that port with UDP, may I use TCP after?
Obs: Delphi XE5 to compile to Windows 32 and Android, so I need a non-Windows Only solution.
Microsoft has an API for working with NATs via uPNP, especially for assigning port mappings in particular. Look at the IUPnPNAT interface and its StaticPortMappingCollection property. Use IStaticPortMappingCollection.Add to assign ports in the NAT.
Of course, this only works with routers that have uPNP turned on. Not all routers support uPNP at all, or have uPNP enabled.
I have a IdTCPClient on my application and my firewall inform me about an outgoing connection to 224.0.0.252:5355. In the connection properties the used protocol is UDP.
I've searched for "224.0.0.252" and found that it's an IP multicast address (Link-local Multicast Name Resolution)
Q: Why IdTCPClient try to do that?
As its name suggests, TIdTCPClient only supports TCP not UDP.
UDP 224.0.0.252:5355 is used by Microsoft in modern Windows versions for Link Local Multicast Name Resolution (defined in RFC 4795) as part of their hostname-to-IP lookups when conventional DNS is not available.
When you ask TIdTCPClient to connect to a hostname, it asks the OS to resolve the hostname to an IP address before then connecting to it. Your Windows version is obviously utilizing LLMNR as part of that resolution, and your firewall is picking up on that. That is happening outside of Indy.
The connection to 224.0.0.252:5355 with protocol UDP is used by recent versions of Windows for Link Local Multicast Name Resolution (LLMNR) searching for local network computers.
If you have no local network you may disable LLMNR with a peculiar registry setting.
Create and execute the file "disable-LLMNR.reg" containing:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient]
"EnableMulticast"=dword:00000000
I need to connect to a VPN Server , I can`t use windows Connections , My Application should work independently !
I tested some Components using RAS Api , they works ! but by using windows connections .
how can i do that without any dependency to windows connections ?
The problem with this question
"VPN" stands for "Virtual Private Network". It's a way to make a private network available to your computer, possibly in a secure way, so your computer can use standard IP protocols as if it were physically connected to the private network.
The operating system needs to know about that network, so of course all VPN implementations use "windows connections". From a different perspective: When you're connected to a VPN you can open a TCP connection to an IP on the private network as if it were on your local network. Since it's the operating system's job to set up your TCP connection and route your TCP/IP packets, of course it needs to know about the VPN! If it doesn't, it'll simply forward all your requests for the given IP to it's default router and fail with a "no route to destination" message (or a "time out", if your router is not kind enough to tell your system it has no idea what the private IP is).
Can it be done?
From a theoretical point of view, of course, you can bypass Windows completely, but then you'll have to "roll your own" everything. You can't use the Windows IP services, you'll have to implement your own TCP. I'm sure there are about a million other little things that need re-implementing.
For a starting point I'd look at the Open VPN: it's Open Source and available for Windows. It uses the UDP protocol as the bases for the VPN implementation, unlike the Windows VPN (that one uses GRE - General Routing Encapsulation, protocol 47). Open VPN itself, of course, uses a "windows connection" to do it's job, because it aims to provide a useful service, but you can use the source code as the bases for your own implementation.
I personally wouldn't even think about doing this, I'm just showing you the way and proving it's possible.
What should be done
I assume you want some kind of secure communication channel to your own service. Look into simple secure connections, tunneling protocols and proxies.
If this needs to be done for one service on one server, I'd look into a simple SSL implementation. Even better, look into using HTTPS.
If you need to access many different services on possibly different servers on the given private network I'd look into proxies.