Remote access should not have single point of failure

Remote access to intranets and otherwise restricted areas was always a challenge. On one hand, it’s desirable to re-create convenient and familiar access to the same resources; on the other hand, there are many issues, starting from ensuring security and access reliability

The same is related to monitoring. If a network’s devices should be monitored, there always should be access to them; thus, there’s a separate task of monitoring accessibility. Below are several guidelines. Please note: it may be equally convenient to use all the mentioned techniques – depending on how reliable should be external access to a network in question.

Backup ISP connections

If several ISPs are available, it may be practical to use at least two separate ISP lines to access Internet. However, one needs to be sure the lines are actually working.

The checks would require an additional setup on some of internal devices: a number of external devices should try connecting to known external IP addresses (PING, TCP or similar simple means would do); internally, these attempts should be registered; in case there were no oncoming “who’s there” connections, the line may be considered offline.

IPHost can check the mentioned “is alive” flag and raise alarm when necessary. Note that IPHost can perform a number of other actions, apart from sending notification: one can set up IPHost to trigger switching to alternate ISP line if current one stops receiving mentioned external probes.

Using VPNs

VPN are and will remain a secure means to access closed networks; apart from well-known OpenVPN, other implementations – tinc or modern WireGuard – can be used to set up seamless access to an intranet. Communication is performed over an encrypted channel; thus it makes no differences whether the intermediate media do provide any encryption.

Similarly, IPHost can perform simple monitoring of a device connected via one of VPNs, to ensure the VPN is alive. Note that using VPNs mitigates, to some extent, using insecure protocols (such as FTP, Telnet, SNMP versions 1 or 2c), if all the communication is performed strictly over virtual private network.

Using WiFi or mobile networks

If there’s an external WiFi access points, AP (the one not using the same ISP line(s) used by the intranet), it could also serve as a backup communication line. One should note, however, that WiFi connections can be hard to secure; if multiple WiFi APs are in use in the same area, connection quality can significantly deteriorate.

Same can be told about mobile and satellite networks. While they can be very convenient, they can also be both slow and expensive to serve as primary Internet connections; however, using them to send notifications can make notifications more reliable.

Using GSM modems

This is rather out-of-date means; however, IPHost allows using GSM modems to send notifications (provided Professional 500 or higher license is in use). This could be considered as a backup communication channel, to notify network administrators of primary Internet line being inaccessible.

Proxy and relay services

All the services responsible for notifications (such as mail servers) should also be redundant; if a mail server goes down, and no backup has been specified, monitoring is as good as absent. A relay service (for example, “smart host” for mail server) can be used in such a situation, to pass email through a number of backup services, using single “smart host” mail server.

Conclusion

Have we missed any means to ensure IPHost can both communicate and notify, when something goes wrong? If we have, please let us know of your experience – contact us or leave a comment below.