Mikrotik-ek közötti IPsec tunnel-en megy a telephelyek közti privát forgalom, mellette ugyanazon a vonalon "simán" az internet felé irányuló "publikus" forgalom.
QoS Queue tree-t próbálok húzni az interface-re, korrektül jelölöm a csomagokat (mangle prerouting), de úgy tűnik, az IPsec forgalomra ez nem hat - pedig ott lenne a fontosabb.
Gondolom, az IPsec tunnel-be kódolás után elveszik a packet mark, így a queue már nem tudja beazonosítani a csomagot.
Maga az IPsec tunnel pedig nem jelölhető ki queue parent-ként, hogy esetleg még a tunnel-be kódolás előtt sorbaállíthassam a csomagokat (bár, ez is csak részmegoldás lenne, mert a kódolt és kódolatlan forgalmat összességében kellene priorizálnom a vonalon)
So, what can I do?
- 1322 megtekintés
Hozzászólások
Az IPsec nagyon jó eséllyel fix IPcímek között közlekedik, ez és protocol match alapján mark-olnám meg a csomagokat (meg természetesen az egyéb forgalmat).
Ez a diagram segítségedre lesz.
- A hozzászóláshoz be kell jelentkezni
Mire gondolsz pontosan? Az IPsec tunnel fix IP-k között van felhúzva, de a tunnel-en belül teljes tartományok (site2site VPN) kommunikálnak.
A baj - a 2. diagram szerint - hogy akár prerouting-nál, akár postrouting-nál mark-olom a csomagot, ha "IPsec policy = no", akkor bekerül az Interface HTB-be és szépen működik a queue, de ha "IPsec policy = yes", akkor a csomag a mark-al együtt kódolódik és már egy eredeti mark-tól független, IPsec csomag kerül vissza az Output queue-ba.
Az IPsec encription előtt viszont nincs HTB, ami a még kódolatlan csomagokat rendezné a tunnel-be kerülés előtt.
----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"
- A hozzászóláshoz be kell jelentkezni
OpenVPN-en ilyenre volna a PassTOS, de itt még bizony a csatornába kerülés előtt kellene a forgalmat jelölgetni és priorizálni.
Szerintem úgy kéne tekinteni erre az IPSec VPN csatornára, mint független hálózati kapcsolatra, külön csatolóra, legalább is a WAN vonaltól különállóra, az más kérdés, hogy ugyanúgy megterhelik a WAN vonalat mint a VPN csatornát, csak VPN-be futó csomagokat tudod szabályozni, a WAN-on már csak a VPN csatorna összprioritását tudod állítgatni. De javítsatok ki, én is kezdő vagyok QoS téren.
- A hozzászóláshoz be kell jelentkezni
Amennyiben a cél az, hogy az IPSec csomagok prioritást élvezzenek a többi csomaggal szemben, akkor packet mark-olnám az IPSec peer felé és tőle jövő csomagokat,
valamint az egyebet és ez alapján állítanám be a prioritást. (IPsec csomagnak 1-es, többinek 8as).
Ezáltal minden WAN interfészt elhagyó csomagnál az IPSec peer felé menő csomagnak elsőbbsége lesz - illetve "házon belül" előbb lesz kézbesítve.
Az, hogy az IPSec tunnelBEN közlekedő csomagoknak mi lesz a prioritása, már más kérdés. Ott szerintem DSCP Mark vagy TOS használható - ha ezt nem strip-eli le valami.
- A hozzászóláshoz be kell jelentkezni
Ez IS cél, de ez már megvan, ez viszonylag "triviális" és működik is.
A probléma az IPsec-BEN futó forgalom priorizálásával van - éppen az, amit egyel feljebb bennyh is említ, hogy míg pl. egy OpenVPN tun interface-én lehetne priorizálni, addig egy IPsec tunnel nem jelenik meg interface-ként, így az abban futó forgalomra nem lehet queue-t illeszteni.
Mark-olni lehet a majd bele kerülő csomagokat, csak nem érek vele semmit :(
Na, ez utóbbira keresném továbbra is a megoldást.
A., Hogy illeszthetnék mégis queue-tree-t az IPsec tunnel-re, mint interface-re?
B., Hogy "örökölhetné" a kódolt IPsec csomag a kódolatlan csomagok packet mark-ját, hogy kódoltan is a WAN interface megfelelő queue-jába kerüljön? (ne csak egy összesített IPsec queue-ba)
Szerk: Kössz a DSCP ötletet! Ez működik. Az eredeti csomagot DSCP mark-ját, az IPsec kódolt csomag megtartja, így ipsec-esp + DSCP mark-ra vizsgálva megfelelően tudom mark-olni a már kódolt csomagot. Már csak az a kérdés, utána vajon visszaállítsam-e 0-ra a DSCP-t, ki tudja, mit kezd vele a szolgáltató?
----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"
- A hozzászóláshoz be kell jelentkezni
Igen, az, hogy mit kezd vele a szolgáltató - azt szolgáltatója válogatja :-)
Mikrotik esetén - újabb verzióknál - a titkosított EoIP az IPSec-ben fut.
Azaz ha az IPSec-et csak annyira használod, hogy az EoIP interfészt erre bind-eled, akkor máris megoldottál mindent, mivel lesz interfészed amire hivatkozhatsz. (meg "nyertél" némi extra overhead-et is - ellenben az IPSec biztosan nem visz át 1500byte-os MTU-t az EoIP-vel meg megoldható ez a dolog, így némi sebesség vesztés árán az applikációid is boldogabbak lehetnek)
- A hozzászóláshoz be kell jelentkezni
Igen, ezzel az MTU dologgal már szívtam egy kört, MSS csökkentés lett a vége. De most már (egyelőre) nem szeretném megint átvariálni a gerinchálózat felépítését, úgyhogy egyelőre marad a DSCP mark-os megoldás
----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"
- A hozzászóláshoz be kell jelentkezni