RouterOS - przekierowanie portów nie działa (brak dostępu do serwera z zewnątrz)

max1234 · 12 Lipiec 2014 18:11

ownCloud zainstalowałem z pilku .tar.bz2 właśnie w /mnt.

Wyniki poleceń:

ls -l /mnt:

total 152
drwxr-xr-x 22 http http 4096 Jun 24 09:10 3rdparty
-rw-r--r-- 1 http http 586 Jun 24 09:09 AUTHORS
-rw-r--r-- 1 http http 34520 Jun 24 09:09 COPYING-AGPL
drwxrwxrwx 26 http http 4096 Jun 24 09:10 apps
drwxrwxrwx 2 http http 4096 Jul 3 04:41 config
-rw-r--r-- 1 http http 916 Jun 24 09:10 console.php
drwxr-xr-x 14 http http 4096 Jun 24 09:10 core
-rw-r--r-- 1 http http 3480 Jun 24 09:10 cron.php
drwxrwx--- 3 http http 4096 Jul 5 09:47 data
-rw-r--r-- 1 http http 24040 Jun 24 09:10 db_structure.xml
-rw-r--r-- 1 http http 179 Jun 24 09:09 index.html
-rw-r--r-- 1 http http 1084 Jun 24 09:10 index.php
drwxr-xr-x 99 http http 4096 Jun 24 09:10 l10n
drwxr-xr-x 5 http http 4096 Jun 24 09:10 lib
-rw-r--r-- 1 http http 279 Jun 24 09:09 occ
drwxr-xr-x 2 http http 4096 Jun 24 09:10 ocs
drwxr-xr-x 9 http http 4096 Jul 3 05:42 phpmyadmin
-rw-r--r-- 1 http http 806 Jun 24 09:10 public.php
-rw-r--r-- 1 http http 1212 Jun 24 09:10 remote.php
-rw-r--r-- 1 http http 26 Jun 24 09:09 robots.txt
drwxr-xr-x 6 http http 4096 Jun 24 09:09 search
drwxr-xr-x 9 http http 4096 Jun 24 09:10 settings
-rw-r--r-- 1 http http 1447 Jun 24 09:10 status.php
drwxr-xr-x 2 http http 4096 Jun 24 09:09 themes
-rw-r--r-- 1 http http 149 Jun 24 09:11 version.php

whereis owncloud:

owncloud:[root@alarmpi /]#

