Hálózat így néz ki:
UPCModem --- Átjáró(BSD 8.2) -- LAN ---- sok kis gép
Namármost az átjárón van egy natd. A LAN-on belülről néha van úgy, hogy nem tudok kapcsolódni egy géphez. Példa:
gandalf@gandalf-HP-G62-Notebook-PC:~$ telnet c.speedtest.net 80
Trying 93.184.221.133...
és csak vár vár. A traceroute és a ping jól megy. Sőt, ha LAN-on belül egy másik gépről megyek ki, akkor kapcsolódik. Ráadásul ez össze vissza történik meg. Például van amikor amazon.com nem elérhető az egyik gépről miközben a többiről igen. Eltelik 5-10 perc, és jó lesz. Ugyan ebben az időben vannak más site-ok amik elérhetőek minden gépről.
Véletlenszerűnek látszik, hogy melyik gépről melyik hely nem érhető el. ping-elni tudom őket, ezért talán a NATD-vel lehet a gond, de igazából nincs ötletem.
Valaki tapasztalt már ilyet?
- 1713 megtekintés
Hozzászólások
Volt egyszer egy olyan bajom, hogy a streamek behaltak es neha a weboldalak reszlegesen jottek le.
a vicc, hogy nyomozgattam egy ideig es arra jutottam, hogy 1300 -as MTU -val nem tapasztalom :)
Viszont, elvileg es minden bizonyitek szerint a modem seggen 1500 siman atmegy :)
- A hozzászóláshoz be kell jelentkezni
Ez egy ilyen hiperszuper UPC-s gigabit modem. DHCP szerver van rajta, és sima IP protokollal lehet elérni. (Nem PPP) Az admin felületén nem lehet MTU-t állítani.
- A hozzászóláshoz be kell jelentkezni
Most épp egy IMAP szerverhez nem tudok kapcsolódni az egyik gépről, több mint fél órája. Másik gépről működik.
Bármilyen más ötlet, valaki?
- A hozzászóláshoz be kell jelentkezni
torrent vagy egyéb miatt elfogynak a portok az átjárón?
- A hozzászóláshoz be kell jelentkezni
Nem telt be egész véletlenül a tcp session tábla? Kísértetiesen ugyanez a hibajelenség, ha igen.
- A hozzászóláshoz be kell jelentkezni
+1 - kern.ipc.somaxconn=8192
másrészt, még régebben volt ilyen problémám, akkor a dummynet nevü modul okozott hasonló problémát (valamilyen bug volt), ha van rá lehetőséged, szedd ki
- A hozzászóláshoz be kell jelentkezni
Wow!
gw# sysctl kern.ipc.somaxconn
kern.ipc.somaxconn: 128
gw# sysctl kern.ipc.somaxconn=8192
kern.ipc.somaxconn: 128 -> 8192
Hát nem csodálkozom hogy nem mentek a dolgok. :-D Most meglássuk mi lesz.
A dummynet nem kiszedhető, szükség van rá sajnos. (Vannak pipe-ok plusz bandwidth limiter-nek)
- A hozzászóláshoz be kell jelentkezni
próbáld meg legalább kikapcsolni egy teszt erejéig, nálam szörnyen bugos volt akárhányszor használtam (3.2 alatt próbáltam elsőnek, azóta néha néha rálestem, de vagy csak bugosabb lett, vagy olyan hibát generált amiért debugolhattam volna évekig, ha nem tudom hogy megbízhatatlan).
Ha az lesz a probléma, van más megoldás a bw limit eléréséhez.
- A hozzászóláshoz be kell jelentkezni
Sajnos somaxconn növelése után is jelentkezik a probléma. Az MTU-t átállítottam 1300-ra de még így is. Egyéb ötletek?
- A hozzászóláshoz be kell jelentkezni
Megvan a hiba! Az ipfw így kezdődött:
pipe 1 config bw 25Mbit # DL
pipe 2 config bw 5Mbit # UL
add 00010 pipe 1 tcp from any to me 49160-50160 # DL
add 00015 pipe 2 tcp from me 49160-50160 to any # UL
add 00100 divert natd all from any to any via re0
Namost ezzel az a baj, hogy ha egy gép véletlenül az adott port tartományból oszt ki portot, akkor az bekerül a pipe-ba. És nem lesz NAT-olva, mivel a pipe tcp hamarabb van mint a nat. Én vagyok a hülye, mert világosan leírták hogy a divert kellene hogy legyen az első szabály...
Megcsinálhatom azt, hogy a divert kerül az elejére, és csak utána jön a pipe. Így nem lesznek kapcsolódási gondok. De ez így limitálná azoknak a kapcsolatoknak a sebességét is, ami igazából egy belső gépre irányulnak (nat-on keresztül). Valahogy így:
add 00010 divert natd all from any to any via re0
add 00011 pipe 1 tcp from any to me dst-port 49160-50160
add 00012 pipe 2 tcp from me src-port 49160-50160 to any
A 00011/00012 szabály már a nat-olt csomagra fog lefutni, és ott a forrás/cél cím közül az egyik mindenképp "me" lesz, ezért lesznek olyan kapcsolatok ahol a nat-olt csomagok is bekerülnek a pipe-ba, amit én NEM akarok.
Az a cél, hogy a nat-olt keresztül utazó csomagok ne kerüljenek bele a pipe-ba, és ne legyen korlátozva a sebességük. De a nem nat-olt csomagok (a portszámtól függően kerüljenek bele) a pipe-ba, és lehessen korlátozni a sebességüket.
A natd manual-t néztem, de nem jutottam előrébb. :-(
- A hozzászóláshoz be kell jelentkezni
én meg olvashattam volna tovább:D
Azért van problémád, mert alap konfigurációt használsz a nat-ra.
Határozd meg, hogy a divert kikre szól (all from netmask) vagy (all via belsőhálókártya).
Ha szépen szegmentálod hogy ki/mit/hova, nem lesz problémád a bw limit megfelelő helyre passzintásával
(pipe 1 tcp from via külsőhálókártya to publikusipcim), ugyanez fordítva.
A me túl általános, te meg csak egy felől szeretnél egy fele használni bw limitet.
- A hozzászóláshoz be kell jelentkezni
Újra elővettem a témát. A natd az jó lesz, a külső re0 a belső re1.
szerintem ez jó lenne:
add 00100 divert natd all from any via re1 to any via re0
Viszont a pipe még mindig nem megy. Ezt írod:
"pipe 1 tcp from via külsőhálókártya to publikusipcim"
Tehát ez lenne:
pipe 1 tcp from via re0 to
Az a gond hogy nekem nincs fix publikus ip címem. Olyat meg nem tudok megadni hogy "arra ami nem belső cím". Vagy igen? A manual szerint az "src" és "dst" a következő lehet:
ip | all
any
me
me6
table(number,[value])
de nekem egyik sem jó. A "me" azért nem jó mert az alatt a belső címeket is érti. Egy fix publikus külső címet meg nem tudok beírni, mert olyan nincs.
- A hozzászóláshoz be kell jelentkezni