Basic limitationsAccess to the faculty network is restricted to increase its security. The restriction generally applies to accesses from the non-university network, ie from domains other than muni.cz (IP prefix 147.251 or 2001: 0718: 0801: 02NN). Generally, all privileged ports of all machines are blocked except for these selected services, which are also available from outside:
- SSH, IMAP (s), POP3 (s) on Aisu 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 implemented by CVT FI upon request.
SSH on ports 80, 443Some Internet providers (hotels, conferences, ...) restrict users to the use of ports to access the web [http (80) / https (443)]. There is no possibility to use SSH service on port 22. For the needs of FI employees (and other users with access to the Anxur employee server) we provide the possibility to use SSH on ports 80 and 443 at anxur-ssh.fi.muni.cz:
ssh -p 80 firstname.lastname@example.org
SSH tunnels (port forwarding) and jump hostsIf you need to connect to a service that is available only from the faculty or university network, it is possible to use the SSH tunnel. Using the SSH tunnel, the connection is established from the machine to which the user has access via SSH (eg Aisa, where access to the faculty services is not restricted), but accesses the service on the selected port on the user's machine.
doma$ ssh -L 13306:db.fi.muni.cz:3306 email@example.comThe above command brings the MySQL port of the machine db.fi.muni.cz to port 13306 of the machine at home, so that the user can connect to his database on the faculty database server from the machine at home by the following command:
doma$ mysql -h localhost -p 13306 -u login -p
Similar instructions for PuTTY client on Windows can be found in various versions on the Internet.
If the target service is SSH to the machine on the FI network, try to use it SSH jump hosts , for example:
ssh -J firstname.lastname@example.org login@nymfeNN.fi.muni.cz.
DNS Problems (or: Aisa Rejects Connection)To connect to some services (including SSH on Ais), it is necessary to connect from an IP address that has correctly configured DNS. This means that there must be a reverse (PTR) DNS entry for this IP address, and for the name that this entry points to, there must be a forward (A) DNS entry that leads back to the address where the user is connecting.
How to verify the consistency of DNS records?It was created for this purpose simple application at the Faculty Administration . Alternatively, verification can be performed manually on UNIX machines, eg by a program
host, on Windows then by program
nslookup.exe. Suppose that the IP address of the machine from which the user logs in is
220.127.116.11, then the verification might look something like this:
$ host 18.104.22.168 22.214.171.124.in-addr.arpa domain name pointer uzivatel4.poskytovatel.czWe have verified that a reverse DNS record for IP address 126.96.36.199 exists. Now the corresponding forward record:
$ host uzivatel4.poskytovatel.cz uzivatel4.poskytovatel.cz has address 188.8.131.52OK, there is also a forward DNS record and leads to the correct IP address.
Most common mistakesThe most common error is the absence of a reverse DNS record (the first command
hostreturn error), the absence of a forward DNS record (the second command returns an error), or the fact that the reverse and forward DNS records do not match (the second command returns a different address than the address specified by the first command).
How to rectifyUsually, the administrator of the network from which the user is connecting (or his / her ISP) is able to fix the DNS records. It should be politely requested and, where appropriate, referred to RFC 1912 "Common DNS Operational and Configuration Errors", where Section 2.1 reads:
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.