Kicsit még utánanéztem a kérdésnek. Az IP lista figyelembe veszi a domén névhez tartozó IP cím lejárati idejét is, és újra lekérdezi amikor lejár. A saját dyndns esetében ahogy nézem 1 perc alatti időközzel frissül.

Valóban. Ezért is volt kérdés, mert soha nem próbáltam. Persze, így lehet egy minimális olyan időintervallum, amikor nem működik, mert még a régi IP cache-elt.

Egyébként az utolsó szabálynál (ami ugye a harpin nat-hoz kell) miért 192.168.0.0/16 a dst-address?

Alex

Azért 192.168.0.0./16 mert nem csak 192.168.9.x hálózatom van (bár az az elsődleges), így viszont univerzális, mert minden 192.168. kezdetű célcímre működni fog. Tehát ha monmdjuk a 192.168.10.10 címen is fut egy szolgáltatás, amit a oruter forwardol, akkor azt is el lehet érni a 192.168.9.x hálózatból a külső IP-re hivatkozva.

[ Szerkesztve ]

Jogos a felvetés, ennyi információval nem sok mindent lehet kezdeni. Mea culpa. Ámbár úgy fest rájöttem a hiba okára. Én voltam az. valószínűleg véletlenül töröltem a szeparált wifi scrnat profilját. A fő hálózatnak címeire meg volt, de ennek nem. Létrehoztam és így már megy. Köszönöm szépen a segítséget még egyszer!

Hali!

A korábbi NAT fordítgatásra:

Nos, én nem szeretek külső elem(ek)től függni, márpedig ez a MikroTik DDNS tipikusan ilyen, nem nálam fut, nem én felügyelem, szóval nem egy főnyeremény véleményem szerint.

Az alapötletet tehát kissé átdolgoztam, íme.

Ekold leírása alapján felvettem az alábbi szabályt, és a tényleges portátirányítást:

add action=masquerade chain=srcnat dst-address=192.168.0.0/16 src-address=192.168.43.0/24 comment="required to use the public IP in LAN same as WAN"
add action=dst-nat chain=dstnat dst-address-list=wan dst-port=1194 protocol=udp to-addresses=192.168.43.6 comment="openvpn"

Utána létrehoztam a /ip firewall address-list helyen a WAN listát, egy elemmel, ami a publikus WAN címem.

Na ehhez csináltam egy olyat, hogy PPPoE on_up esetén lefuttat egy szkriptet, ami a PPPoE interfész címével felülírja a korábbi WAN címet az address_list esetében. Így gyakorlatilag ha van net, nincs olyan eset, hogy ne működne a szabály belső hálóról WAN címre.

Ha kiadok egy /interface pppoe-client majd disable 0 enable 0 sort, az ekvivalens a PPPoE szakadással? Az a baj, hogy a 168 óra leteltével nem leszek a router közelében, tehát ha meggárgyul, elég nehezen tudom helyrerakni, szóval valahogy kéne tesztelni. DIGI a szolgáltatóm.

üdv, adika4444

Sziasztok!

Én ez alapján csináltam annak idején a Hairpin NAT-ot, és tökéletesen működik mindenféle address list piszkálás nélkül, DIGI-vel.
Egy NO-IP DDNS ugyan fel van húzva, de ez a működés szempontjából indifferens.

Kiragadott részlet, de pl. a Transmission kliens sora így néz ki + masquerade:

/ip firewall nat
add action=masquerade chain=srcnat out-interface=pppoe-DIGI
add action=masquerade chain=srcnat comment="Hairpin NAT" dst-address=\
!192.168.0.1 src-address=192.168.0.0/24
add action=dst-nat chain=dstnat comment="Zyxel NAS" dst-address=\
!192.168.0.0/24 dst-address-type=local dst-port=\
51515 protocol=tcp to-addresses=192.168.0.2

[ Szerkesztve ]

ez mind szuper, de ha nem vagy otthon, akkor honnan tudod hogy mi az új IP címed, és még fontosabb, hogy pl a böngésződ honnan tudja?
mert nyilván azért kell a hairpin NAT, hogy bentről is elérj valamilyen, alapvetően kintről elérhető szolgáltatást...
a DDNS erre megoldás, míg a szkripted - ha jól értem a működését - nem

Gvella Glan! | There are two types of people: Those who can extrapolate from incomplete data

