Dotaz: Mikrotik přesměrování portů do vnitří sítě

[ZAH]

Mám vnitří síť s několika subnety jako router do vnější sítě mám mikrotik s RouterOS 6.47.4 vše vypadá normálně a funguje.

Přidával jsem testovací subnet a v něm je prozatím jeden Raspberry Pi s rasbianem . Na tomto stroji jsem potřeboval tři služby dostupných z internetu. Nastavil jsem na routru povolení k přesměrování tří portů nastavil NAT na Raspberry na příslušné porty a mám přístupný pouze SSH ostaní dva ne.

Nepřístupné jsou z internetu Grafana port 3000, a Node-Red 1880. Služby běží a jsou přístupné z ostatním subnetů vnitřní sítě. Předpokládal jsem chybu NAT nebo filtru, tak jsem v zoufalství nahradil cílový port nepřístupných služeb v NATU portem 22 SSH a hle na všech SSH běželo normálně.

Iptables v Raspberry by mělo povolovat vše.

Má někdo nějaký typ co otestovat. ZAH

---

---

Odpovědi

[MMMMMMMMM]

Chtělo by to vidět ta pravidla firewallu...

[ZAH]

Natovaci pravidla, funguje pravidlo 17 ostatni dvě ne.

17    chain=dstnat action=dst-nat to-addresses=192.168.157.10 to-ports=22   protocol=tcp in-interface=ether1_WAN dst-port=2422 log=yes log-prefix="SSH Jahoda" 
18    chain=dstnat action=dst-nat to-addresses=192.168.157.10 to-ports=1880 protocol=tcp in-interface=ether1_WAN dst-port=2480 log=no log-prefix="" 
19    chain=dstnat action=dst-nat to-addresses=192.168.157.10 to-ports=3000 protocol=tcp in-interface=ether1_WAN dst-port=2430 log=yes log-prefix="Grafana" 

Pravidlo 19 po zapnuti logovani zapisuje.

[vencour]

Takže jen u 17 přibývají data (bajty, pakety) ve výpisu pravidel nebo jen u 17 se dostanete na cílový server?

[j]

Pust si na tom RPI tcpdump a jdi se na to pripojit, pokud pakety nedorazi, pust si totez na tom mikrotikovi.

Pokud pakety dorazi, mas to blbe prave na tom rpi. A nemusi to byt jen firewall.

---

Dete s tim guuglem dopice!

[ZAH]

Příloha:

• Mikrotik smerovani (4728 bytů)

V přiloze záchyt komunikace na RPI.

1. Fungující Grafana z vnitřní sítě z jiného subnetu.

2. Fungující SSH z venku

3. Související pravidla NAT

Log Mikrotiku potvrzuje provedení pravidel přesměrování. Snifer Mikrotiku potvrzuje přijem komunikace. Komunikace se ztratí někde mezi NAT routru a RPI.

Potřeboval bych nakopnout jak zachytit a filtrovat odchozí komunikaci Mikrotiku. ZAH

[Vantomas]

Co tam je za konektivitu? Není tam nějaký DSL? Pak bych zkusil přidat pravidlo pro snížení TCP MSS.

V opačném případě se další hádání neobejde bez komplet filter forward a nat snat pravidel.

[ZAH]

Konektivitou to nebude sndartní wifi s veřejnou IP.

Mezitím jsem zachytil v logu toto.

	Drop uknown forward: in:ether1_WAN out:bridge1, src-mac ac:1f:6b:a5:xx:xx, proto TCP (SYN), 161.97.xxx.xxx:50620->192.168.157.10:3000, NAT 161.97.xxx.xxx:50620->(10.18.13.182:2430->192.168.157.10:3000), len 60

Předpokládal jsem že postačí povolit navázaná spojení.

13    ;;; Established WAN forward  connection
      chain=forward action=accept connection-state=established,related log=no log-prefix="" 

[Vantomas]

Takže už to funguje, když jsi našel další indicii?

[ZAH]

Bohužel ne, dostanu se k tomu až navečer. Pak budu hledat dál.

[ZAH]

Fajn. Nejspíš tam je problém s tím pravidlem okolo navázaných spojení a že nejsou povolená nová spojení z venku. Když jsi zkoušel měnit ta DNAT pravidla směřem na port 22 a to, že ti to ssh šlo otevřít, tak to prostě byla jen náhoda v tom, že v conntrack tabulce zůstala nějaká stará spojení a ta nová pak spadla do "related".

No a pak taky pozor na to, že dst-porty ve filteru musí být ty na které se dělá DNAT, protože po pohledu do schéma je vidět, že se nejprve prochází NAT pravidla a pak teprve FILTER.

[ZAH]

Bingo ! . Nejprve prochází NAT, takže ve filter musí být DST port z NATU pro porty kdy, je pouze přesměrování do vnitřní sítě si to nemusíme uvědomovat.