Since 10 November our faculty has a new website! The old website will still be available at oldwww.fi.muni.cz for now. Something is broken? Please report it to webmaster@fi.muni.cz or use our webform.

translated by Google

Basic restrictions

Access 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:

Other, justified exceptions will be made by CVT FI on request.

SSH on ports 80, 443

Some 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 login@anxur-ssh.fi.muni.cz

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 login@aisa.fi.muni.cz
The 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 -p
Similar 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 1.2.3.4 , then the verification might look something like this:
$ host 1.2.3.4
4.3.2.1.in-addr.arpa domain name pointer uzivatel4.poskytovatel.cz
This is to verify that the reverse DNS record for IP address 1.2.3.4 exists. Now a corresponding forward listing:
$ host uzivatel4.poskytovatel.cz
uzivatel4.poskytovatel.cz has address 1.2.3.4
OK, there is a forward DNS record and leads to the correct IP address.

The most common mistakes

The most common error is the absence of a reverse DNS record (the first command host returns 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 correction

DNS 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.

Full block IP address

To protect the services provided by FI MU, attempts to access prohibited ports of prohibited or non-existent machines are tracked. If a machine repeatedly accesses prohibited forbidden ports, its behavior is evaluated as an attempted unauthorized intrusion into FI MU, and access to FI MU is completely blocked for 24 hours. After a credible explanation of the behavior, CVT FI MU may terminate the blocking prematurely. In case of repeated incidents, blocking is permanent.