Köszi az ötletet, de a PPPoE miatt kérdéses az egész. Lehet marad a fapados módszer, kihúzom a kábelt aztán visszadugom

(#8058) Lenry:
Félreérthetőre sikeredett. Tehát a cél az annyi, hogy a szkript minden köztes megoldás nélkül nyerje ki a WAN címemet. Én már használok DDNS-t az eléréshez, csak a cél az, hogy ahol nem kell, ott ne használja, így ha például leáll, annak nincs kihatása a router ezen részére.

[ Szerkesztve ]

üdv, adika4444

No itt akkor egyben mindenkinek:

A WAN cím arra kell, hogy a routeren belül ne kelljen DDNS. Duckdns-t használok a home serveremen, az teljességgel kielégíti az igényeimet.

No de akkor jöjjön a gyakorlati rész.

A linkelt szkript hát bizonybizony hibás, a delay-jel kellett játszani, meg a parancsok sorrendjével. Így sem elegáns, mert ellenőrízhetné, hogy tényleg van-e kapcsolat mielőtt v6-ot kér, de jó ez most. A másik probléma, hogy bár a lease 00:10:00-ra van téve, még is valami bődület magasat oszt ki mindig a v6-os DHCP szerver, ami rohadtul nem kerek abban a formájában.

Na tehát akkor az én beállításaim. Lan tartományom 192.168.43.0/24, ether1 a bejövő portom.

#Beallitjuk a PPPoE-t (akinek be van, az csak set-tel lojje be a service name-t digi-re)
/interface pppoe-client
add add-default-route=yes disabled=no interface=ether1 keepalive-timeout=\
disabled name=pppoe-digi password=<ppp-login-pass> service-name=digi \
use-peer-dns=yes user=<mindenkinek_a_sajatja>
#Meghivjuk a szkriptemet, ami a PPPoE ujracsatlakozasnal ujrainditja az IPv6-ot, ill. a WAN cimlistat is beallitja.
/ppp profile
set *0 on-up=pppoe-digi-reconnect
#Felveszunk egy cimet, hogy legyen mit modositani a kov. ujracsatnal, amikor is a 0.0.0.0 a realis WAN cimunkre fog cserelodni
/ip firewall address-list
add address=0.0.0.0 list=wan
#Ekkold leirasaban volt, nelkule is mukodik a net, de ha mar van hat miert ne legyen beallitva
/ip firewall mangle
add action=change-mss chain=forward comment="PPPoE MTU" new-mss=1440 \
out-interface=pppoe-digi passthrough=yes protocol=tcp tcp-flags=syn \
tcp-mss=!0-1440
#NAT beallitasa, a masodik szabaly a kulso cim belso hasznalathoz kell
/ip firewall nat
add action=masquerade chain=srcnat out-interface=pppoe-digi src-address=\
192.168.43.0/24
add action=masquerade chain=srcnat dst-address=192.168.0.0/16 src-address=\
192.168.43.0/24
#IPv6
/ipv6 address
add address=::1 from-pool=digi interface=br-lan
/ipv6 dhcp-client
add add-default-route=yes interface=pppoe-digi pool-name=digi request=\
address,prefix
/ipv6 nd
add advertise-dns=yes interface=pppoe-digi ra-lifetime=none
/ipv6 route
add distance=1 gateway=pppoe-digi
#IPv6-os DHCP szerver. Lathato, hogy a lease 10 perc, csak ezt ignoralja a rendszer a gyakorlatban.
/ipv6 dhcp-server
add address-pool=digi interface=br-lan lease-time=10m name=dhcp-digi6
#vegul a szkript
/system script
add dont-require-permissions=no name=pppoe-digi-reconnect owner=admin policy=\
read,write,policy,test,sniff,sensitive,romon source=":execute {/ipv6 pool \
remove digi}\
\n:execute {/ipv6 dhcp-client disable [find interface=pppoe-digi]}\
\n \
\n:delay 3\
\n:execute {/ipv6 dhcp-client enable [find interface=pppoe-digi]}\
\n:delay 3\
\n:execute {/ipv6 dhcp-server disable [find name=dhcp-digi6]}\
\n:execute {/ipv6 dhcp-server enable [find name=dhcp-digi6]}\
\n\
\n:global ipaddress [/ip address get [find interface=\"pppoe-digi\"] addre\
ss ];\
\n:for i from=( [:len \$ipaddress] - 1) to=0 do={ \
\n\t:if ( [:pick \$ipaddress \$i] = \"/\") do={ \
\n\t\t:global newipaddress [:pick \$ipaddress 0 \$i]\
\n\t} \
\n}\
\n:execute {/ip firewall address-list set [find list=\"wan\"] address=\$ne\
wipaddress}"

Egy kézi PPP reconect után pedig örömmel jelentem, hogy szépen az új prefixet osztogatja a v6-os DHCP szerver és frissült a címem a tűzfalon

Ami még fontos, hogy mivel a PPPoE interfész címét használja, ezért ha benatol a DIGI, akkor a NAT-olt cím lesz a listán (100.64.0.0/10)

Nem vagyok egy nagy mágus a témában, szerda óta MikroTik-ezek, szóval ha valami nem elég precíz, akkor javítsatok!

üdv, adika4444

IPv6-nál nincsen NAT.
A NAT a v4-re vonatkozik.

üdv, adika4444

Igen, szokásuk sajnos. Rám még nem sújtott le az átok, 2016 januárja óta vagyok DIGI-s.

üdv, adika4444

Thx! Tetszik az otlet.

Igen, elvileg meg lehet oldani. Odáig már eljutottam, hogy ha 100-zal kezdődik az IP, akkor NAT, ha nem, akkor nem NAT. Csak ugye a NAT tartománya a 100.64.0.0/10 ami annyit tesz, hogy 100.64.0.0 és 100.127.255.255 közti lehet az IP. Tehát ha 100-zal kezdődik, akkor meg kell vizsgálni a második blokkot, és ha az >= 64 és <= 127, na akkor van NAT. A DIGI-nek elvileg nincsen publikus IP-je ami 100-zal kezdődik, tehát elméletileg elég a cím elejének vizsgálata, de igazából ha már lúd, legyen kövér alapon érdemes ellenőrizni ezt is.

üdv, adika4444

Szerintem sokkal egyszerűbb a WAN interface IP címét összehasonlítani pl. ezzel. Így nem kell az IP tartományokkal foglalkozni. Ha különbözik, akkor NAT-olt, ha egyezik, akkor nem.

Alex

nem értem ezt a túlbonyolítást.
leszeded a wan interfész címét, kiszámolod a hálózati részét, és ha beleesik a cgn-be, akkor natolva vagy.
lásd: manual bitwise operators

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Erre azt a megoldást használom, hogy megnézem a /ip cloud által láttott külső IP-t a pppoe interfész IP címével. Ha egyezik akkor nem NAT-olt a cím.

Valóban lehet erre scriptet is írni, de igazából amikor erre szükség van, akkor úgyis éppen otthon vagy, hiszen bentről kell elérned a külső címed.
Ha nem bízol a dyndns-ben arra is vannak jó megoldások, nekem pl. az a másodlagos megoldásom, hogy a weblapomon van egy PHP, aminek a router időnként elküldi néhány adatát. Így ha a dyndns nem működne, a weblapomon akkor is meg tudom nézni, hogy mi a routerem IP címe, mikor jelentkezett utoljára erről a címről a router, és mi a dyndns neve. Ez a PHP több router adatait is tudja fogadni, és szépen összerakja egy táblázatba az adatokat.

Kreatív, asszem én is készítek egy ilyet.

üdv, adika4444

Nekem van egy CHR mikrotik-em egy felhő szolgáltató virtuális gépén amihez van egy fix IP, ide l2tp/ipsec, ide jövök be az összes általam kezelt router-rel, a notebook-ról vpn-nel csatlakozom és innen minden eszközömet elérem. Nem gond a NAT, a változó WAN IP....stb.

Sziasztok!

Tudtok adni útmutatót, hogy milyen szabályok ajánlatos a tűzfalnál és a nat-nál létrehozni?
MikroTik hAP ac2

Köszi!

Mindent engedsz amire szükséged van, az összes többit pedig tiltod.

Leírásra, ajánlásra, best practice-ra gondoltam..

Valami ilyesmire gondoltál? [link]

Ez tetszik 😊

Sziasztok!

Nemrég vettem egy Mikrotik hAP ac^2-t. Telekomos optikai internetem van.
Ha úgy állítom be, hogy a Sagemcom ONT csinálja a PPPoE kapcsolatot és a mikrotik a wan-nak beállított portján dhcp kliensként kap ip-t, akkor a mikrotikra kötött eszközökön rendben van az internet sebessége (~900 Mbit le, 980 Mbit fel). De ez így nekem nem jó, így dupla NAT-olás van...
Ha a mikrotik csinálja a PPPoE kapcsolatot, akkor a letöltési sebesség rendben van, viszont a feltöltési sebesség csak 200 Mbit.
Mit állítok be rosszul? Az alábbi képeken láthatóak a jelenlegi PPPoE-s beállításaim. Lereseteltem a routert úgy, hogy ne legyen alapból beállítva semmi, utána állítottam be ezeket. (a képek készítésekor nem volt bedugva a hálókábel, amin keresztül meg a pppoe kapcsolat).

[ Szerkesztve ]

Ha tényleg nem jó a dupla NAT, akkor esetleg csak simán AP-nak konfigurálhatnád a Mikrotiket. Tehát a Sagemcom ONT osztaná mindenkinek az IP-t DHCP segítségével, a hAP ac^2 pedig csak access point-ként működne. (Ez valóban nem oldja meg a PPPoE problémát a Mikrotiken, de kompromisszumos megoldásnak jó lehet.)

[ Szerkesztve ]

Sebességmérésnél mennyin pörög a proci?
MTU size a PPPoe miatt nem célszerű kisebbre állítani?

A MAC címet nem lenne nagy ügy átmásolni a mikrotikbe...

Persze.

Alex

Nem csinál ilyet a Telekom. Beköttettük az 1000/200-at, amit még aznap felrakattunk giga/gigára. Először sagemen ment az 1000/200, utána a saját AC66U-n. Felváltás után az AC66U-n egy PPPoE reconnect után ment az új sebesség. Próbaképp megnéztem, a Sagemen is. Visszaraktam az ASUS-ra, és azóta is tökéletesen megy.

Egy hAP ac^2-re akarom cserélni majd, oda is vágna, ha nem vinné a giga/giga csomagot.

DjTomboy: Egy gépet köss rá a Sagem-re közvetlen, és azon csinálj PPPoE-t. Ha nem is hajtja ki a gigát, de ha már 200 fölé megy a felfelé irány, akkor lehet következtetni...

üdv, adika4444

Ez csak egy ötlet volt. De akár userenként más módszert is használhat a Telekom... Csak ugye gyanús az a 200 Mbps. Én megnézném egy másik routerrel is (nem a SagemCom-al). Kétlem, hogy a hAP ac² csak 200 Mbps-t tudna felfelé irányban, miközben lefelé tudja a gigabitet.

[ Szerkesztve ]

Alex

DIGI gigás neten jelenleg is jön a 800/300. Szóval legalább 300-at bírnia kell neki.
Érdekes mindenesetre a hiba, nagyon meglepődnék, ha tényleg az lenne, hogy MAC alapján korlátozgatnak. De ugye a MAC-t a MikroTik-be lehet klónozni, a Sagem meg asszem kiírja a WAN fizikai címet.

üdv, adika4444

Ez nem valami MTU vagy clam tcp to mss gond? Lehet darabolja feltöltésnél a csomagokat, ahelyett, hogy ICMP-n utasítaná a klienseket kisebb csomagméretre.

Le az elipszilonos jével, éljen a "j" !!!

Nagyon köszönöm!

Pont azt akarom elérni, hogy ne a Sagem legyen a router, így ez a megoldás nem jó.

(Egyébként a Sagem-nek sokkal jobb a wifije, mint ennek a Mikrotik-nek.)

Mármint a router procija? Megnézem majd, csak most nem tudom próbálgatni, helyileg máshol vagyok.

MTU-ra egy ilyen van beállítva:

Most néztem a Sagem-ben 1492-re van állítva az MTU.

Próbáltam ezzel-enélkül de sehogy sem volt jó.

A csomagomban 1 Gbit/s letöltési, 1 Gbit/s feltöltési sebesség van.. Ez majdnem mindig meg is van a Sagem-mel. A házban összesen két lakásba van bekötve Telekom net, így ketten osztozunk az 1,25 Gbps-on.

Ha Speedtest-et csinálok, akkor mindig több különböző szerverrel szoktam mérni egymás után és a feladatkezelőben nézem a hálózati csati sebességet. Rakok majd fel képeket, csak most nem tudok mérni.

[ Szerkesztve ]