Fórumok
Két mikrotik router site to site vpn, (voidafine static ip, telekom pppoe)
Egyik irányban minden jó, másik irányba néhány eszköz webGuija nem megy.
ping -l el kiderült,hogy baj van a csomagmérettel. Az egyszerűség kedvéért MTU-t
1300 ra állítottam mindkét routerben, minden működik.
Viszont igy minden csomagra érvényes az 1300.
1. Miért ilyen fapados ez, vagy csak én nem tudok valamit? hogyan szokás ezt beállítani ?
2 hagyjama pi..ába és inkább wireguard ? Vagy az is ilyen ?
Hozzászólások
#define site2site vpn.
Viszont igy minden csomagra érvényes az 1300. > pont ez a lenyeg, a legalacsonyabb MTU az iranyado a bridge-eken.
hidd el, packet fragmentationnel sem jarsz jobban, de van, hogy csak az segit. :)
probalkozhatsz ezzel https://help.mikrotik.com/docs/spaces/ROS/pages/48660587/Mangle#Mangle-…
esetleg a fasttrack off-fal.
Ha megnézed, a két internet kapcsolatod nem azonos MTU-val dolgozik, ez okozhat némi zavart az erőben...
Ezért állitottam mindkettőt 1300 -ra . Az egyik irányba minden működött, a másik iréányb voltak gondok. ping xxxx -l 1300 ,ment , 1400 meg nem , beállitottam erre "oszt jó napot". Tele a net ezel, első hozzászólónak, dorsynak lehet igaza, jobb ha nincs szegmentálás.
https://blog.claryel.hu
1500 nem jó
https://blog.claryel.hu
Mit értesz IPSec site-to-site VPN alatt? Sima, tunnel módú IPSec-et, vagy van még benne valami enkapszuláció (L2TP, GRE, stb...?)
A PPPoE fejléc mérete 8 bájt, az IPv4 fejlécé 20 bájt / az IPv6 fejlécé 40 bájt. A titkosítás (ESP) teljes overheadje függ attól, hogy milyen titkosítást használsz belül. Ha NAT-T vagy Mobile IKE is van, akkor az egész payload még UDP-be is van enkapszulálva. (8 bájt)
Az 1300-as MTU értékkel nem jársz nagyon rossz helyen, de ha nagyon optimalizálni akarsz, akkor az előbb felsoroltak pontos ismeretében akár 1350-1370 környékére is fel tudhatsz mászni, már persze, ha ennek van bármi érdemi jelentőssége.
Teljesen mindegy, hogy milyen VPN technológiát használsz (IPSec, Wireguard, stb.) a matek mindenhol ugyanaz lesz, csak legfeljebb az egyes enkapszulációs rétegek overheadje között lesz pár bájtnyi eltérés.
Épp a minap jártam én is így, és kénytelen voltam MTU-t számolni...
...ami - mint kiderült számomra - nem is olyan egyszerű, a nekem kellő L2TP/IPsec NAT-T esetében, PPPoE internet mellett...
Nekem az jött ki, hogy a max. MTU-m 1389 byte lehet IPv4 VPN kapcsolat esetén.
Ha nem jól számoltam, akkor légyszi javítson ki, aki vágja az ilyen fokú enkapszulációt, fejléc méreteket, satöbbit.
A wireguard overhead-je IPv4 esetén 60 byte, szóval PPPoE internet mellett a max. MTU 1432 byte lehet. Plusz, sokkal egyszerűbb beállítani, és jó teljesítményt ad HW AES gyorsítás nélküli végpontokon is.
Azért fapados ez, mert bár létezik a PMTUD, de aránylag sokszor valami megakadályozza (általában "fájin" tűzfalbeállítások) a működését, így a végpontok nem tudják automatikusan kideríteni a tényleg működő max. MTU-t, ezért jellemzően kézzel kell a VPN-eken MTU-t korlátozni, hogy ez ne okozzon gondot. Legalábbis nekem ez a tapasztalatom.
Köszi.
https://blog.claryel.hu
hat nem kene tiltani az ICMP-t es akkor megbeszelnek egymassal (path mtu discovery)
IKEv2 tud fragmentalni amugy
-mint irtam fent.Vagyis nemhogy tiltva van, igy derüllt ki hogy nagy a csomagméret,
https://blog.claryel.hu
gondolom a ping a vegpontok kozott zajlott nem a routerekre, szoval attol meg a routereken lehet tiltva az icmp hogy atengedi
na meg ping!=icmp, az csak egy a sok kozul...
de ugye az mtu hibat nem a vegpont hanem a szuk keresztmetszetet okozo router fogja generalni (ha hagyjak)
Igen, a ping a végpontok között ment csak , beállítom majd , hogy a routerek is pingelhesék egymást a VPS-en át:
/ip firewall nat add chain=srcnat src-address-type=local dst-address=172.16.3.0/24 action=src-nat to-address=192.168.4.3
illetve a túloldal:
/ip firewall nat add chain=srcnat src-address-type=local dst-address=192.168.4.0/24 action=src-nat to-address=172.16.3.3
majd kpróbálom , ICMP nincs tiltva, sőt ez egy otthoni dolog, ilyenhor tűzfal kikapcs.
https://blog.claryel.hu
Nem MTU-t kell változtatni, hanem MSS clamp-et kell bekapcsolni, vagy - biztos, ami biztos - tűzfalban (mangle chain) is definiálni az érintett IP subnet-ek között mindkét érintett router-en. Ezzel tudod manuálisan korlátozni, hogy ne akarja túllépni a két végpont közötti legkisebb MTU-t.
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"
> hanem MSS clamp-et kell bekapcsolni
az csak TCP-re jo.
Valahol azt olvastam, hogy sok UDP alapú protokoll fel van erre készítve (persze biztos, nem mind) vagy kapásból valami nagyon kis csomagméretet használ, azért nem akkora probléma. Mindenesetre PPPoE-nél is, ha RouterOS alatt kikapcsolom a PPP profilban a Clamp-ot, akkor jó pár hazai weboldal be se jön, míg másokkal semmi gond, UDP-vel meg a RouterOS se bajlódik alapból (mondjuk azon kívül, hogy vagy a PMTU vagy valami felsőbb rétegbeli protokoll közbe nem lép, nem is tudom, létezik-e ezen a szinten bármilyen technika az UDP-re).
De ha jól értem, a clamp-nál is kézzel kell beállítani a csomagméretet ?
https://blog.claryel.hu
igen, de azt meg tudod csinalni dinamikusan IP alapon is, mivel tuzfal szabaly, nem csak fixen.
Ha tűzfal szabályként viszed fel, akkor igen, RouterOS alatt az adott PPP(oE) interfészhez igazítja kapásból a PPP alrendszerbe épített, az ott csak egy kapcsoló érték nélkül.
Nekem ez oly módon állt elő, hogy bizonyos weboldalak, (Fiido.com, orczy.hu) nem jöttek be. Az egyik vonal Vodafone (ezzel nem ment), a másik egy PPPoE VDSL, azzal meg simán ment. Addig küszködtem, míg végül arra jutottam, hogy a Vodafone hálózatában van útközben egy PPPoE kapcsolódási pont és emiatt levettem a WAN interfész MTU-ját 1492-re. Most megy minden oldal.
Nem VPN, de hátha...