Req #66208 [Wfx->Opn]: PHP-FPM Bind to address

Edit report at https://bugs.php.net/bug.php?id=66208&edit=1 ID: 66208 Updated by: requinix@php.net Reported by: tronox at hotmail dot com Summary: PHP-FPM Bind to address -Status: Wont fix +Status: Open Type: Feature/Change Request Package: *Network Functions Operating System: Amazon AMI PHP Version: 5.5.6 Block user comment: N Private report: N New Comment: But that only affects inbound connections - when outbound ones are created, be that by PHP or something else, the OS still decides which interface to use unless told otherwise. Again, it's not PHP that's deciding to use eth0 but the system. And that's the problem you're having: it's not picking the interface you want it to pick, but your solution is to somehow force PHP (who, once more, is not the one deciding) to "say otherwise". Then again, you've managed to "lock down every system so far", which I must not understand because what I would expect that to entail isn't even possible. But whatever, if there is a change that should be made it's not my call how it'd be done. Previous Comments: ------------------------------------------------------------------------ [2013-12-01 02:53:31] tronox at hotmail dot com The network interfaces have routes in place to use their bound IPs as the default outgoing IPs. However while running PHP through PHP-FPM even binding it to the specific IP. My setup is 2 PHP-FPM pools, one running on 10.0.0.5:9005 and another running on 10.0.0.6:9006. Even though they are bound to listen on those IPs/Ports they still send out requests using the server's main IP 10.0.0.5. 0: from all lookup local 32762: from all to 10.0.0.6 lookup cldmv 32763: from 10.0.0.6 lookup cldmv 32764: from 10.0.0.7 lookup 10001 32765: from 10.0.0.6 lookup 10001 32766: from all lookup main 32767: from all lookup default default via 10.0.0.1 dev eth0 default via 10.0.0.1 dev eth1 metric 10001 10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.5 10.0.0.0/24 dev eth1 proto kernel scope link src 10.0.0.6 169.254.169.254 dev eth0 [root@s1 ~]# netstat -anr Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 10.0.0.1 0.0.0.0 UG 0 0 0 eth0 0.0.0.0 10.0.0.1 0.0.0.0 UG 0 0 0 eth1 10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 169.254.169.254 0.0.0.0 255.255.255.255 UH 0 0 0 eth0 As you can see above all traffic from 10.0.0.6 is to use eth1. Which it does with everything else installed so far. However with PHP it's only using the server's root main default IP. Even though there is a default eth1 and the ip 10.0.0.6 is routed to use eth1. I care about what interface a client's outbound traffic is on is due to bandwidth monitoring. Not to mention if I can send those functions a bindto then why is it so much to ask for a way to defaultly bind their outgoing connections? I'm not asking for a restriction or anything. Most users will just use those functions as in and will never know of the default binding (if one is implemented). However in it's current state bandwidth will show up on the client running 10.0.0.5 for all traffic outgoing through php on the box. I've been able to lock down every system so far to allow users to only access their section of the server through their IP. PHP seems to be the last string in the whole thing with it's inability to bind defaultly to the IP used to connect. Yea I could block all outbound traffic on 10.0.0.5 for each user but that could be a lot of IP table rules and then would force users to modify their code to bind to a specific IP fr each one of these functions. Which while there is a workaround available. PHP is already creating a context to connect out, I can't see it being that hard to tell it an ip to bind to. Keep in mind this is coming from a server administrator, not simply a user. As you can see below the IPs are nearly always the main server's IP. The only interesting part is when I hit the local IPs which always reply with the ip of the ip being pinged. http://test.cldmv.net/test.php http://test2.cldmv.net/test.php ------------------------------------------------------------------------ [2013-11-30 15:32:22] requinix@php.net Keeping in mind that the SERVER_ADDR is not calculated by PHP (heck, it's not even part of the CGI standard), yes the SERVER_ADDR does reflect the interface through which the request came, but that interface is not necessarily one that can access another location. A very typical development setup is a web server running and listening on localhost: attempting to access www.example.com from such a server could fail as PHP would try to bind to 127.0.0.1:0 (something that Ubuntu considers an "invalid argument"). Even if it did bind successfully that interface is useless for connections to anywhere except the machine itself. So okay, so then we make PHP ignore 127.* addresses and not attempt to bind at all should that be the REMOTE_ADDR? Now consider the situation where a server sits between the LAN and WAN. That's two (not counting loopback) interfaces. Traffic from the WAN would allow for connections to www.example.com as that interface has a route to that host, but traffic from the LAN would fail because it does not. For PHP to know better it would have to be aware of the system's routing tables, and that's just becoming too much work - work that the OS does deliberately and automatically for us anyways. The current default behavior of PHP, which is to use the default behavior in socket programming (ie, letting the operating system decide), works perfectly well for nearly all use cases; for those like you in unusual circumstances (I'm not even sure why you care about which interface is used for the connection so long as it works) the workaround of stream contexts and "bindto" does the job quickly and easily. All that aside, it sounds like your real problem is that the boxes aren't using the right interfaces for the right destinations, and that's totally something that should be solved with the network configuration on the machines themselves. ------------------------------------------------------------------------ [2013-11-30 09:50:35] tronox at hotmail dot com More specifically to your exact words: "talking about the IP address that remote servers see your HTTP requests coming from". ------------------------------------------------------------------------ [2013-11-30 09:49:28] tronox at hotmail dot com http://example.com/whatismyip.php code is: <?php echo $_SERVER['REMOTE_ADDR'];?> To explain it a bit better I guess. When I use file_get_contents('http://example.com/whatismyip.php') I get back the server's eth0 main IP. Rather then the IP, which while using phpinfo(), returned by _SERVER["SERVER_ADDR"]. Meaning the IP PHP is using to connect outside of the server is being defined by the server's default IP even though _SERVER["SERVER_ADDR"] is being set differently per host. Now most of the functions in PHP already support a bindto via stream. However that would mean I would have to re-write code to bind to specific IPs. Not to mention having to babysit each site to make sure they were doing that as well. I see no reason why PHP shouldn't, or at least have an option for it, bind outgoing connections defaultly to the IP set in _SERVER["SERVER_ADDR"]. ------------------------------------------------------------------------ [2013-11-30 09:14:43] requinix@php.net So wait, are you talking about the IP address that your web server is binding to, which is what your title and latest reply are talking about (despite how it's not PHP-FPM that does that), or are you talking about the IP address that remote servers see your HTTP requests coming from, which is what your description was about? ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=66208 -- Edit this bug report at https://bugs.php.net/bug.php?id=66208&edit=1