A valami ipsec implementációval összekötött 3 telephelyes vpn-ünkről az egyik távoli telephely állandóan leszakadozik.
Mivel a dolog azóta fordul elő, amióta a központi telephelyre egy FreeBSD-s squid proxy-t telepítettem (előtte tiszta windows hálózat volt), a proxy-t gyanúsítják. Most éppen visszavették a webes sávszélt 100kbit/s-ra a 4Mbit/s-s vonalon. :-(
Szerintem ez nonszensz, mert a webes nagyon rövid ideig tartó "csúcsterhelésünk" a korlát nélkül is csak a rendelkezésre álló internetes sávszél kb. 30%-a volt, azaz a vpn-nek szerintem mindig maradt elég sávszél. A proxy internet felé nyitott tcp/udp kapcsolatainak darabszáma meg csúcsidőben 70 körül tetőzött.
Van valami ötletetek, hogy akkor mégis miért szakadozhat a kapcsolat az egyik távoli telephellyel? Mit ellenőrizzünk?
Saját kútfőből elkezdtem a távoli telephelyeket pingelgetni a FreeBSD-ről (ami a központi telephely hálózatán belül van, tehát nem gateway), és azt vettem észre, hogy az egyik telephelyről már az 1300 byte-os ICMP csomag sem jön vissza (valami rádiós kapcsolat) és a 64 byte-os ping time-ja rendkívül ingadozó; a másik telephelyről meg még a 4500 byte-os ICMP csomag is visszajön, és a ping time-ja elég stabil. Különös, de éppen ez az utóbbi telephely szakadozik le. (Ahonnan egyébként nincs route a másik telephelyre.) Lehet ebből bármi következtetést levonni, vagy nincs köze a problémához?
Hozzászólások
OK. Közben megtudtam, hogy 12 ipsec link van 12 telephelyre, és mind szakadozik...
Plusz olvasgattam még egy keveset a témában, és méginkább az a meggyőződésem, hogy nem a BSD/squid proxy okozza a telephelyek leszakadását, hanem valami MTU probléma.
Meg tudnátok erősíteni ezeket a feltevéseimet:
A) Nem szabadna olyan távoli telephelynek (vpn alhálózatnak) lennie, ahonnan az 1300 byte-os ping-re (amin a NOFRAG nincs beállítva) nem jön semmilyen válasz az idők végezetéig
B) Olyan telephelynek sem szabadna lennie, ahonnan a 4600 byte-os pingre nem jön válasz (márpedig mind ilyen), mert darabolással még ekkora csomagnak is át kellene jutnia a vpn linken oda-vissza
C) Ha az A)-ban és a B)-ben leírt problémát tapasztaltam, akkor az lehet az oka a telephelyek random leszakadásának.
Továbbá: azt veszem észre, hogy az internetet ( www.google.com-ot) innen a központból bármilyen >64 byte-os ICMP csomaggal pingelve csak 64 byte érkezik vissza. Mi lehet ennek az oka? A céges tűzfal? Arról hallottam már, hogy egy tűzfal a frag csomagokat eldobja, de miért éppen 64 byte-osak a darabok, akármekkora ICMP csomaggal is pingelek?
Ha a tűzfal beállítása a ludas ebben; okozhat ez a rendeltetésszerű üzemben valamilyen prolémát? Ha igen, akkor konkrétan milyet? (Ezen a tűzfalon keresztül csatlakoznak be a telephelyek vpn linkjei is)
Mindenesetre gyanús, hogy a nagy méretű csomaggal pingelés csak azokhoz a telephelyekhez működik rendesen, amelyek bérelt vonallal vannak bekötve; ellenben az internet felé, meg a vpn-en csatlakozó telephelyek felé nem muxik a - szerintem - elvárható módon...
Szerkesztés:
Most ugrik be, hogy azt olvastam valahol, hogy az ipsec 64 byte-os darabokra bontja a forgalmát. Nem lehet, hogy egy elbaltázott route miatt a központ internetes forgalma a LAN helyett áthalad egy ipsec linken is? Dehát, még ha így is lenne, 64 byte-os csomagokban akkor is át kellene jutnia a teljes ICMP csomagnak - gondolom; nem csak az első 64 byte-jának; vagyis ez nem magyarázná meg, hogy miért jön vissza mindig csak 64 byte a google pingelésekor...
---
Mondjon le!