| At line 3 added 8 lines |
| Quick video showing the steps described below: [https://youtu.be/qIe6Hyi4R9E] |
| (As of CrushFTP 10.2.0_21+ the template user is generated automatically for you.) |
|
| When a connection comes into the DMZ server over SFTP/FTP(es)/HTTP(s)/WebDAV(s), the DMZ server talks to the internal server on an existing connection it already has from the internal server. This communication is over a SSL socket and is always initiated from the internal to the DMZ. The protocol the DMZ then uses inside this secure connection is HTTP. The internal server then attaches the connection to the first HTTP (not HTTPS) port internally that it finds in its list of ports. |
|
| So all interaction between DMZ and Internal is the HTTP protocol (inside a SSL connection). The user may be using SFTP to connect to the DMZ, and ask for a directory listing. This then results in the DMZ asking the internal server for a dir listing using HTTP, and then its translated and delivered to the SFTP client as a SFTP dir listing. This way all protocols are handled by the DMZ, and the internal server does everything using one protocol that can handle everything. |
| ---- |
|
| At line 5 changed one line |
| java -jar CrushFTP.jar -dmz 9000 #accept a connection from any IP on port 9000 to receive settings and run |
| /C:/real_path_to/CrushFTP10/Java/bin/java.exe" -jar CrushFTP.jar -dmz 9000 |
| At line 7 removed one line |
| java -jar CrushFTP.jar -dmz 9000 192.168.1.10,10.0.1.5,192.168.1.11 #accept a connection from these IPs on port 9000 and run |
| At line 9 changed one line |
| If you specify acceptable IPs, and the IP isn't int he list, the connection is dropped, and a message logged. |
| On Windows, if portable Java runtime is placed inside the CrushFTP installation folder, use |
| {{{ |
| /C:/real_path_to/CrushFTP10/Java/bin/java.exe" -jar CrushFTP.jar -dmz 9000 |
| }}} |
| To install the service , use the __-dmzi__ parameter instead |
| {{{ |
| /C:/real_path_to/CrushFTP10/Java/bin/java.exe" -jar CrushFTP.jar -dmzi 9000 |
| At line 24 added 17 lines |
| or |
|
| .\Java\bin\java.exe -jar CrushFTP.jar -dmzi 9000 |
| }}} |
|
| On Linux/UNIX will need to remove or comment the line |
| {{{ |
| $NOHUP $JAVA -Ddir=$CRUSH_DIR -Xmx1024M -jar plugins/lib/CrushFTPJarProxy.jar -d & >/dev/null 2>&1 |
| }}} |
|
| and uncomment the |
| {{{ |
| #$NOHUP $JAVA -Ddir=$CRUSH_DIR -Xmx512M -jar CrushFTP.jar -dmz 9000 & >/dev/null 2>&1 |
| }}} |
| line in the init script file __crushftp_init.sh__ then start or install normally. |
|
|
| At line 13 changed one line |
| So duplicate prefs.XML and call it "prefs_dmztest.XML". The "_dmz1" is part of a specific naming scheme. This server will be identified as "dmztest". So if you wanted another name such as 'extra' you would do "prefs_extra.XML". |
| So duplicate prefs.XML and call it "prefs_dmztest.XML". The "_dmztest" is part of a specific naming scheme. This server will be identified as "dmztest". So if you wanted another name such as 'extra' you would do "prefs_extra.XML". |
| At line 17 changed one line |
| Create a new port item, set its protocol to be DMZ:// and configure the IP and port for the DMZ server where the core will be connecting out to the DMZ. The IP is the IP of the DMZ server and the port is the port you used above when you started it. The 'name' field that would normally be optional is required here as that is how it identified what prefs.XML file to use. So the name should match that second part of the filename you made above. In this case 'dmztest'. |
| Create a new port item, set its protocol to be DMZ:// and configure the IP and port for the DMZ server where the core will be connecting out to the DMZ. The IP is the IP of the DMZ server and the port is the port you used above when you started it. The 'name' field that would normally be optional is required here as that is how it identifies what prefs.XML file to use. So the name should match that second part of the filename you made above. In this case 'dmztest'. When the port starts, it sends the prefs_dmztest.XML over the network to the DMZ server, and its kept in memory on the DMZ server. There will be outgoing port connections from the internal server to the DMZ server on the port specified. |
| At line 21 changed one line |
| 4.) Now when you go back to the [Server Admin] tab, you will notice a new drop down selector to the right of the tabs allowing you to control the instance you are managing. |
| 4.) Now when you go back to the [Server Admin] tab, you will notice a new drop down selector to the right of the tabs allowing you to control the instance you are managing. Select your DMZ instance. If the interface loads, then it means the DMZ server is communicating correctly. Now we need to setup the forwarding user. |
| At line 23 removed one line |
|
| At line 54 added 44 lines |
|
| 5.) *OBSOLETE* Go to the user manager on the DMZ instance. Create a new user named "template". No need for a password as its not used. This is a reserved username that forwards to an internal server. |
|
| Create a new remote item using the third button down in the middle of the virtual file system area. Configure it exactly as shown in the screenshot using the username of '{username}' and password of {password}'. Don't change the IP or port, just leave it as the screenshot shows. Then give it full permissions with the checkboxes on the right after you save. |
|
| [attachments|dmz_user.png] |
|
| Since this is a DMZ server, this remote item will be used by the DMZ to talk to the internal server. It will adjust the IP, port, and fill in the user/pass info as needed dynamically. |
|
| If the DMZ will do public key authentication, in the user manager, set the public key path for this 'template' user to be just the three letters in uppercase: DMZ. This will allow automatic public key verification based on keys configured on the internal server to be validated on the DMZ as well. |
|
| [attachments|dmz_publickey.png] |
|
| ---- |
| !No prefs are stored on the DMZ server. |
| !SSH keys, and SSL certificates are given to the DMZ server from the Internal server. |
| !No users are stored on the DMZ server. |
| !No user data files are stored on the DMZ server. |
| !File transfers are streamed through to the Internal server. |
|
| ---- |
|
| You can install the DMZ as a daemon process in windows using:\\ |
| {{{ |
| java -jar CrushFTP.jar -dmzi 9000 |
| }}} |
| \\ |
| ----\\ |
| (Internal details of the protocols methodologies)\\ |
| \\ |
| !DMZv1 methodology: |
| Opens a read and write socket. Two sockets for all queue messages between servers. Initiated from internal server to DMZ. Then it opens 50 data sockets for whenever they might be needed, they are available for quick usage not needing any additional delay to request one. This would be for things like a login, dir listings, upload, download...etc. All user protocol type interactions. We only let these sockets remain unused for a maximum of 8 seconds, then we discard them to make sure a firewall hasn't possible dropped a socket and we go to use it and don't realize its been killed by the firewall. When he socket count drops below 50, we add more. So it is a continuous cycle of adding and dropping sockets and discarding sockets that are used and so on. *LOTS* of new socket activity. PRIMARY AND PREFERED PROTOCOL\\ |
| \\ |
| !DMZv2 methodology: |
| This protocol was discontinued. It attempted to route DMZv1 through a SSH tunnel between servers which revealed inefficiencies and bugs in SSH tunneling libraries. DISCONTINUED\\ |
| \\ |
| !DMZv3 methodology: |
| There are 4 sockets. Read/write tunnel sockets for system type actions, and read/write tunnel sockets for data type actions. No other sockets are created. All other activity is tunneled inside of those 4 sockets between the Internal and DMZ host. the tunnel is not a reverse tunnel, so architecturally it functions the same as the way DMZv1 does. v3 has the DMZv1 protocol running inside of it, but it doesn't discard sockets since it knows it can trust the tunnel not to timeout or discard sockets. So that part of the protocol still functions the same. DMZv3 also handles disconnections on the sockets. If any of the 4 sockets get disconnected, it re-establishes the connection and resends any part of the tunneled messages that didn't make it across. So its added automatic retry and robustness to this. The dmz_tmp folder for this tunneling is due to the fact we can't stop or slow down the entire socket in the event one of the destination sockets on t he other side can't accept the data or has timed out. We instead buffer this to disk temporarily and then consume it the first moment we can. The expectation here is that the DMZ's internal communication pipe is faster than the internal or external communications that clients are doing. DISCONTINUED\\ |
| \\ |
| !DMZ v4 methodology: |
| Re-attempted ssh tunnel with ssh libraries (like v2), learned the hard way, tunnel in ssh is still very unsafe for high volume usage. DISCONTINUED\\ |
| \\ |
| !DMZ v5 methodology: |
| Only for CrushFTP v10 because some customers still had no stable means of DMZ due to their firewalls. Tunnels all of DMZ v1 traffic through its sockets similar to how DMZ v3 does, no timeouts on sockets. Instead of tunneling everything through one socket like v3 did, it now tunnels everything through individual sockets. It keeps a pool of sockets for reusing them so there aren’t a lot of new sockets created, and the sockets stay fairly active and busy. If any socket dies, it at most can affect one single action…but not the entire DMZ communication channel (the DMZv3 flaw). So traffic is still encapsulated/tunneled inside another socket, but this allows for validation of the socket being good or not and confirmation of traffic making it to the other side and so on. BACKUP PROTOCOL FOR CUSTOMERS WITH NETWORKING ISSUES.\\ |
