![]() Corporate.Net Hide & Seek With Gateways & Translators By Eric Hall Let us tell you what you already know: TCP/IP is rapidly becoming the protocol of choice for networks everywhere. All of the major NOS vendors are backing it in one form or another, the Internet requires it, and users want it now. Although self-contained networks can use any IP addresses they wish, sites looking to connect to the Internet or other remote networks must use Internet-legal addresses for applications to function properly. While you'll be able to send packets from a system with an illegal address, the destination will not be able to return packets if the address you used points to another network on the Internet. Whether or not you're able to deploy Internet-legal IP addresses across your netw ork is another issue altogether. Maybe you have too many systems, making it difficult (or even impossible) to get enough legal IP address blocks to support all of your devices. Or perhaps you have legacy installations or applications that use invented IP addresses, requiring that you re-visit entire departments before you can implement "real" addresses across your network. There lies the dilemma: Sites that use their own addressing schemes must use externally accessible addresses to access remote systems, but not all network administrators have the luxury of being able to use fully compliant, Internet-legal addresses. IP gateways provide a solution by hiding the IP addresses of the internal devices, making internally generated packets appear as though they are coming from another device that does have an Internet-legal address. The IP gateway provides external connectivity without requiring that Internet-legal addresses be deployed across the internal networks. IP gateways come in two basic form-facto rs: hardware-based firewalls/routers and IP-over-IPX protocol converters. For example, Secure Computing Corp.'s BorderWare firewall uses application proxies at the core of its architecture, providing IP gate way services to internal clients that connect to external resources. To the internal systems, the firewall looks like a router that sits between the internal and external networks. Clients send outbound packets to the gateway, rather than simply forwarding the packets like a "normal" router would, so they appear to be originating from the gateway itself. Packets returning to the gateway then are redirected to the appropriate internal systems. Another commonly found implementation is in WINSOCK.DLL replacements, typically used in IP-over-IPX protocol conversion products such as the Novell Internet Access Server (NIAS) bundled with IntranetWare. Internal devices do not have "real" IP stacks, but instead use a WINSOCK.DLL that provides IP transport services over IPX. The clients share the NetWare server' s IP stack directly and use the server's port management services for their applications. In essence, the IPX-based client IP stacks become extensions of the server's IP stack. Rather than build maps of internal and external IP addresses and ports, NIAS assembles an address map that correlates internal IPX addresses to external IP addresses and port numbers (see "IP-Over-IPX Gateway Functionality With NIAS," at left). The clients use an IPX-based WINSOCK.DLL for local TCP and UDP applications, creating virtual IP connections on behalf of the server. IPX is used to deliver the virtual IP packets to the server, which in turn uses its local IP stack to deliver the packets to their destinations. Architecturally, this is similar to Systems Network Architecture (SNA) gateways of yore, which also used a central system for providing SNA transport services over IPX and other protocols. The same sorts of limitations that SNA gateways have historically faced also apply here. First among these is the devices them selves are not full-fledged IP clients. Since the systems do not have their own specific IP addresses, they cannot have individual IP identities, even on the local network. Clients can't even ping each other, be cause the Internet Control Message Protocol (ICMP) packets will end up pointing to the NetWare server hosting the IP stack. Low Maintenance Vs. High Functionality The architectural differences between these two implementations generate a variety of management implications. For example, because NIAS uses a single IP stack for services, client applications only need to allocate a port on the server's stack to run IP applications. The server simply creates an entry in its map that points the allocated port number back to the IPX client that requested it. It does not have to rewrite address headers or anything else; it only has to redirect packets to the proper destination, whether internal via IPX or external via IP.
|
|
by Chris Lewis Brewing Fresh Code: Java Development Environments by Todd Tannenbaum Updated Februayr 7, 1997 |














