Helló!
Ma frissítettem a fenti Openwrt verzióra, viszont rányomtam, hogy tartsuk meg a beállításokat és úgy tűnik, hogy az opkg régi config fileját is megtartotta, így viszont nem tudok új csomagokat telepíteni. Kérem, adjon valaki egy /etc/opkg.conf -t!
Köszönöm! :)
Sziasztok!
Adott egy Bullet 2HP eszköz, amely eddig egy másik egyszerű TP-LINK router wireless jelét továbbította. Ezt valamikor rég - nem tudni ki - beállították és nagyszerűen működött, míg egy lakó (egy motel-ben volt felszerelve) gondolt egyet és adott neki egy reset-et, mert nem volt internet.
Én azóta ezt az eszközt nem tudom rábírni, hogy a TP-LINK wifi jelét szórja tovább. Amit eddig sikerült elérnem vele:
- Ha a Wireless Mode-t Station-re állítom, akkor feltudok csatlakozni a másik router-re, és LAN el is érem az internetet, viszont nem tudok megadni másik SSID-t, hogy azt szórja is tovább.
- Station WDS-nél hasonló a történet
- Ha Access Point vagy Access Point WDS-re állítom, akkor működik a wireless (tudok titkosítani és SSID-t adni), de akkor nem tudom megadni neki, hogy arról az egyszerű TP-Link router-ről vegye a jelet, mert LAN-on szeretne internetet kapni
Legfrissebb firmware van rajta.
Egyszerűen nem bírok rájönni.
Segítségeteket előre is nagyon köszönöm.
u.i.: ne tessék bántani, most találkoztam először Ubiquiti eszközzel :(
Előre jelzem, hogy hülye vagyok a hálózatokhoz :)
Van egy gép, amiben 2 hálókártya van, 2 publikus fix ip-vel 2 különböző tartományból.
Az eth0 az rendben működik.
A eth1-el viszont nem boldogultam, kívülről nem lehetett pingelni.
Miután ez alapján beállítottam, már pingelni tudtam bárhonnan:
http://www.thomas-krenn.com/en/wiki/Two_Default_Gateways_on_One_System
ip route add xxx.xxx.xxx.0/24 dev eth1 src xxx.xxx.xxx.xxx table rt2
ip route add default via xxx.xxx.xxx.1 dev eth1 table rt2
ip rule add from xxx.xxx.xxx.xxx/32 table rt2
ip rule add to xxx.xxx.xxx.xxx/32 table rt2
Viszont kifelé kommunikálni csak a xxx.xxx.xxx.0/24 hálózat felé tudok az eth1-ről.
ping -I eth1 xxx.xxx.xxx.15 működik, ping -I eth1 8.8.8.8 nem.
Az kellene, hogy az eth1-ről bárhova tudjak csomagot küldeni (és bárhonnan fogadni).
(A fix ip-k mögött nat-olt VPS-ek vannak, amit kívülről a fix IP-vel lehet elérni, iptables irányítja a kéréseket a megfelelő VPS-nek.)
Ha valami zavaros, akkor elnézést, napok óta már alig aludtam.
Sikerült már valakinek stabil VPN kapcsolatot létesítenie egy Juniper tűzfal és linux illetve windows kliens között?
A legújabb 2.2.2 -es shrew kliens lett letöltve, és mind linux, mind windows alatt elég hamar (általában 1 perc) megszakad a kapcsolat.
Olvasgattam a google-ben, nagyon sokan járnak hasonló cipőben.
A másik gondom pedig a megosztás lenne, amennyiben sikerülne végre stabil kapcsolatot összehozni, a linuxon keresztül szeretném megosztani ezt a VPN kapcsolatot, vagyis a mögötte levő gépeket szeretném a hálózatban levő kliensgépekről elérni. PPTP, VPNC, OPENVPN csatlakozásokat sikerült eddig megosztani iptables segítségével, de ez a VPN valahogy nem jön össze (ESP + AH protokol stb), van esetleg erre valakinek működő megoldása?
Udvozletem!
Valakinek nincs esetleg elrakva egy OpenWrt White Russian rc6 flash image-e brcm47xx platformra? Sajnos egy eszkozom kizarolag ezzel szeretne menni es sehol se talalok mar ilyen verzioju image-et.
Adott egy Debian alapú router (már megint :) ), OpenVPN-nel. Ha egy Vista-t futtató klienset rakok (win7 ok-nak tűnik) a "LAN" (nak kinevezett) portra akár switchen keresztül akkor megbénítja a LAN oldali forgalmat, ha windows-os megosztásról másolok nagy állományokat (mely megosztás VPN túloldalán van). Addig eljutottam, hogy ha lelövöm a tcp window sizing-ot csak a vistán, akkor minden rendbejön , próbáltam a két átjárón is kikapcsolni, de semmi hatása. A vistás klienset, közvetlenül arra a hálózatra kötve, ahol a megosztás van, nincs komolyabb gond.
Na most akár iptablesben akár ip route-ban akár máshogy valahogy, hogy lehetne megoldani az átjárón vagy átjárókon, hogy ha egy ilyen kliens kerül a LAN-ra, ne bénítson meg mindenkit, amíg ki nem kapcsoljuk a tcp window sizing-ot (netsh int tcp set global autotuninglevel=disabled). Tehát nem a kliens gépen, hanem magán az átjárón?
Azt írták sok helyen, hogy a régi routerekkel tűzfalakkal lehet gond, de csak simán engedem a forwardot a LAN és a VPN között és NAT sincs köztük.
Frissülés:
Egy blogon találtam az alábbi kódot (amit mindkét átjárón beállítottam), és tényleg, clamp-mss... opcióval nekem se jó, viszont a 294-es mss értékkel (ha jól értelmezem byte lenne) müxik. Igaz valamivel lassabb lett a másolás, de a kliens buzergálása nélkül se szállnak el a pingek a végtelenbe másolás közben, hanem 5 ms alatt maradnak. Viszont fogalmam sincs, honnan szedte a srác pont a 294-et. Eddig még a dupláját próbáltam, de az se volt jó.
"# MTU in tunnel (only for Windows machines... strange)
iptables -D FORWARD -p tcp --tcp-flags SYN,RST SYN --jump TCPMSS --clamp-mss-to-pmtu
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN --jump TCPMSS --clamp-mss-to-pmtu
(update : I use now "--set-mss 294" option after some problems with "--clamp-mss-to-pmtu")"
Sziasztok!
Lehet valamit csinálni, ha az eth0 nem érzékeli, ha kábelt dugok bele? Amikor boot-ol a gép, felvillanak a led-ek a csatlakozón, mindkettőn: egyik a link, másik az adatkommunikáció. De csak, mint init.
Az eth1 jó.
Típus: Intel Corporation 80003ES2LAN Gigabit Ethernet Controller (Copper).
BIOS-ban engedélyezve van mindkettő.
Próbáltam több kábellel, de semmi.
Az eth1 mindennel jó volt.
Van értelme letiltani a BIOS-ban az eth0-at, ha már nincs használva? Bármi előnye lenne?
Jól sejtem, hogy nem sok megoldás van erre a hardver hibának tűnő helyzetre?
Sziasztok,
Egy olyan fizikai eszközt keresek aminek az egyik végét a user bedugja a local LAN-ba, a másik felét rádugja a monitor/USB helyére, és innentől kezdve távolról tudom irányítani a gépet, látom a képernyőt, és BOOT USB-t is fel tudok csatolni.
Minderre azért van szükség, mert egy nagyontávoli telephelyre nem mennék ki azért, ha egy gép elakad bootolás közben.
Gyarkolatilag ILO szerű funkcionalitást várok el tőle, és fontos hogy elegendő ha csak 1 kliens csatlakozik hozzá... A szokásos robosztus KVM switch-ek-nél valami filigránabb megoldás kellene, amit a user megkap a recepción, rádugja a gépére - én meg tolom távolról.
Jó lenne ha nem lenne bazidrága, de a megbízhatóság a legfontosabb szempont. A távoli média felcsatolása Must Have.
Thx!
Curt
Van egy régi Debian alapú átjáró/tűzfal, amire csatlakoznak kliensek és egy másik telephely, általában OpenVPN 2.0.x-en. Készítenék egy új átjárót a telephelyre, amit vezeték nélküli kapcsolaton érnénk el, és olyan 100 MBitet bír a vonal, később az eszközök cseréjével talán többet is.
Lényeg:
Közvetlenül egy vagy két switchen keresztül összekötve a két átjárót, ha másolok egy kb 5 megánál nagyobb állományt egy NAS-ról a VPN-en át a másik átjáróra kötött laptopra, minden más forgalom meghal, RDP kifagy, icmp echo-k elvesznek és a másolás is meg megakad és újraindul.
Azt vettem még észre, hogy ilyenkor a régi átjárón a többi kapcsolat is szakadozik (VPN internet, minden ami az adott hálókártyától függ)
Ha az új szerveren csökkentem a hálókártya sebességét 100-ról 10 mbit-re, vagy csak 100 mbit full duplexre állítom a hálókártyát, akkor stabilizálódik a helyzet, a másolás egyenletes lesz, rdp nem szakad, icmp kiesése ritkul.
Próbáltam még fragment méretet állítani, fast-io-t ki-be kapcsolni, titkosítást és tömörítést kikapcsolni próbaképp. Csak a hálókártya visszafogása segített. Realtek alapú gigabites PCI-Express kártya, TP-link ugyan de a firmware és a meghajtó úgy is a kernel része, úgyhogy elvileg mindegy. Próbáltam a legutolsó stabil Debiannal és 14.04-es Ubuntuval, ugyanaz a helyzet.
Mi lehet a megoldás, valaki látott-e ilyet? Hogy lehetne csak az OpenVPN-t visszafogni, a hálókártyát meg nem? Vagy lehet nem is ez az oldal a rosz hanem a régi központi átjáró és annak öregecske hálókártyája? Ha azt fogom vissza, az kevésbé hatásos.
Közben meglett a ludas egy Draytek router beépített switchének képében.
Viszont előjött egy új gond.
Vista esetén csak akkor működik jól a hálózat, ha kikapcsolom a tcp window scaling-ot a Vista-s gépen.
Mit kellene a Debian alapú átjárón, amin a VPN is fut állítani, hogy akkor is jól működjön, ha nincs kikapcsolva a tcp window scaling?
Hiba: szakad mindenféle egyéb kapcsolat, netrádió, ping, ha a VPN-en túlról másolok nagy állományokat SMB protokollal. Annyival jobb a helyzet, mint az előző hibánál, hogy a VPN kapcsolat stabil, a késleltetések alacsonyak a két átjáró között.
Így néz ki valahogy az adatút:
NAS---GW1----(VPN TUN, UDP)-----GW2---Vistás laptop
Ha jól olvastam, a TCP window scaling akkor müxik rosszul, ha valamelyik átjáró rosszul ír át adatokat a tcp csomagok továbbításánál. Itt ugye két Debian alapú átjáró jöhet szóba. Mindkettőn be van kapcsolva a tcp window scaling, ha jól láttam a proc könyvtár mélyén. az iptables szabályok meg nincsennek agyon bonyolítva, szimpla forward. A VPN konfig pedig tartalmazza a "fragment 1300" és "mssfix" sorokat.
Sziasztok!
Van egy webszerver aminek le kéne mérnem a külföldi sávszélét, van erre valami lehetőség? google most ne ma barátom, magamtól meg azt sem tudom, hogy fogjak hozzá :(
előre is köszönök minden segítséget.
A rendszer egy gui nélküli 7.6-os debian.