A végpont valós IP címeket kap (pl. 178.164.227.157, majd 81.0.85.x) - mondjuk változót - de a gateway az 10.0.0.1. Ezen lehet változtatni?
Működik így is a távoli elérés. Csak nekem furcsa, hogy a szolgáltatónak miért jó így megoldani...
- 1560 megtekintés
Hozzászólások
Szolgáltatóváltás...? :-)
Amúgy ez miért probléma? Nálam szintén Digi, és szintén 10.0.0.1 a default gateway, ráadásul a tűzfalban szűröm a privát IP címek felé menő forgalmat.
- A hozzászóláshoz be kell jelentkezni
miert akarnal valtoztatni ezen?
ppp eseten egyebkent is interface-re "szokas" route-olni, nem pedig ip-re. a 10.0.0.1 ne zavarjon ossze.
ha megnezed te egy /32-es maszku ip-t kapsz. tehat nincs a "tartomanyon" belul mire route-olj. kitolsz mindent a ppp interface fele, es kesz.
Flags: D - DYNAMIC; A - ACTIVE; c - CONNECT, v - VPN
Columns: DST-ADDRESS, GATEWAY, DISTANCE
DST-ADDRESS GATEWAY DISTANCE
DAv 0.0.0.0/0 digi-pppoe 1
DAc 10.0.0.1/32 digi-pppoe 0- A hozzászóláshoz be kell jelentkezni
Sőt, mintha IPv6-nál is link local címe lenne a Digi-s átjárónak és ott se gond. Szokni kell a szemnek :D , de működik.
- A hozzászóláshoz be kell jelentkezni
attol, h ipv6, ugyanaz a deal, interface-re route-olsz, nem ip-re:
Flags: D - DYNAMIC; A - ACTIVE; c - CONNECT, d - DHCP, v - VPN
Columns: DST-ADDRESS, GATEWAY, DISTANCE
DST-ADDRESS GATEWAY DISTANCE
DAv ::/0 digi-pppoe 1Point to Point (Protocol over Ethernet)-hoz nem kell a tartomanybol atjaro. p2p.
visszefele pedig ugy jut a csomag, hogy a pppoe concentrator tudja, hogy a te aktualis /64-ed melyik ppp interface fele van.
- A hozzászóláshoz be kell jelentkezni
Én is lestem anno, de ez valószínűleg a PPP (over ethernet) velejárója lehet.
Az sokkal nagyobb baj, hogy a pppoe encapsulation következménye miatt nem működik (jól) az RSS (receive side scaling). Ezért a gigabit-es forgalmat multi-queue NIC nem tudja szétdobni multi-core CPU-nak, csak a legelsőnek. Ezért ha nincs rá valami hardveres offload trükk, 2 gigahertz alatti processzorú rúterek (pl. arm, vagy x86 sbc) nem tudják kihajtani a wire-speed gigabit routing-ot. NAT-al meg még kevésbbé. Tűzfallal és shaping-gel meg még annyira sem. A hardveres trükköknél meg ugrik a packetfiltering, logging, bandwidth monitoring és shaping.
- A hozzászóláshoz be kell jelentkezni
A hardveres trükköknél meg ugrik a packetfiltering, logging, bandwidth monitoring és shaping.
Hozzatennem, egy 2024 -ben tervezett eszkoztol mar azert elvarnam, hogy ha nem is mindet ezekbol, de legalabb a "buta" statikus ipt/nft rule-okat futtassa hardverbol. De az alapszintu traffic shaping sem ordongosseg.
- A hozzászóláshoz be kell jelentkezni
Van ilyen, de nem feltetlenul a sarki PC boltban...
- A hozzászóláshoz be kell jelentkezni
a ppp gigabit nem nagy teljesitmeny sub 1Ghz arm-en sem. pl: https://mikrotik.com/product/hap_ac2
viszont olcso mikrotiknel a szopas, hogy a NAT-ra van hwaccel es siman kitolod a gigabitet ppp-n, ipv6 meg koppol 4-500 mbps korul, mert az CPU-bol szenved. pedig csak koszos routing :)
celhardver FTW.
- A hozzászóláshoz be kell jelentkezni
kb 2 hete teszteltem hap AC2 -est openwrt vel. DHCP vel ipv4 en max 800mbitet tudott átnatolni. ipv6 ból 5-600-at. Szóval maradok az ER-X routernél, abban van hwoffload ...
Fedora 41, Thinkpad x280
- A hozzászóláshoz be kell jelentkezni
akkor valamit szarul csinalsz. ellenorizd, h megy-e a hwoffload. routeros tudja. a hakkimakki firmware meg... :) so life.
egyeb forgalom mellett:
$ iperf3 -c ping.online.net -p 5202 -t 10 -R
...
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.01 sec 1.05 GBytes 900 Mbits/sec 308 sender
[ 5] 0.00-10.00 sec 1023 MBytes 858 Mbits/sec receiver
$ iperf3 -c ping6.online.net -p 5202 -t 10 -R
...
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.06 sec 523 MBytes 436 Mbits/sec 8502 sender
[ 5] 0.00-10.00 sec 493 MBytes 413 Mbits/sec receiveres ez mar kulfold, kisebb pingu host fele van ez tobb is.
- A hozzászóláshoz be kell jelentkezni
Ez a te 2 mérésed eredménye miben merőben más (jobb?) az övéhez képest? Csak mert én nem látom azt a fölényes előnyt amit sugallni próbáltál, főleg ipv6-on nem.
- A hozzászóláshoz be kell jelentkezni
"viszont olcso mikrotiknel a szopas, hogy a NAT-ra van hwaccel es siman kitolod a gigabitet ppp-n, ipv6 meg koppol 4-500 mbps korul, mert az CPU-bol szenved. pedig csak koszos routing :)
celhardver FTW." - itt a valasz minden kerdesedre.
az, hogy nem szignifikansan tobb, arra pedig feletted egyel.
szelessav.net (kisebb ping):
| 930,49 Mbit/s | 326,16 Mbit/s |
ennyi "fer ki" a gigas linken. natolva. pppoe-n. ipv4-en. routerOS-sel. ~700MHz 32bit arm cpu+hwaccel.
- A hozzászóláshoz be kell jelentkezni
Az én tesztem otthoni hálázaton történt, azaz a belső LAN ból kapott WAN-ipt és amit natolt azon lévő szerverről iperfeltem a LAN szerverre.
Ha gondolod előveszem újra és megnézem.
Viszont tudtommal az IPQ4018 ban nincsen hw offload, talán IPQ4019 ben. És az is rémlik, hogy hiába jött ki ~800mbit a cpu elég csúcson járt.
https://www.reddit.com/r/openwrt/comments/13m0ysc/mt7621at_vs_ipq401819…
Itt is ilyet írnak:
MediaTek MT7621AT has AFE and hardware accelerator for NAT and doesn't have AQM.IPQ4018 /IPQ4019 has AQM support and doesn't have AFE/NAT
MT7621 nél inkább az idegesit hogy néha dob egy hátast a DSA driver, ha nagyobb forgalom van:
[2024/08/30 06:09:23] mtk_soc_eth 1e100000.ethernet dsa: transmit timed out
[2024/08/30 06:09:23] mtk_soc_eth 1e100000.ethernet dsa: Link is Down
[2024/08/30 06:09:23] mtk_soc_eth 1e100000.ethernet dsa: configuring for fixed/rgmii link mode
[2024/08/30 06:09:24] mtk_soc_eth 1e100000.ethernet dsa: Link is Up - 1Gbps/Full - flow control rx/tx
Fedora 41, Thinkpad x280
- A hozzászóláshoz be kell jelentkezni
franc tudja, cpu chipet nem mondja meg, csak, h arm, 4 mag.
model: RBD52G-5HacD2HnD
cpu: ARM
cpu-count: 4
cpu-frequency: 672MHz
cpu-load: 1%
v4-en nincs cpu hasznalat csak irq, ami termeszetes, hisz' interface-rol/re megy a forgalom:
/system/resource/cpu/print detail interval=1
0 cpu="cpu0" load=1% irq=0% disk=0%
1 cpu="cpu1" load=13% irq=12% disk=0%
2 cpu="cpu2" load=30% irq=30% disk=0%
3 cpu="cpu3" load=33% irq=33% disk=0%
szemben az ipv6-tal ami valamiert egy szalon "teker" (summa 100%), sajnos nem tudom mi a titok ipv6 routing eseten, de gondolom a hwaccel/multithreading hianya (aka: nincs "fastpath"):
/system/resource/cpu/print detail interval=1
0 cpu="cpu0" load=0% irq=0% disk=0%
1 cpu="cpu1" load=37% irq=37% disk=0%
2 cpu="cpu2" load=4% irq=0% disk=0%
3 cpu="cpu3" load=84% irq=84% disk=0%itthonra boven jo ez. ha valami "lassan" jon es nem tudom kivarni, mert ipv6-on tolt, akkor lecsapom az ip-t addig, aztan szalad a csigabit.
- A hozzászóláshoz be kell jelentkezni
Most látom, hogy ez mikrotik alatt méred, én meg openwrt ről beszélek ....
Másrészt ha van IRQ a cpu ban akkor az azt jelenti, hogy nincsen hw offload,
iperf3 ipv4 NAT-al ~930mbit a cpu terhelés ennyi:
Mem: 162908K used, 87644K free, 13580K shrd, 0K buff, 43684K cached
CPU: 0% usr 3% sys 0% nic 92% idle 0% io 0% irq 4% sirq
A 4% sirq pedig a routerben futo wireshark tunnel miatt van.
Fedora 41, Thinkpad x280
- A hozzászóláshoz be kell jelentkezni
én meg openwrt ről beszélek .... jeleztem fentebb a dolgot, csak elsiklottal :)
ok, de ppp-rol volt szo.
ros nem mutat kulon iowait-et, az kene latszodjon az IF forgalomtol. hogy ros ezt irq-kent ertelmezi-e. who knows. who cares.
az alapallitas viszont igyis-ugyis f*ag, hogy 2GHz+ kene gigabit nat+pppoe-hez. :)
- A hozzászóláshoz be kell jelentkezni
Emlékeim szerint, mikor pppoe-s netem volt. is ment a hwnat az MT7621 esben, Majd ha nem leszek lusta, meglesem PPPoE val.
Hogy mi kell a gigabit pppoe-hoz ? Majd meglesem akkor pppoe val hap ac2 + openwrt -t ... Persze ehhez majd ossze kell dobnom egy koncentratort, de nem nagy kaland, van benne rutinom :D
Fedora 41, Thinkpad x280
- A hozzászóláshoz be kell jelentkezni
ja, a pppoe nem nagy magic, de azert van az eszkoznek dolga vele.
ez annal inkabb
es a terminusz teknikuszra se jol emlekeztem, nem fastpath, fasttrack! :) fast a samba!
aztan mikor ver istvan felrekonfigolja a routert, megy a pislogas, hogy mitol lasssssuuuuuuuu :)
- A hozzászóláshoz be kell jelentkezni
Az alapállítás ez volt:
Ezért ha nincs rá valami hardveres offload trükk, 2 gigahertz alatti processzorú rúterek (pl. arm, vagy x86 sbc)
- A hozzászóláshoz be kell jelentkezni
kollega viszont azt mondja, h cpu-bol megy. akkor kinek van igaza? :)
- A hozzászóláshoz be kell jelentkezni
En probaltam. A pppd -nek van olyan opcioja, amivel meg tudod adni, hogy neked mi lenne a preferalt endpoint cim, de a hulye router (itt epp egy asus van) olyan pppd-t hasznal, ahol ez nagyon-nagyon nehezkes megoldani parancssorbol, raadasul mikor sikerult is, nem mukodott, maradt 10.0.0.1 a gateway. Nem tudom, miert, ennel melyebben nem volt idom/energiam beleasni magam a pppd lelkivilagaba.
En vegul azt hasznaltam ki, hogy a pppd a route tablaban 10.0.0.1/32 -t allit be, ugyhogy a 10/8 tobbi reszen szabadon lehet garazdalkodni.
Erdekes security szemszogbol btw, hogy remote oldalon atallitva az IP-t tudsz snoop-olni tetszoleges home network-ben ugye, mert a legtobb router/user nem allit be interface-t.
- A hozzászóláshoz be kell jelentkezni
tudsz snoop-olni tetszoleges home network-ben ugye > ez igy hulyeseg. amelyik IF-en ott a tartomany, az a tartomany arra interface-re van routeolva...
ha meg nincs olyan tartomany, tokmindegy mit csinalsz a ppp felol, az a csomag nem fog menni sehova.
aki meg osszebridge-eli a WAN-jat a LAN oldallal, az hagyja abba amit csinal :D
DST-ADDRESS GATEWAY DISTANCE
DAc 192.168.2.0/24 br-lan 0
maradt 10.0.0.1 a gateway. > ez sem igaz, csak ha buta/bena az eszkoz. ilyenkor az tortenik, hogy megmondod, h a ppp IF fele van a 10.0.0.1/32 es esetleg arra route-olsz, de ez "kerulo megoldas", alapvetoen nem IP-re, hanem interface-re route-olunk, ahogy fentebb is irtam.
- A hozzászóláshoz be kell jelentkezni
ezt mond meg az asusnak is.
- A hozzászóláshoz be kell jelentkezni
marmint mit? en nem lattam asus linuxan hogy nez ki a route tabla meg a bridge-ek. ha megmutatod, megszakertem neked szivesen. (ha webfeluletes bullshit, az nem erdekel, oda mindenki azt hazudik amit akar)
- A hozzászóláshoz be kell jelentkezni
# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.0.0.1 0.0.0.0 UG 0 0 0 ppp0
9.9.9.11 10.0.0.1 255.255.255.255 UGH 1 0 0 ppp0
10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 br0
10.0.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
149.112.112.11 10.0.0.1 255.255.255.255 UGH 1 0 0 ppp0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
192.168.101.0 0.0.0.0 255.255.255.0 U 0 0 0 br1
192.168.102.0 0.0.0.0 255.255.255.0 U 0 0 0 br2
239.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 br0
ez az asus route tablaja, amit a GUI csinal.
van ugye /32 a PPP ip-re, meg meg 1-1 a DNS IP-re.
- A hozzászóláshoz be kell jelentkezni
tehat all amit mondtam:
ilyenkor az tortenik, hogy megmondod, h a ppp IF fele van a 10.0.0.1/32 es esetleg arra route-olsz, de ez "kerulo megoldas", alapvetoen nem IP-re, hanem interface-re route-olunk, ahogy fentebb is irtam.
eloszor megmondja, h a 10.0.0.1 a ppp0-an lakik - ez az interface-re route-olas. es oda route-olja a 0.0.0.0/0-at.
mondhatna, h a 0.0.0.0/0 van a ppp0 fele, de nem teszi.
utana meg azt mondani 1-1 ip-re, h szinten a 10.0.0.1 fele van, gyakorlatilag ertelmetlen. a 0.0.0.0/0-ban ott van az is.
szerk: annyiban lehet ertelme a dns-t direkt valamerre route-olni, ha valamilyen failover megoldas/dual uplink van es a szolgaltato dns szervere a masik uplink fele nem szolgal ki.
- A hozzászóláshoz be kell jelentkezni
Nem szolgáltatóváltás, hanem második szolgáltató failover.
Igazatok van, mert a gateway ellenére megy egyébként a távoli elérés.
Az ügyfélkapun át lehet kapcsolni a modemet bridge módba egyszerűen.
A sebesség gyors.
"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."
- A hozzászóláshoz be kell jelentkezni
Hol nézted a 10.0.0.1-es átjárót? Most megnéztem valakinél, a router logjában tányleg annyi. A szolgáltató eszköze nála ridge módban van, és nálad?
- A hozzászóláshoz be kell jelentkezni
Bridge módban van a modem és a rákötött router felületén néztem. A port forwarding viszont működik. Ezek szerint publikus IP-t NAT-olnak. Nyilván ilyen a rendszerük - hát érdekes. A Telekomnál a publikus IP-hez nem NAT-olt gateway tartozik.
"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."
- A hozzászóláshoz be kell jelentkezni
Ezek szerint publikus IP-t NAT-olnak.
Miért kéne NAT -olni ? Attól hogy a te publikus IP-d következő hop-ja egy privát IP nem jelent semmi. Ez az ő belső routinguk. Gondolom valahol majd lesz olyan, ahol belsőből kilép publikusra.
Sok helyen már belső routingra is nem public IP-t használnak, hogy ne pazaroljanak. Nem szép megoldás, de semmi se szól ellene ...
Fedora 41, Thinkpad x280
- A hozzászóláshoz be kell jelentkezni
Hát igen, lehet ilyen a belső routing, csak nekem furcsa.
"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."
- A hozzászóláshoz be kell jelentkezni
technikailag nincs kulonseg "kulso" meg "belso" tartomanyok kozt. azert jottek letre, hogy legyen egysegesen hasznalhato tartomany, amit "by default nem route-olunk a vilagba".
barmikor route-olhatsz barmilyen tartomanyt barmilyen ip-re. (ahogy az szokas is, hogy kapsz egy provision ip-t es arra route-olnak neked egy - attol tok fuggetlen - tartomanyt)
de:
ip-re route-olas igazabol absztrakcio layer2-n, hiszen vegul MAC cim alapjan talal oda a csomag ahova kell.
ppp eseten pedig nem is kell, interface-re route van, beleokadod ami oda valo.
a legszebb az volt, mikor az eles eszu ex kollega kitalalta, hogy "elhasznalta" a 10.0.0.0/8-at, a kovetkezo tartomany meg a 20.0.0.0/8 lett. logikus! el is kezdte belso halokent hasznalni :) addig jol is mukodott, amig nem kellett az fele a pub /8 fele (vagy onnan) kommunikalni. :)
- A hozzászóláshoz be kell jelentkezni