Using virtual network address information during communications
Techniques are described for employing virtual network address information in communications with other computing devices or software programs. In some circumstances, the techniques are used by a computing device that hosts multiple virtual domains each having a distinct domain name and having one or more virtual users of the domain. If so, the host computing device communicates with others on behalf of the virtual domains or virtual users by employing virtual network address information as part of the communications.
This application is a continuation of Ser. No. 09/768,671, filed Jan. 24, 2001, which is entirely incorporated herein by reference.
TECHNICAL FIELDThe following disclosure relates generally to inter-computer communication, and more particularly to communication by a computer that hosts virtual domains or virtual users.
BACKGROUNDComputers communicate with each other for a variety of reasons. For example, a user on one computer may wish to send a message (e.g., an email) to a user on a remote computer or to retrieve a Web page from a remote computer. A client computer system can identify and communicate with millions of other computer systems on the Internet by using a unique network address for each such computer. A common type of network address is a unique numeric identifier called an “IP address” (e.g., 198.81.209.25). Each computer also typically has a unique textual Domain Name System (DNS) domain name network address (e.g., micron.com or comp23.MicronPC.com) that is mapped to that IP address.
When a communication is sent from a client (or “source”) computer system to a server (or “destination”) computer system, the client computer system typically specifies the IP address of the server computer system (either directly or via a domain name that maps to the IP address) in order to facilitate the routing of the communication to the server computer system. Such communications typically take place using the TCP/IP network communications protocol. For example, common application-level communications protocols such as HTTP, FTP, Telnet, and Simple Mail Transfer Protocol (SMTP) typically use TCP/IP as an underlying communications mechanism. The TCP/IP protocol is described in greater detail in “TCP/IP Network Administration, Second Edition” by Craig Hunt, 1992, O'Reilly & Associates Publishing, which is hereby incorporated by reference in its entirety.
Application programs executing on different computers often communicate by using communication mechanisms provided by the operating systems on their computers. For example, application programs commonly exchange information using TCP/IP communication sockets that are provided by operating systems such as Unix or Microsoft Windows. A socket connection can be described with four pieces of information, those being a source computer IP address and software port and a destination computer IP address and software port. Such a socket connection is typically initiated by an application program executing on a server computer. In particular, a server application creates a socket on the server (e.g., via the socket ( ) function), binds the server computer IP address and the software port to the socket (e.g., via the bind ( ) function), and obtains a software port on the server which is mapped to the server application by the server's operating system. The server application then listens for a connection request from a client computer (e.g., via the is ten ( ) function) that includes a source IP address and software port to which the server application can respond.
When a client application program wants to communicate with such a server application, the client application creates a socket on the client (via the socket ( ) function) and may determine a client computer software port that is to be mapped to the client application. The client application then specifies that the created socket has a destination IP address corresponding to the destination computer and a destination software port that corresponds to the port mapped to the server application program, and uses the socket to make a connection request to the server application (e.g., via the connect ( ) function). In particular, the connection request is transmitted to the destination IP address and software port, along with the source IP address and software port to allow the server to respond. The inclusion of the source IP address with the connection request can be performed by the client computer operating system, which determines the IP address for the computer on which the client application is executing (e.g., by using the routing table or some other mechanism on the client computer).
The connection request that is sent to the destination IP address and software port is routed to the executing server application, and the application program on the server computer can then accept the connection request (e.g., via the accept ( ) function) and use the included source IP address and software port to respond to the client application. After the connection is accepted, the two programs can establish a shared communications standard and exchange information. TCP/IP sockets are described in greater detail in “Pocket Guide to TCP/IP Sockets (C Version)” by Kenneth L. Calvert and Michael J. Donaho, 2000, Morgan Kaufmann Publishers, which is hereby incorporated by reference in its entirety.
The Sendmail mail transport agent program is one example of software that communicates in the manner described above. For example, consider a situation in which a user on a client computer creates an email message using a mail user agent program (e.g., elm or Zmail) and specifies that a user on a remote server computer is to be a recipient of the email. The client mail user agent program begins the transfer of the created email to the remote recipient by forwarding the email to a local mail transport agent program (e.g., Sendmail or Zmailer) that is executing on the client computer. A copy of the mail transport agent may already be executing, or the mail user agent may instead invoke the mail transport agent. It is the responsibility of the local mail transport agent to transfer the created email to the remote server computer. If the local mail transport agent is the Sendmail program, it next establishes a socket-based connection with a Sendmail mail transport agent program that is executing on the remote server computer, and sends the email to the server. In some situations, the Sendmail mail transport agent on the client computer will temporarily store the email in an outgoing email queue on the client computer before transferring the email to the server computer. After the mail transport agent on the server computer receives the email, it makes the email available to the remote user recipient, who can use a mail user agent program on the server computer to read the email. The Sendmail program is available at the time of this writing at http://www.sendmail.org/, and additional details about Sendmail are available in “sendmail, Second Edition” by Bryan Costales with Eric Allman, 1997, O'Reilly & Associates Publishing, which is hereby incorporated by reference in its entirety.
Unfortunately, problems can arise when one computing device must communicate with other computing devices on behalf of a third-party. One reason that such problems can arise stems from the existence of malicious users that intentionally attempt to disguise the identity of themselves and their computing devices in a variety of ways, such as by having their computing devices transmit false domain name or IP address information for identification purposes (referred to as “IP spoofing”). In order to combat such malicious users, many computing devices and application programs have incorporated security measures to attempt to detect and/or prevent such malicious users and their computing devices from establishing connections. In particular, such security measures attempt to verify in various ways that the identification information provided by client computers is accurate. However, such security measures may also detect and/or prevent situations in which a computing device is legitimately acting on behalf of a third-party, such as when the computing device provides identification information that corresponds to the third-party.
As an example of a problem that arises when a computing device attempts to legitimately communicate with other computing devices on behalf of a third-party, consider the illustrative situation shown in
While the VCDs are not actual physical devices, they do share the resources of computing device 100 (e.g., memory, storage, and processing power) and can appear to their users as if they were physical devices. For example, user b1 of VCD 200 may be physically using the I/O devices of computing device 110, but may remotely login to VCD 200 (e.g., by using a Telnet program or Web browser) and gain access to the resources of VCD 200. Once access has been gained, user b1 can typically then perform the same types of actions as non-virtual users (e.g., user al) of computing device 100, such as executing programs or modifying the contents of VCD 200's storage (e.g., storage of computing device 100 that is allocated to VCD 200). In addition to receiving access to computing device 100 resources, the virtual IP addresses of the VCDs are mapped to computing device 100 so that communications sent to those virtual IP addresses will be forwarded to the device in the same manner as communications sent to the device's actual IP address of “216.122.95.01”.
As with non-virtual computing devices, the VCDs may need to communicate with other computing devices. For example, user b1 of VCD 200 may wish to send email to user x1 of computing device 130. In order to do so, however, the physical resources of computing device 100 will need to be used, with computing device 100 acting on behalf of VCD 200. Unfortunately, as indicated above, security measures employed by other computing devices or application program may detect and/or prevent such communication by computing device 100 despite the fact that it is acting legitimately on behalf of the third-party VCD 200.
The misidentification of the email sender in the illustrated situation is caused by Sendmail's use of the standard socket network communications mechanism. In particular, even if the Sendmail program is invoked by another program executing in VCD 200 such as a mail user agent, the Sendmail program needs to have unrestricted access to various resources of computing device 100 and thus needs to execute with the highest level of system administrator privileges for computing device 100 (e.g., the “root” user for a Unix system). When the operating system of computing device 100 determines the network address information that corresponds to the socket created by the Sendmail program, it determines that the Sendmail program is executing for a user of computing device 100 having system administrator privileges and it retrieves the network address information for computing device 100. In this manner, the network address information of computing device 100 gets provided for the created socket rather than the network address information of VCD 200. Those skilled in the art will appreciate that a similar problem could occur for various other reasons in other situations. For example, if computing device 100 provided a single executing copy of a network communications program that processed the communications requests for all of the application programs running on the VCDs, that executing program may similarly use the network address information for computing device 100 rather than for any particular user or VCD executing an application program.
Unfortunately, the misidentification of the email sender in the illustrated situation can cause various problems. Depending on the configuration of the remote mail transport agent, such an email may not even be accepted. Moreover, even if the email is accepted and provided to user x1, the email will contain inconsistent information about the sender. In particular, header line 247 indicates that the email came from a user at a device with a domain name of abc.com and an IP address of 216.122.95.01, while header lines 242, 245 and 246 indicate that the email came from a user at a device with a domain name of bcd.com and an IP address of 216.122.95.70. Such inconsistent information can cause the recipient of the email to distrust the email or refuse to accept it. For situations in which a company is providing hosting services to customers, such problems can cause loss of business and other problems. Moreover, those skilled in the art will appreciate that these problems are not limited to email messages, and can instead occur for any type of inter-computer communication.
Thus, a need exists for a computing device that is acting legitimately on behalf of third-parties (e.g., a computing device acting as a host to VCDs or to virtual network addresses) to be able to communicate with other computing devices for those third-parties without triggering security measures employed by those other computing devices.
BRIEF DESCRIPTION OF THE DRAWINGS
A software facility is described below that employs virtual network address information in communications with other computing devices or software programs. In some embodiments, the facility is used by a computing device that hosts multiple virtual domains each having a distinct domain name and having one or more virtual users of the domain. In such embodiments, the host computing device communicates with others on behalf of the virtual domains or virtual users by employing virtual network address information as part of the communications.
For illustrative purposes, some embodiments of the software facility are described below in which email messages are exchanged using the Sendmail message transport agent program, and in which a computing device that host multiple virtual domains communicates with other computers on behalf of virtual users of those domains. However, those skilled in the art will appreciate that the techniques of the facility can be used in a wide variety of other situations, some of which are discussed below, and that the use of the facility is not limited to the exchange of email messages, to the use of the Sendmail program, or to situations in which a computing device is hosting virtual domains or virtual users.
In particular,
The storage includes groups of information for multiple virtual domains 440 (or VCDs to which the virtual domains correspond) that are hosted by the hosting computer system. Each virtual domain can contain various information for use by users of the domain, such as a mail agent program 442 for creating and storing email messages and other domain-specific software and/or data 448. Each virtual domain also includes configuration information 446 for the domain (e.g., a virtual domain name for the domain, a virtual IP address to which the virtual domain name is mapped, a list of users of the virtual domain, etc.), and an outgoing mail queue in which mail created by users of the virtual domain for recipients at other computing devices is temporarily stored before transfer. In some embodiments, the mail agent program 442 will store the outgoing email in the virtual domain queue, while in other embodiments the mail agent program will transfer the email to a mail transport agent that will perform the storage. Those skilled in the art will appreciate that a variety of other data and software could similarly be stored for each virtual domain, and that one or more of the virtual domains may alternately lack some of the displayed information (e.g., there may be a single stored mail user agent that the users in all of the virtual domains use). Those skilled in the art will also appreciate that in some embodiments different virtual domains can use different mail agent programs 442.
In addition to the virtual domains, the storage also includes configuration information 424 for the computer system (e.g., information about the various virtual users and virtual domains, such as the locations in which the virtual domain information is stored) and an outgoing mail queue in which mail created by users of the computer system that are not users of any of the virtual domains is temporarily stored before transfer. The storage also includes a Virtual Domain Mail Transport Agent (“VDMTA”) program 422 that, when executed, will transmit the email messages for the virtual domains to remote computer systems as appropriate. In some embodiments the VDMTA may be invoked by a mail agent 442 for a virtual domain when mail is available in the outgoing mail queue for the virtual domain, while in other embodiments the VDMTA periodically (e.g., every 30 minutes) checks the outgoing mail queues for the various virtual domains.
Executing copies of one or more mail user/storage agents 434 and one or more VDMTAs 432 are present in the memory. In some embodiments, a single copy of the VDMTA executes and transfers mail for all of the virtual domains, and in other embodiments multiple copies of the VDMTA can be executing for different virtual domains (e.g., when each virtual domain invokes a copy of the VDMTA when there is mail to be sent from the virtual domain's outgoing mail queue).
When processing the email for a virtual domain, an executing VDMTA retrieves the mail stored in the outgoing mail queue for the virtual domain and retrieves the virtual network address information for the virtual domain (e.g., from the stored domain configuration information for the virtual domain). For each email message in the queue, the VDMTA then determines any recipients on remote computing devices, establishes a connection with those remote computing devices on behalf of the virtual domain by using the retrieved virtual network address information, and then transmits the email to the remote computing devices. In particular, before establishing a connection with a remote computing device, the VDMTA binds the virtual network address information to the communication mechanism to be used in such a manner that the virtual network address information is used in place of that of the hosting computer system. For example, in the illustrated embodiment in which TCP/IP sockets are used, the virtual IP address for the virtual domain is bound to the socket before a connection request is sent to the remote computer.
If the hosting computer system has its own defined users that are not virtual users, such users may also create email messages for recipients of other computer systems. If so, they will use a mail transport agent (e.g., VDMTA) to send the email messages to those other computer systems using the network address information of the hosting computer system. In some circumstances, such as when the mail transport agent cannot immediately transmit an email message, a message will be stored in the outgoing mail queue 426 for the computer system. When a mail transport agent later retrieves the mail from the mail queue 426 for transmittal, the mail transport agent will send the email messages using the hosting computer system network address information.
The various virtual domain components and information on the hosting computer system may be accessed by users and software in a variety of ways. For example, some users may have physical access to the hosting computer system, and may thus be able to gain access via the I/O devices 410. Alternately, other users can use the I/O devices 454 and software (e.g., a Telnet program 459 executing in memory 457) that are provided by one of the consumer computer systems to remotely access a hosted virtual domain (e.g., via the Internet and/or the World Wide Web). In addition to user accesses of the virtual domain functionality, the hosting computer system can also exchange information (e.g., email messages) with various remote server computer systems 470, such as via mail transport agents 479 executing in memory 477 of the server computers.
Those skilled in the art will appreciate that computer systems 400, 450, and 470 are merely illustrative and are not intended to limit the scope of the present invention. Computer system 400 may be connected to other devices that are not illustrated, including through one or more networks such as the Internet or via the World Wide Web (WWW). In addition, the functionality provided by the illustrated components may in some embodiments be combined in fewer components or distributed in additional components. Similarly, in some embodiments the functionality of some of the illustrated components may not be provided and/or other additional functionality may be available. For example, other components could additionally be available to perform administrative functions for hosting customers (e.g., establishing new virtual domains and providing account status information for existing customers) and to obtain new virtual network address information (e.g., domain names and virtual IP addresses) for new customers.
Those skilled in the art will also appreciate that, while various components are illustrated as being in memory or on storage, these items or portions of them can be transferred between memory and other storage for purposes of memory management and data integrity. The software components and data structures may also be stored as instructions on a computer-readable medium (e.g., a hard disk, a memory, or a portable article to be read by an appropriate drive), and transmitted as generated data signals on a variety of computer-readable transmission mediums, including wireless-based and wired/cable-based mediums. Accordingly, the present invention may be practiced with other computer system configurations.
Moreover, those skilled in the art will appreciate that the software facility can be used in various environments other than the Internet. In addition, a hosting computer system may comprise any combination of hardware or software that can provide hosting functionality. Similarly, a customer system may comprise any combination of hardware or software that can interact with the hosting computer system. These systems may include television-based systems or various other consumer products. The various computer systems can also operate on a wide variety of operating system types (e.g., Windows, Linux, Unix, MacOS, BEOS, PalmOS, EPOC, Windows CE, FLEXOS, OS/9, JavaOS, etc.), and need not share the same operating system.
Those skilled in the art will appreciate that an existing mail transport agent can be modified to act as a VDMTA in a variety of ways, and that the modifications will be specific to the particular mail transport agent used. Tables 1-4 below illustrate examples of modifications that can be made to a Sendmail version 8.9.3 program so that it acts as a VDMTA.
In particular, Table 1 illustrates C-language instructions that the modified client Sendmail can execute before making a connection with a remote server Sendmail so that the modified client Sendmail will use appropriate virtual network address information in place of the actual network address information for the computing device on which the modified client Sendmail is executing. These instructions can be added, for example, in the make connection procedure in the daemon.c file after the socket( ) system call and before the connect( ) system call.
Table 2 illustrates C-language instructions that the modified client Sendmail can execute so that created emails are stored in an outgoing mail queue for the appropriate virtual domain or machine before they are transmitted. These instructions can be added, for example, in the “main” procedure in the main.c file after the uid and gid are determined and before “save command line arguments” and the reading of the configuration files.
Table 3 illustrates a Perl-language script named vsmq.pl that when executed will process the queues of outgoing stored emails for the various virtual users. In the illustrated example, each virtual user X has a home directory at /usr/home/X/ and has a outgoing mail queue at /usr/home/X/var/spool/mqueue. The script can be stored in any location from which it can be executed, such as /usr/local/bin/ on some Unix-based computing devices.
Finally, the following line can be added to the Unix root user's crontab so that the script illustrated in Table 3 will be automatically executed.
-
- 40 * * * * /usr/local/bin/vsmq.pl>>&/var/log/maillog
Those skilled in the art will appreciate that the locations of the files may vary on different computing devices and with different operating systems.
The routine begins in step 505 where an indication to create a message is received. The routine continues to step 510 where it receives an indication of the contents of the message, of the message recipients, and optionally of other message-related information such as a message Subject. In step 515 the routine then determines the virtual user name of the sender, the virtual network address information of the virtual user's domain, and the current time. The determined information is used in step 520 to add various headers to the created message. In step 525, the created message is added to the outgoing message queue for the virtual domain (or the virtual computer system supporting the virtual domain). In step 530, it is determined whether there are more messages to be created and stored, and if so returns to step 505. If not, the routine continues to step 595 and ends.
If it is determined that the selected computing device is not remote, then at least one of the recipients of the message is a virtual user of the same virtual domain as that of the message sender, and the routine continues to step 640. In step 640, the routine optionally adds headers to the message using the virtual network address information of the virtual domain (e.g., to add mandatory headers not included by the mail creation agent). In step 645, the routine then sends the message to the local recipients (e.g., by adding a copy of the message to incoming mail queues for each of the recipients).
If it was instead determined that the selected computing device is remote, then the routine continues to step 655 to create a communication socket to be used for transmitting the email to the selected computing device. The routine then continues to step 660 to bind the virtual network address information (e.g., a virtual IP address) to the socket. In step 665, the routine then uses the socket to make a connection to the 1P address of the remote machine (which can be obtained from the email message or from the domain name of the remote device that is included in the email message), using the virtual network address information as the address of the sender. The routine then continues to step 670 to optionally add headers to the message using the virtual network address information of the virtual domain, and then sends the message to the remote recipients over the socket.
After steps 645 or 675, the routine continues to step 680 to determine if there are more destination machines for the selected email message. If so, the routine returns to step 625, and if not continues to step 685 to determine if there are more messages from the queue to be sent. If so, the routine returns to step 615, and if not the routine continues to step 690 to determine if there are more virtual domains whose messages are to be sent. If so, the routine returns to step 605, and if not the routine continues to step 695 and ends.
Those skilled in the art will also appreciate that in some embodiments the functionality provided by the routines discussed above may be provided in alternate ways, such as being split among more routines or consolidated into less routines. Similarly, in some embodiments illustrated routines may provide more or less functionality than is described, such as when other illustrated routines instead lack or include such functionality respectively, or when the amount of functionality that is provided is altered.
From the foregoing it will be appreciated that, although specific embodiments have been described herein for purposes of illustration, various modifications may be made without deviating from the spirit and scope of the invention. Accordingly, the invention is not limited except as by the appended claims. In addition, while certain aspects of the invention are presented below in certain claim forms, the inventors contemplate the various aspects of the invention in any available claim form. For example, while only one some aspects of the invention may currently be recited as being embodied in a computer-readable medium, other aspects may likewise be so embodied. Accordingly, the inventors reserve the right to add additional claims after filing the application to pursue such additional claim forms for other aspects of the invention.
Claims
1. A method, in a computing device having a network address, for communicating with a remote computing device on behalf of at least one virtual computing device hosted by the computing device, the method comprising the steps of:
- determining a virtual network address associated with the virtual computing device;
- associating a first source network address of a first communication socket with the virtual network address; and
- sending information to the remote computing device using the first communication socket.
2. The method of claim 1, further comprising:
- retrieving the virtual network address from a configuration file.
3. The method of claim 1, wherein the associating step further comprises:
- creating the first communication socket; and
- binding the virtual network address to the first communication socket as a source network address of the first communication socket.
4. The method of claim 1, further comprising:
- receiving, from an application executing in the context of the virtual computing device, a request to send information to the remote computing device.
5. The method of claim 1, wherein the virtual network address is an IP address.
6. The method of claim 1, wherein the virtual network address is a domain name.
7. The method of claim 1, wherein the the virtual network addresses are hosted by the computing device as a service to customers.
8. The method of claim 1, further comprising:
- sending information to the remote computing device using a second communication socket, a source network address of the second communication being associated with the network address of the computing device.
9. A method, in a computing device having a network address, for communicating with a remote computing device on behalf of at least one virtual domain hosted by the computing device, the method comprising the steps of:
- determining a virtual network address associated with the virtual domain;
- configuring a first communication socket to use the virtual network address as a source network address;
- sending information to the remote computing device using the first communication socket.
10. The method of claim 9, further comprising:
- retrieving the virtual network address from a configuration file.
11. The method of claim 9, wherein the associating step further comprises:
- creating the first communication socket; and
- binding the virtual network address to the first communication socket as a source network address of the first communication socket.
12. The method of claim 9, further comprising:
- receiving, from an application executing in the context of the virtual computing device, a request to send information to the remote computing device.
13. The method of claim 9, further comprising:
- sending information to the remote computing device using a second communication socket, a source network address of the second communication being associated with the network address of the computing device.
14. The method of claim 9, wherein the virtual network address is an IP address.
15. The method of claim 9, wherein the the virtual network addresses are hosted by the computing device as a service to customers.
16. A method, in a computing device having a network address, for communicating with a remote computing device on behalf of an application residing on the computing device, the application executing in the context of a virtual computing device, the method comprising the steps of:
- retrieving, from the application, data to be sent to the remote computing device on behalf of the virtual computing device;
- determining a virtual network address associated with the virtual computing device;
- configuring a first communication socket to use the virtual network address as a source network address;
- sending information to the remote computing device using the first communication socket.
17. The method of claim 16, further comprising:
- retrieving the virtual network address from a configuration file.
18. The method of claim 16, wherein the associating step further comprises:
- creating the first communication socket; and
- binding the virtual network address to the first communication socket as a source network address of the first communication socket.
19. The method of claim 16, further comprising:
- receiving, from an application executing in the context of the virtual computing device, a request to send information to the remote computing device.
20. The method of claim 16, further comprising:
- sending information to the remote computing device using a second communication socket, a source network address of the second communication being associated with the network address of the computing device.
Type: Application
Filed: Feb 4, 2005
Publication Date: Jun 16, 2005
Inventor: Qiaofeng Zhou (Sammamish, WA)
Application Number: 11/050,970