Basic restrictionsAccess to the faculty network is limited in order to increase its security. Restrictions generally apply to non-univerity network access, ie non-muni.cz domains (IP with prefix 147.251 or 2001: 0718: 0801: 02NN). In general, all privileged ports of all machines are blocked except for those selected services that are available from outside:
- SSH, IMAP (s), POP3 (s) on Ais and Anxura (correct DNS record required - see below)
- SMTP with forced authentication at relay.fi.muni.cz
- NTP and time at time.fi.muni.cz
- HTTP (s) at www.fi.muni.cz and fadmin.fi.muni.cz
Other, justified exceptions will be made by CVT FI on request.
SSH on ports 80, 443Some ISPs (hotels, conferences, ...) restrict users only to using the [http (80) / https (443)] access ports. This is not an option to use SSH on port 22. For the needs of FI staff (and other users with access to the Anxur employee server), we are able to use SSH on ports 80 and 443 at anxur-ssh.fi.muni.cz:
ssh -p 80 email@example.com
SSH tunnels (port forwarding)If you need to connect to a service that is available only from a faculty or university network, you can use the SSH tunnel. Using the SSH tunnel, the connection is linked from a machine to which the user has access via SSH (eg Aisa, where access to faculty services is not restricted), but the service is accessed on the selected port on the user's machine.
doma$ ssh -L 13306:db.fi.muni.cz:3306 firstname.lastname@example.orgThe above command will drive the db.fi.muni.cz MySQL port to the machine 13306 at home so the user can connect to his database on the faculty database server from the machine at home by following the command:
doma$ mysql -h localhost -p 13306 -u login -pSimilar instructions for the PuTTY client on Windows can be found in different versions of the Internet.
DNS Issues (or: Aisa Rejects Link)To connect to some services (including SSH on Ais), you need to connect from an IP address that has a properly configured DNS. Which means there must be a reverse (PTR) record in DNS for this IP address, and for the name that this record shows, there must be a forward (A) record in the DNS that leads back to the address from which the user connects.
How do I verify the consistency of DNS records?For this purpose, it was created simple application at the Faculty Administration . Alternatively, verification can be done manually, on UNIX machines, for example, with a program
host, on Windows then the program
nslookup.exe. Suppose the IP address of the machine from which the user reports is
188.8.131.52, then the verification might look something like this:
$ host 184.108.40.206 220.127.116.11.in-addr.arpa domain name pointer uzivatel4.poskytovatel.czThis is to verify that the reverse DNS record for IP address 18.104.22.168 exists. Now a corresponding forward listing:
$ host uzivatel4.poskytovatel.cz uzivatel4.poskytovatel.cz has address 22.214.171.124OK, there is a forward DNS record and leads to the correct IP address.
The most common mistakesThe most common error is the absence of a reverse DNS record (the first command
hostreturns an error), the absence of a forward DNS record (the second statement returns an error) or the fact that the reverse and forward DNS record does not match (the second statement returns a different address than the address specified in the first command).
How to make a correctionDNS records can be corrected by the network administrator from where the user connects (or his ISP). You have to ask for it and, if necessary, refer to RFC 1912 "Common DNS Operational and Configuration Errors", where section 2.1 says:
2.1 Inconsistent, Missing, or Bad Data Every Internet-reachable host should have a name. The consequences of this are becoming more and more obvious. Many services available on the Internet will not talk to you if you aren't correctly registered in the DNS. Make sure your PTR and A records match. For every IP address, there should be a matching PTR record in the in-addr.arpa domain. If a host is multi-homed, (more than one IP address) make sure that all IP addresses have a corresponding PTR record (not just the first one). Failure to have matching PTR and A records can cause loss of Internet services similar to not being registered in the DNS at all.