([root@alarmpi /]# to znak zachęty - pojawił mi się on w tej samej linii, co wynik tego polecenia)

netstat -lnp | egrep “(80|443)”:

tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 302/httpd
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 302/httpd

Wyniki poleceń RouterOS:

ip address print:

Flags: X - disabled, I - invalid, D - dynamic 
 # ADDRESS NETWORK INTERFACE                              
 0 192.168.1.1/24 192.168.1.0 ether1                                 
 1 192.168.100.189/24 192.168.100.0 wlan1

interface ethernet print:

Flags: X - disabled, R - running, S - slave 
 # NAME MTU MAC-ADDRESS ARP MASTER-PORT SWITCH     
 0 R ether1 1500 D4:CA:6D:88:39:BD enabled none switch1

ip firewall nat print:

Flags: X - disabled, I - invalid, D - dynamic 
 0 chain=srcnat action=masquerade src-address=192.168.1.0/24 

 1 chain=srcnat action=masquerade out-interface=ether1 

 2 chain=dstnat action=dst-nat to-addresses=192.168.1.248 to-ports=80 
     protocol=tcp dst-address=62.233.xxx.xxx dst-port=80 

 3 chain=dstnat action=dst-nat to-addresses=192.168.1.248 to-ports=443 
     protocol=tcp dst-address=62.233.xxx.xxx dst-port=443 

 4 chain=dstnat action=dst-nat to-addresses=192.168.1.248 to-ports=80 
     protocol=tcp dst-address=62.233.xxx.xxx dst-port=81

Uznałem, że bez sensu jest cenzurować lokalny adres Raspberry Pi. 62.233.xxx.xxx to IP zewnętrzne.

To, że nie mógłbym tych adresów użyć, to wiem, ale nie do końca znałem przyczynę takiego zachowania routera. Teraz już rozumiem, dzięki za wytłumaczenie

roobal · 12 Lipiec 2014 19:47

Teraz podaj mi wyniki poniższych poleceń.

cat /mnt/index.html
ifconfig

I napisz gdzie zainstalowany jest ownCloud, polecenie whereis go nie znajduje (możliwe, że ma inną nazwę).

Problem leży prawdopodobnie w konfiguracji serwera, bo samo przekierowanie działa.

max1234 · 12 Lipiec 2014 19:54

cat /mnt/index.html:

<!DOCTYPE html>
<html>
<head>
        <script type="text/javascript"> window.location.href="index.php"; </script>
        <meta http-equiv="refresh" content="0; URL=index.php">
</head>
</html>

ifconfig:

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
        inet 192.168.1.248 netmask 255.255.255.0 broadcast 192.168.1.255
        ether b8:27:eb:df:a5:8d txqueuelen 1000 (Ethernet)
        RX packets 31765 bytes 12503579 (11.9 MiB)
        RX errors 0 dropped 702 overruns 0 frame 0
        TX packets 23607 bytes 3236659 (3.0 MiB)
        TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
        inet 127.0.0.1 netmask 255.0.0.0
        loop txqueuelen 0 (Local Loopback)
        RX packets 97 bytes 7708 (7.5 KiB)
        RX errors 0 dropped 0 overruns 0 frame 0
        TX packets 97 bytes 7708 (7.5 KiB)
        TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

ownCloud jest zainstalowany tam, gdzie napisałem w poprzednim poście - właśnie w /mnt (instalowałem go z pliku .tar.bz2 ściągniętego z oficjalnej strony).

anon33704549 · 12 Lipiec 2014 20:11

W /mnt bezpośrednio czy w jakimś katalogu?

max1234 · 12 Lipiec 2014 20:26

Bezpośrednio. Pod /mnt zamontowany jest dysk twardy.

anon33704549 · 12 Lipiec 2014 20:35

A plik, który ci wyświetla It works gdzie jest? Czy to Apache generuje na żywca po instalacji (nie pamietam jak to szło dawno Apache nie używałem).

roobal · 12 Lipiec 2014 20:39

W dyrektywie.

<IfModule dir_module>
    DirectoryIndex index.html
</IfModule>

Dodaj po index.html jeszcze index.php.

Po instalacji ownCloud restartowałeś Apache? Bo wygląda na to, że wyświetla cały czas domyślną stronę zarówno na porcie 80, 443 jak i 81 (przed chwilą sprawdzałem po twoim IP).

Czy oprócz Mikrotika korzystasz jeszcze z jakiegoś innego routera? Bo widzę, że masz adresację dla LAN i WiFi, a dla WAN nie masz.

max1234 · 12 Lipiec 2014 21:12

@struart, nigdzie nie ma pliku z “It works!”. Wygląda na to, że Apache sam go generuje albo jest w takim miejscu, do którego nie mam dostępu.

@roobal, po dopisaniu “index.php” i zrestartowaniu Apache sytuacja jest ta sama. Ale zauważyłem, że u mnie na porcie 443 zamiast “It works!” wyświetla się błąd “Bad Request”. Reszta portów pokazuje to samo, co przedtem. Poza tym po instalacji ownCloud restartowałem Apache jeszcze kilkanaście razy (w celach konfiguracyjnych) i mam tylko jeden router.

roobal · 13 Lipiec 2014 01:02

To jest domyślny plik Apache i on go wyświetla. Jeśli masz Apache, to plik powinien być w /var/www/index.html. Nie napisałeś gdzie jest ownCloud, bo często tego typu panele mają własne konfiguracje dla Apache, Nginx i Lighttpd.

Jak wchodzę na twoje IP, to wyświetla się “It works”, więc Apache działa (oczywiscie mówie o https, zresztą na porcie 81 też wyświetla się It works).

Dlaczego w takim razie ip address print nie pokazuje adresacji dla portu WAN?

max1234 · 13 Lipiec 2014 09:42

Tyle że u mnie w ogóle nie ma katalogu /var/www. Poza tym strona “It works!” wyświetlała się jeszcze przed postawieniem i uruchomieniem Apache (wcześniej nie miałem żadnego postawionego serwera). Jeśli chodzi o lokalizację ownCloud, to jak już pisałem 2 razy, instalowałem panel z paczki .tar.bz2, a konkretnie rozpakowałem ją do katalogu /mnt i później skonfigurowałem z poziomu przeglądarki. Apache, PHP i MySQL wgrałem pacmanem.

Tu akurat jest moja wina, wchodziłem na port 443 bez https:// na początku. Jak wpiszę https, to nie ma już błędu “Bad Request”.

Na początku nie wiedziałem, dlaczego. Poszedłem więc zobaczyć, jak router jest podłączony. Ogółem wygląda to tak, że są cztery wtyczki LAN i jedna wtyczka WAN (wszystkie na wtyk RJ-45). Nic nie jest podłączone do wtyczki WAN (dlatego nie ma dla niej adresacji). Router połączony jest z siecią za pośrednictwem kabla sieciowego podłączonego z jednej strony do pierwszej wtyczki LAN, a z drugiej strony do urządzonka nazywającego się “Ethernet Adapter” (jest ono dodatkowo podłączone do prądu). Z niego wychodzi inny kabel (z wtykiem RJ-45), który chyba idzie do skrzyneczki na dachu (w domu jest internet radiowy).

roobal · 13 Lipiec 2014 12:57

Nie masz czasem AP Mikrotika (lub innego producenta) na dachu? Jeśli tak, to prawdopodobnie na AP trzeba zrobić przekierowanie.

Widocznie musiał działać inny serwer www, choć domyślnie powinien się wyświetlać panel konfiguracji RouterOS, jeśli nie ma przekierowań.

max1234 · 13 Lipiec 2014 13:29

Tego to akurat nie wiem. A jak zrobić przekierowanie na AP? Jeśli będzie to możliwe do skonfigurowania z poziomu routera, to wtedy spróbuję - może wówczas zadziała.

roobal · 13 Lipiec 2014 16:15

Na AP logujesz się po adresie bramy do internetu. RouterOS ma na LANie adres w sieci 192.168.1.0/24 i ma adres 192.168.1.1, więc prawdopodobnie router na dachu ma 192.168.1.254. Ewentualnie sprawdź w tablicy routingu poleceniem.

ip route print

Jeśli nie można zalogować się do AP, niech dostawca ustawi go w tryb mostu lub niech wyłączy NAT, lub zrobi Ci przekierowanie. Bo wygląda na to, że przed twoim routerem jest jeszcze inny router. Jeśli ustawi w tryb bridge lub wyłączy NAT, wówczas NAT ustawiasz na swoim routere i dopiero wtedy robisz przekierowania.

Możesz jeszcze pokazać wynik polecenia.

interface print

Tamto pokazywało tylko interfejsy ethernet, to pokazuje wszystkie.

Sprawdźmy jeszcze trasę jaką pokonują pakiety. Możesz to zrobić na dowolnym hoście, może to być z Windows, może być z Linuksa.

Polecenie dla Windows

tracert dobreprogramy.pl

Polecenie dla Linuksa.

traceroute dobreprogramy.pl

max1234 · 13 Lipiec 2014 17:37

Na 100% adresem AP jest 192.168.100.1. Tak wynika z wyniku polecenia ip route print:

# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
 0 A S 0.0.0.0/0 192.168.100.1 1
 1 ADC 192.168.1.0/24 192.168.1.1 ether1 0
 2 ADC 192.168.100.0/24 192.168.100.189 wlan1 0

Na to wskazuje też wynik polecenia tracert dobreprogramy.pl:

Tracing route to dobreprogramy.pl [194.0.171.150]
over a maximum of 30 hops:

  1 <1 ms <1 ms <1 ms 192.168.1.1
  2 4 ms 6 ms 6 ms 192.168.100.1
  3 7 ms 6 ms 6 ms 87-204-xxx-xx.ip.netia.com.pl [87.204.xxx.xx]
  4 7 ms 6 ms 6 ms 83-238-xx-xxx.ip.netia.com.pl [83.238.xx.xxx]
  5 9 ms 12 ms 7 ms toruh001rt04-xxxxxxxxxxxx.inetia.pl [87.204.xxx.
x]
  6 17 ms 11 ms 18 ms toruh001rt05-xxxxxxxxxxxx.inetia.pl [83.238.xxx.
xx]
  7 11 ms 11 ms 15 ms warsc001rt06-xxxxxxxxxxxx.inetia.pl [81.210.xxx.
xxx]
  8 22 ms 19 ms 17 ms xenium.plix.pl [195.182.218.145]
  9 12 ms 11 ms 10 ms nlb-web.xenium.pl [194.0.171.150]

Trace complete

(część adresów ocenzurowałem)

Jeszcze interface print:

Flags: D - dynamic, X - disabled, R - running, S - slave 
 # NAME TYPE MTU L2MTU MAX-L2MTU MAC-ADDRESS      
 0 R ether1 ether 1500 1598 2028 D4:CA:6D:88:39:BD
 1 R wlan1 wlan 1500 2290 D4:CA:6D:88:39:BE

Najciekawsze w tym jest to, że jak wpisuję do przeglądarki 192.168.100.1, to wyświetla mi się “It works!”, czyli dokładnie ta sama strona, jaka w tej chwili pojawia się na zewnętrznym IP. Jednak żadnego panelu logowania nie ma. Czy kontakt z dostawcą jest konieczny do rozwiązania problemu?

Ta skrzynka na dachu jest od paru lat nietknięta, a RouterOS działa dopiero od ok. roku. Przedtem przekierowanie portów działało…

roobal · 13 Lipiec 2014 19:13

Czyli przekierowanie powinno być robione na interfejs wlan, a router powinien już znaleźć odpowiedni host w podsieci 192.168.1.0/24. Ewentualnie możesz ustawić most pomiędzy ether i wlan. Gdyby nic z tych rzeczy nie pomogły, zresetuj ustawienia i skonfiguruj router na nowo.

Wywalasz wszystkie reguły dla NAT i tworzysz nowe.

ip firewall nat add chain=srcnat action=masquerade out-interface=wlan1
ip firewall nat add chain=dstnat dst-address=63.233.x.x dst-port=80 action=dst-nat to-addresses=192.168.100.189 to-ports=80

Jeśli router nie będzie mógł sobie poradzić z takim przekierowanie, stwórz bridge między ether i wlan. Rozumiem, że ten adres 192.168.100.189 router dostaje z tej skrzynki na dachu tak? Jeśli tak, to przekierowanie powinno się robić na AP, bo on wykonuje NAT. Tak też wynika z trasowania pakietu, co widać z polecenia tracert.

Jeśli nie ma możliwości zalogowania się do AP, to tak. Możesz jeszcze przeskanować nmapem jakie porty są otwarte, być może panel działa na innym, niż 80 porcie lub dostęp jest tylko przez telnet lub ssh.

W sieci wewnętrznej Ci działa, ponieważ router wykonuje routing między podsieciami, a nie translację pakietów.

max1234 · 14 Lipiec 2014 21:16

Skontaktowałem się z dostawcą neta i raczej nie pójdzie mi na rękę

Na pewno nie ma innego sposobu na rozwiązanie problemu? Jeśli nie, to wtedy trudno - pogodzę się z tym.

Poza tym te reguły też nie działają - dalej z zewnątrz 62.233.xxx.xxx pokazuje “It works!”.

roobal · 15 Lipiec 2014 00:10

Z tego wszystkiego wynika, że NAT działa na AP. Jeśli tak jest, to nic nie zrobisz.