Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
eko.one.pl → Posty przez alossek
Jak sobie skompilujesz filrmware z włączonym REGDOMAIN to włączysz obsługę tych kanałów. Moje to mają.
Aaaa, czyli w oryginalnym nie działa.
No nic, tylko brać Twoje obrazy i po kłopocie.
Dzięki.
--
Pozdrawiam!
Witam!
Czy możliwa jest obsługa kanałów 12 i 13 w trybie AP ?
Nigdzie wprost tego nie wyczytałem, ALE gdy próbuję u siebie to włączyć,
pojawia mi się komunikat że to nie możliwe.
udhcpc (v1.15.3) started
Sending discover...
Configuration file: /var/run/hostapd-phy0.conf
channel [12] (13) is disabled for use in AP mode, flags: 0x1Kraj ustawiłem jak trzeba, według:
http://eko.one.pl/?p=openwrt-konfigurac … sugiikanau
iw phy0 info | grep MHz
* 2412 MHz [1] (20.0 dBm)
* 2417 MHz [2] (20.0 dBm)
* 2422 MHz [3] (20.0 dBm)
* 2427 MHz [4] (20.0 dBm)
* 2432 MHz [5] (20.0 dBm)
* 2437 MHz [6] (20.0 dBm)
* 2442 MHz [7] (20.0 dBm)
* 2447 MHz [8] (20.0 dBm)
* 2452 MHz [9] (20.0 dBm)
* 2457 MHz [10] (20.0 dBm)
* 2462 MHz [11] (20.0 dBm)
* 2467 MHz [12] (disabled)
* 2472 MHz [13] (disabled)
* 2484 MHz [14] (disabled)A mimo to kanały 12 i 13 mam zablokowane.
Czy kanały są zablokowane z powodu tego że router działa w trybie AP ?
Z drugiej strony szukałem czytam jakieś tickety i wygląda to na błąd
https://dev.openwrt.org/ticket/10496,
https://dev.openwrt.org/ticket/9678
(rzecz się dzieje na oryginalny Backfire 10.03.1)
---
Pozdrawiam!
No to teraz ja odgrzewam :-)
Zrobiłem według przepisu, wszystko niby działa z jednym ALE ...
Na wykresie nie ma moje sieci
(w trakcie skanu nie ma żadnych klientów na moim WIFI)
coś jest nie tak, czy to normalne ?
(skrypt od Cezarego niemodyfikowany uruchomiony
na oryginalny Backfire 10.03.1, tp-link 1043nd)
Ramka w ethernecie ma wielkość 1500bajów. Dane są transmitowane w ramkach, więc jak przewalasz powiedzmy film 700MB to sobie policz ile ramek musi przejść. Po między wysłaniem ramek jest pewien odstęp czasu. Zwiększenie wielkości ramki powoduje zmniejszenie sumaryczne ich ilości potrzebnej do przesłania danych, więc i ilość tych odstępów pomiędzy nimi jest mniejsza. Sumarycznie więc potrzebna mniej czasu na przesłanie tych danych, więc wzrasta przepustowość sieci. Tak ogólnie powiedzmy. Ale to co występuje w tych switchach to tylko na przysłanie danych jest, nie wpłynie to na transfer danych z /do routera.
Że tak spytam po lamersku,
a może użyć tego do WIFI (np. do 802.11n) lub do 100 Mbps, czy to tylko do 1GBit ?
Rozumiem że końcówki (nawet te 1Gbit) muszą mieć mechanizm wspierać te większe ramki ?
--
Pozdrawiam!
Jak podważysz, cofnij lekko do tyłu tą czarną ramkę, wówczas z przodu, tam gdzie LEDy wolna przestrzeń. Jak tam zajrzysz będzie widać zatrzaski - podważ je śrubokrętem i powinno pójść.
--
Pozdrawiam!
Kto rozsądny po lanie robi tak nieefektywny tunel jak openvpn ? To narzędzie dla dostępu zdalnego do dokumentów, programów, itd. generalnie do pracy zdalnej. Choć można i do innych celów użyć.
To ja może podepnę się pod temat i przy okazji zapytam, jak w takim razie zrobić stworzyć efektywny tunel na openwrt ?
Właśnie przymierzam się do połączenia dwóch sieci według Twojego artykułu. Jednak będę korzystać głównie z trzech usług ssh, samba i streaming wideo - konkretnie pomiędzy sieciami ma latać http stream z wykorzystaniem udpxy (i tu własnie potrzebuje wydajności i efektywności).
--
Pozdrawiam!
Jak metryka jest taka sama, to nie wybiera losowo tylko sprawdza i jeżeli dana sieć jest podłączona do routera to ona będzie miała pierwszeństwo w wyborze albo ta sieć która ma mniejszą maskę czyli jest bardziej dopasowana - przynajmniej tak jest w Cisco o ile dobrze pamiętam. Być może w tym przypadku też działa taki mechanizm, że sieć bezpośrednio na interface ma większy priorytet niż wpis statyczny aczkolwiek to bez sensu, bo wtedy cała idea metryki (metric) poszłaby się ... znaczy do lasu
Być może jest to też jakiś bug po prostu, kto wie
Słaby jestem w te sprawy i nie wiem jak to powinno działać, ale ...
Czy nie powinno być tak że gdy mam dwa VLANy i dwa dhcp i dostaję dwie bramy
to powinny być dwie bramy ?
Backfire 10.03.1 usuwa poprzenie bramy (nie wiem czy to bug ?)
przyjrzałem się plikowi /usr/share/udhcpc/default.script
[ -n "$router" ] && [ "$router" != "0.0.0.0" ] && [ "$router" != "255.255.255.255" ] && [ "$router" != "$old_router" ] && {
echo "udhcpc: setting default routers: $router"
local valid_gw=""
for i in $router ; do
route add default gw $i ${user_metric:+metric $user_metric} dev $interface
valid_gw="${valid_gw:+$valid_gw|}$i"
done
route -n # to ja dopisałem
eval $(route -n | awk '
/^0.0.0.0\W{9}('$valid_gw')\W/ {next}
/^0.0.0.0/ {print "route del -net "$1" gw "$2";"}
')
route -n # to ja dopisałem
change_state network "$ifc" gateway "$router"
}Jak widać jest tam "route del"
Dodałem sobie "route -n" przed tym eval
i widzę że wpierw wchodzi mi 'wan' mam domyślny gateway do wan (czyli ok),
potem wchodzi wan_350 mam dwa domyślne gateway do wan i do wan_350 (czyli chyba ok ?)
potem jest eval (robi route del)
i potem mam już tylko domyślny gateway do wan_350
Widać z tego ewidentnie że dąży do tego by mieć jedną bramę (i to tą ostatnią)
Możesz spróbować jeszcze inaczej, jeżeli dostajesz adresy z klasy raz 172.20 .x.x a raz 172.30.x.x to dopisz w interfejsie wan_350 bramę 0.0.0.0 żeby jej nie pobierało i zrób route na proxy tak jak miałeś na początku z bramą wpisaną 172.20.x.1 i drugi taki sam ale z bramą 172.30.x.1, zadziała i tak tylko ta właściwa a domyślną dostaniesz jedną z wana eth0.2, tylko upewnij się co do maski, w route powinieneś mieć wpis 212.x.x.x 172.20.x.1 255.255.255.255 U 0 0 0 eth0.350 lub z bramą 172.30.x.1
Teraz to już walka dla walki, bo tak naprawdę,
to rozwiązanie (http://eko.one.pl/forum/viewtopic.php?pid=52138#p52138)
działa (i z proxy i z resztą)
Jedynie ustawianie tego 'metric' wszytko psuje (nie wiem czemu)
i mam albo dwie bramy (172.20.x.1 i 212.a.b.1)
lub jedną 212.a.b.1 (i w logu błąd - "route: SIOCADDRT: File exists" z powodu zdublowania/dodania statycznej trasy)
W tej chwili działa net, działa proxy.
Niepokojące są :
- dwie bramy (ale jak pisałeś to nie problem)
- dwie lub jedna domyślna brama (i dublowanie się tras gdy wejdzie wcześniej ta z eth0.2)
- ustawienie metric' gdy są dwie bramy domyślnie - wszystko psuje
Teraz już tylko zastanawiam się czy gdzieś leży problem z tym metric,
bo jak rozumiem gdy są dwie domyślne bramy pakiet próbuje przebić się przez jedną i/lub drugą
(nie wiem jak to działa bez metric)
a gdyby miał metric wiedziałby gdzie iść wpierw (dobrze gdybam ?)
--
Pozdrawiam!
Jesteś pewien że maska w route do proxy nie musi być wpisana? Nie widać tego w tablicy rutingu.
W tym wypadku miałem zakomentowaną trasę do proxy aby nie zamącać problemu,
bo chciałem się skupić na problemie z bramami (bo te końcówki bez proxy przestały działać przez ten problem).
Maska do route chyba nie mus być wpisana
cyt. (http://wiki.openwrt.org/doc/uci/network)
"Route netmask. If omitted, 255.255.255.255 is assumed which makes target a host address"
Co rozumiem że "Jeśli pominięto, to wówczas jest 255.255.255.255 jest co sprawia, że kierowanie na adres hosta"
czyli tak jak podałeś "255.255.255.255".
Jak miałeś tak:
route -n 192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 br-lan 212.x.x.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0.2 172.20.x.0 0.0.0.0 255.255.254.0 U 0 0 0 eth0.350 172.20.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0.350 224.0.0.0 0.0.0.0 240.0.0.0 U 0 0 0 eth0.350 0.0.0.0 172.20.x.1 0.0.0.0 UG 0 0 0 eth0.350 0.0.0.0 212.x.x.1 0.0.0.0 UG 1 0 0 eth0.2to wszystko działało?
Nie, nie działo.
W tym przyadku własnie było ustawione metric=1 dla eth0.2 (dla definicji 'interface' a nie dla 'route')
Może tak być że będą 2 bramy, tylko możesz jeszcze dodać metric 1 na samym eth0.2.
Kurde nic z tego nie rozumiem.
Wcale nie działa z tym 'metric'.
Zrobiłem tak:
config 'interface' 'wan'
option 'ifname' 'eth0.2'
option 'proto' 'dhcp'
option 'metric' '1'po restarcie miałem
route -n
192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 br-lan
212.x.x.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0.2
172.20.x.0 0.0.0.0 255.255.254.0 U 0 0 0 eth0.350
172.20.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0.350
224.0.0.0 0.0.0.0 240.0.0.0 U 0 0 0 eth0.350
0.0.0.0 172.20.x.1 0.0.0.0 UG 0 0 0 eth0.350
0.0.0.0 212.x.x.1 0.0.0.0 UG 1 0 0 eth0.2lub (zdublowana brama od wan - z powodu wpisania na pałę domyślnej bramy przez wan)
route -n
192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 br-lan
212.x.x.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0.2
172.20.x.0 0.0.0.0 255.255.254.0 U 0 0 0 eth0.350
172.20.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0.350
224.0.0.0 0.0.0.0 240.0.0.0 U 0 0 0 eth0.350
0.0.0.0 212.x.x.1 0.0.0.0 UG 0 0 0 eth0.2
0.0.0.0 212.x.x.1 0.0.0.0 UG 1 0 0 eth0.2W obu przypadkach brak netu
No to zrobiłem tak
config 'interface' 'wan'
option 'ifname' 'eth0.2'
option 'proto' 'dhcp'
option 'metric' '2'
config 'route'
option 'interface' 'wan'
option 'target' '0.0.0.0'
option 'netmask' '0.0.0.0'
option 'metric' '1'Efekt taki sam.
Nic z tego nie kumam, własnie w tym przypadku zdaje się że 'metric' powinno działać
gdy są dwie bramy aby mógł zdecydować która ważniejsza a tu dupa.
Jakieś pomysły ?
Spróbuj się pobawić z parametrem metric na obu wanach im wyższy tym ważniejszy, czyli dla eth0.2 daj wyższy.
Niestety nie pomogło, nadal jest losowo (eth0.2 dałem '3' a na eth0.350 dałem '2').
Na pałę dodałem coś takiego:
config 'route'
option 'interface' 'wan'
option 'target' '0.0.0.0'
option 'netmask' '0.0.0.0'ale teraz zdarza się że mam albo
route -n
192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 br-lan
212.x.x.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0.2
172.20.x.0 0.0.0.0 255.255.254.0 U 0 0 0 eth0.350
172.20.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0.350
224.0.0.0 0.0.0.0 240.0.0.0 U 0 0 0 eth0.350
0.0.0.0 172.20.x.1 0.0.0.0 UG 0 0 0 eth0.350albo dwie bramy domyślne
route -n
192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 br-lan
212.x.x.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0.2
172.20.x.0 0.0.0.0 255.255.254.0 U 0 0 0 eth0.350
172.20.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0.350
224.0.0.0 0.0.0.0 240.0.0.0 U 0 0 0 eth0.350
0.0.0.0 172.20.x.1 0.0.0.0 UG 0 0 0 eth0.350
0.0.0.0 212.x.x.1 0.0.0.0 UG 0 0 0 eth0.2Wtedy działa, ale
Nie wiem czy tak może być ? że są dwie bramy domyślne ?
--
Pozdrawiam!
Powinno być tak, że dostajesz od ISP jakiś adres na tym VLAN350 po swojej stronie i to jest Twoja brama do tego proxy dla Twoich hostów z LAN. Ten adres raczej powinien być cały czas stały i taki sam. Jeżeli jednak nie jest, to może ustaw po prostu ten routing nie na fizyczny adres IP tylko na konkretny interaface czyli w tym przypadku na eth0.350 - wtedy router będzie zawsze przekazywał ruch na ten interface niezależnie od tego jaki tam będzie IP.
tak zrobiłem, i jest ok, ale ...
Mam teraz problem z bramami.
na początku miałem
/etc/config/network
config 'interface' 'wan_350'
option 'ifname' 'eth0.350'
option 'proto' 'dhcp'
option 'gateway' '0.0.0.0'Teraz żeby zadziało usunąłem gateway i dodałem trasę jak sugerowałeś
/etc/config/network
config 'interface' 'wan_350'
option 'ifname' 'eth0.350'
option 'proto' 'dhcp'
# trasa dla serwera proxy
config 'route'
option 'interface' 'wan_350'
option 'target' '212.x.a.b'i to działa.
Celowo
- nie wskazuję netmask (co oznacza że jest 255.255.255.255)
- nie wskazuję gateway (co oznacza że bierze bramę z interfejsu jak sugerujesz)
Problem :
Po usunięciu gateway z wan_350 mam problem z bramami,
bo bramę domyślną mam
raz z wan_350
route -n
192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 br-lan
212.x.x.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0.2
172.20.x.0 0.0.0.0 255.255.254.0 U 0 0 0 eth0.350
172.20.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0.350
224.0.0.0 0.0.0.0 240.0.0.0 U 0 0 0 eth0.350
0.0.0.0 172.20.x.1 0.0.0.0 UG 0 0 0 eth0.350a raz z wan
route -n
192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 br-lan
212.x.x.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0.2
172.20.x.0 0.0.0.0 255.255.254.0 U 0 0 0 eth0.350
172.20.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0.350
224.0.0.0 0.0.0.0 240.0.0.0 U 0 0 0 eth0.350
0.0.0.0 212.x.x.1 0.0.0.0 UG 0 0 0 eth0.2Brama jest wybierana losowo (chyba zależy od kolejności odpowiedzi DHCP z obu podsieci)
Ale w przypadku gdy brama jest z eth0.350 nie ma netu na końcówkach (tylko przez proxy)
Czy da się tak zrobić by brama domyślna była zawsze tylko z eth0.2
Jeszcze chwilę pomęczę temat.
Teraz mam trasę zdefiniowaną na pałę w pliku network i jak pisałem wszystko pięknie hula.
Jednak i vlan350 jest w adresacji 172.20.x.x (255.255.254.0),
ale czasem przeskakuje do adresacji 172.30.x.x.
Czy wiecie może panowie jak zrobić to dynamicznie,
np. na podstawie przydzielonego adres ip z VLAN350 ?
Albo jak ustawić aby zawsze działało ?
--
Pozdrawiam!
xbartx i sniffer
Działa !!!!
Wielkie dzięki panowie !!!
Szacunek.
P.S.
Wykorzystałem rozwiązanie sniffera bramę na pałę ustawiłem 172.20.x.1 i poszło.
--
Pozdrawiam!
Wywal to --sport any bo to jest chyba zbędne.
BTW snifera rozwiązanie wydaje się bardziej eleganckie.
Ok, próbuje oba rozwiązania, ale w obu chyba jest problem z bramą, bo z tego co pisze sniffer nie ma to być '0.0.0.0'
--
Pozdrawiam!
W zasadzie, jeżeli masz zrobiony nat z klasy lokalnej na interfejs wan_350 to zwykły wpis route do adresu ip_proxy/255.255.255.255 via brama w wan_350 (nie 0.0.0.0) powinien załatwić sprawę.
Jak nie będzie NATa na interfejsie wan_350 to prosiak nie będzie znał rutingu do twojej klasy lokalnej i/lub może blokować dostęp z niej.
Wystarczyoption 'masq' '1'w odpowiedniej sekcji zone w firewallu i ruting...
config 'route' option 'interface' 'wan_350' option 'target' '212.a.b.x' # gdzie 212.a.b.x to IP serwera proxy option 'netmask' '255.255.255.255' option 'gateway' 'ip_bramy_w_wan350'
Z network wyrzuciłem tą bramę ('0.0.0.0') co był na stałe ustawiona, ale nic to nie zmieniło w route -n
Nie wiem skąd mam tą bramę dla wan_350 wytrzasnąć ?
Mam założyć że brama to 172.20.x.1 ?, bo tak wygląda u mnie
route -n
192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 br-lan
212.x.x.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0.2
172.20.x.0 0.0.0.0 255.255.254.0 U 0 0 0 eth0.350
172.20.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0.350
224.0.0.0 0.0.0.0 240.0.0.0 U 0 0 0 eth0.350
0.0.0.0 212.x.x.1 0.0.0.0 UG 0 0 0 eth0.2No to problem masz zasadniczo taki, że proxy, jest jak podejrzewam w tej samej klasie adresowej co Twój zewnętrzny IP na WAN. Tylko, że Twój ISP chce abyś wychodził do niego przez jego sieć wewnętrzną 172.20.x.x - nie będzie to zbyt eleganckie ale może spróbować jakoś takiej reguły:
iptables -t nat -I PREROUTING -p tcp --sport any -s 192.168.1.0/24 -p tcp --dport 8080 -d $adres_proxy -j DNAT --to $adres_bramy_do_172.
Dawno nie korzystałem z iptables, więc regułka może nie być poprawna w każdym bądź razie idea jest taka:
protokół tcp/każdy port/adres źródłowy z podsieci 192.168.1.0/24 w kierunku IP_proxy/protokół tcp/port 8080 skieruj na adres bramy do sieci 172.20.x.x czy równie dobrze na interface od VLAN350. Jakoś tak to widzę.
Coś nie tak z tym poleceniem, bo w wyniku dostaję:
iptables v1.4.6: invalid port/service `any' specified
Try `iptables -h' or 'iptables --help' for more information.Niestety totalna noga jestem z iptables, ale spróbuje jakoś poprawić to polecenie.
--
Pozdrawiam!
W zasadzie, jeżeli masz zrobiony nat z klasy lokalnej na interfejs wan_350 to zwykły wpis route do adresu ip_proxy/255.255.255.255 via brama w wan_350 (nie 0.0.0.0) powinien załatwić sprawę.
Jak nie będzie NATa na interfejsie wan_350 to prosiak nie będzie znał rutingu do twojej klasy lokalnej i/lub może blokować dostęp z niej.
Wystarczyoption 'masq' '1'w odpowiedniej sekcji zone w firewallu i ruting...
config 'route' option 'interface' 'wan_350' option 'target' '212.a.b.x' # gdzie 212.a.b.x to IP serwera proxy option 'netmask' '255.255.255.255' option 'gateway' 'ip_bramy_w_wan350'
Zaraz także i tego spróbuje, ale ...
bramę dla wan_350 mam własnie na pałę ustawioną '0.0.0.0'
(nie wiem czy to dobrze, ale kiedyś jak walczyłem z IPTV, ktoś mi to poradził
i coś tam to poprawiło)
config 'interface' 'wan_350'
option 'ifname' 'eth0.350'
option 'proto' 'dhcp'
option 'gateway' '0.0.0.0'Rozumiem że wpis dot. zone w firewallu ma być ta od 'wan_350' (tak zresztą mam)
Widzę też że netmask jest na końcu .255 ja miałem .254, usunę tą bramę '0.0.0.0'
i wypróbuję ten scenariusz.
No to problem masz zasadniczo taki, że proxy, jest jak podejrzewam w tej samej klasie adresowej co Twój zewnętrzny IP na WAN. Tylko, że Twój ISP chce abyś wychodził do niego przez jego sieć wewnętrzną 172.20.x.x - nie będzie to zbyt eleganckie ale może spróbować jakoś takiej reguły:
iptables -t nat -I PREROUTING -p tcp --sport any -s 192.168.1.0/24 -p tcp --dport 8080 -d $adres_proxy -j DNAT --to $adres_bramy_do_172.
Dawno nie korzystałem z iptables, więc regułka może nie być poprawna w każdym bądź razie idea jest taka:
protokół tcp/każdy port/adres źródłowy z podsieci 192.168.1.0/24 w kierunku IP_proxy/protokół tcp/port 8080 skieruj na adres bramy do sieci 172.20.x.x czy równie dobrze na interface od VLAN350. Jakoś tak to widzę.
Dzięki, zaraz wypróbuję, choć mam bramę dla wan_350 ustawioną na '0.0.0.0'
i nie wiem czy to zadziała ?
To może zdefiniuj co chcesz konkretnie osiągnąć, co chcesz uzyskać.
Jednak jak pisałem,
nie chcę TERAZ całego ruchu do www puszczać przez proxy.
(Wcześniej tak miałem i o to pytałem w tym poście w którym mi odpowiedział Cezary).
Zatem w tej chwili konkretnie chcę osiągnąć to,
aby końcówka decydowała czy idzie przez proxy czy nie
(konfigurując np. przeglądarkę internetową i ustawiając to proxy)
W przypadku gdy proxy nie będzie ustawione ruch ma iść normalnie.
--
Pozdrawiam!
Problem jest w takim razie z routingiem. Należałoby dodać statyczny wpis, który będzie kierował ruch z sieci 192.168.10.0 do IP 212.a.b.x przez
172.20.x.0teraz idzie to po prostu przez default gateway czyli:
0.0.0.0 212.x.x.1 0.0.0.0 UG 0 0 0 eth0.2Z tym że openwrt to nie jest chyba klasyczny router tylko bardziej firewall, więc musiałbyś raczej zrobić jakąś regułę na FW. Sprawdzę w wolnej chwili, bo nie znam tego systemu zbyt dobrze (bawię się dopiero od kilku dni i to głównie z 3G).
xbartx, dzięki za odpowiedz.
Chciałem zrobić to tak, dodając do /etc/config/network:
config 'route'
option 'interface' 'wan_350'
option 'target' '212.a.b.x' # gdzie 212.a.b.x to IP serwera proxy
option 'netmask' '255.255.255.254' # nie wiem czy to dobra maska
option 'gateway' '0.0.0.0'gdzie u mnie wan_350 zdefiniowany jest tak:
config 'interface' 'wan_350'
option 'ifname' 'eth0.350'
option 'proto' 'dhcp'
option 'gateway' '0.0.0.0'Ale dodanie takiej trasy nie działa.
Z kolei wcześniej (pytałem już o coś podobnego kiedyś na forum
http://eko.one.pl/forum/viewtopic.php?id=1697)
chciałem cały ruch z portu 80 przekierować na proxy i wówczas Cezary polecił mi coś takiego:
Zrób regułkę iptables robiącą przekierowanie na proxy, cos w rodzaju:
iptables -t nat -I PREROUTING -s 192.168.1.0/24 -p tcp --dport 80 -j DNAT --to $adres_proxy:$port_proxy
Czyli wszystko co ma iść na 80 leci do proxy.
Czyli jak napisał Cezary wszystko co ma iść na 80 leci do proxy.
Ale teraz nie bardzo o to mi chodzi,
a o to aby na końcówce decydować (poprzez ustawienia przeglądarki)
czy iść przez serwer proxy czy normalnie.
--
Pozdrawiam!
Napisz jeszcze raz ale bardziej dokładnie. Jaką adresację masz w jakim VLAN?
Jeżeli od strony WAN masz dwie adresację to on muszą być w różnych VLAN chyba że masz na myśli 'nie tagowany' jak default vlan.
Od strony WAN (od dostawcy) mam dostęp do dwóch sieci,
- jedna nie tagowaną (ramki nie mają ustawionego VlanId, nie wiem czy to oznacza że to jest "default vlan" ?) z publicznym adresem IP i tu dostępem do Internetu
- drugą Vlan id =350, mam sieć 172.20.x.x i tu jest serwer http_proxy (212.a.b.x:8080) który pozwala wyjść do Internetu.
Jeśli skonfiguruje router tak że używa tylko sieci z VLan id=350 to dostęp na końcówkach mam poprzez ten proxy i działa.
Jeśli jednak skonfiguruje router tak że korzysta z obu sieci wówczas z proxy nie mogę korzystać.
I to własnie mój problem, router mam włączoną obsługę dwóch sieci,
ale z proxy nie mogę korzystać (a chcę).
--
Pozdrawiam!
To ja może odświeżę temat i spytam krócej :
czy da się w ogóle to zrobić ?
--
Pozdrawiam!
Witam!
Mam dwie sieci
- vlan id=350 (dostęp do internetu przez http_proxy powiedzmy 212.a.b.x:8080), siec 172.x.x.x
- nie tagowany (publiczny adres ip) 212.a.b.c
route -n
192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 br-lan
212.x.x.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0.2
172.20.x.0 0.0.0.0 255.255.254.0 U 0 0 0 eth0.350
172.20.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0.350
224.0.0.0 0.0.0.0 240.0.0.0 U 0 0 0 eth0.300
0.0.0.0 212.x.x.1 0.0.0.0 UG 0 0 0 eth0.2Jak widać z vlan350 mam dostęp do 172.20.0.0/16,
Teraz internet na końcówkach (192.168.10.1/24) mam przez nietagowaną sieć,
Jak ustawiam serwer proxy na końcówkach, to mam błąd:
The following error was encountered while trying to retrieve the URL: http://www.bing.com/
Dostęp zabroniony.
Access control configuration prevents your request from being allowed at this time. Please contact your service provider if you feel this is incorrect.
Your cache administrator is not_to_be_disturbed.
--------------------------------------------------------------------------------
Utworzono Sun, 07 Oct 2012 19:28:33 GMT przez proxy02.blebleble.pl (squid)Chciałbym na końcówkach móc wyjść na świat poprzez http_proxy (212.a.b.x:8080).
Jak to zrobić ?
Muszę jakieś trasy zdefiniować czy jak ?
Proszę o pomoc.
--
Pozdrawiam!
Ja uzywam z powodzeniem OpenVPN na 1043ND przez proxy (klient za proxy to OpenVPN windowsowy). Musialem jednak ustawic tcp i port 443 (przeciez musza laczyc sie z bankiem), bo pozostale mam powycinane.
Dzięki, u mnie tak damo było port 443, mnie uratował, no tcp musi być jak jest http_proxy.
Co do moich wcześniejszych uwag, to dla potomnych jednak napiszę,
że potwierdzam w artykule rpc (póki co) jest błąd.
http://rpc.one.pl/index.php/lista-artyk … -w-openwrt
5) Konfiguracja Klienta OpenVPN (vpn_client_lan2.dyndns.biz - LAN2) pod OpenWrt:
jest:
option cert /etc/openvpn/vpn_server_lan1.dyndns.biz.crt
option key /etc/openvpn/vpn_server_lan1.dyndns.biz.keypowinno być
option cert /etc/openvpn/vpn_client_lan2.dyndns.biz.crt
option key /etc/openvpn/vpn_client_lan2.dyndns.biz.keya także w
"Na kliencie VPN (LAN2 - vpn_client_lan2.dyndns.biz) kopiujemy np. za pomocą scp:" brakuje pliku
dh1024.pem, wiec należy go tam także skopiować.
scp -P 22 /etc/easy-rsa/keys/dh1024.pem root@vpn_server_lan1.dyndns.biz:/etc/openvpn--
Pozdrawiam!
eko.one.pl → Posty przez alossek
Forum oparte o PunBB, wspierane przez Informer Technologies, Inc