Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Witam grono!
Posiadam skonfigurowanego debiana do przekierowania internetu dzięki poradnikowi pani BiExi. Problem jest taki, że niektóre strony się nie otwierają na klientach w sieci LAN (np. tp.pl, nk.pl, epson.com). Na serwerze wszystkie strony chodzą. W sieci mamy jeszcze jedną bramę do internetu i na niej (te same dnsy) wszystko działa. Gdzie może leżeć problem?
Temat został już poruszony na innym forum, ale pomocy nie uzyskałem :(
Offline
Złe adresy DNS na komputerach klientów :)
Offline
zakładając, że masz tak samo zrobione jak w poradniku to w /etc/dhcp3/dhcpd.conf masz mieć
ddns-update-style ad-hoc; subnet 192.168.1.0 netmask 255.255.255.0 { range 192.168.1.10 192.168.1.20; default-lease-time 3600; option domain-name "ble.pl"; option domain-name-servers 208.67.222.222, 208.67.220.220, 8.8.8.8; option netbios-name-servers 192.168.1.1; option routers 192.168.1.1; option subnet-mask 255.255.255.0; option broadcast-address 192.168.1.255; }
EDIT:
ja sobie ustawiałem debiana według tego -> http://firsthost.nazwa.pl/wordpress/2009/01/28/domo … ebianie-cz-1/ i śmiga
Ostatnio edytowany przez urbinek (2010-04-16 15:47:35)
Offline
Witam,
Przepraszam za opóźnienie, ale choroba mnie zmogła :/
giegiel napisał(-a):
Złe adresy DNS na komputerach klientów :)
DNSy są wpisane na stałe (te od netii) i działają na obu bramach.
urbinek napisał(-a):
zakładając, że masz tak samo zrobione jak w poradniku to w /etc/dhcp3/dhcpd.conf masz mieć
ja sobie ustawiałem debiana według tego -> http://.../ i śmiga
Nie mam zainstalowanego dhcpd, bo za serwerem jest router.
Ten drugi sposób nie działa u mnie wogóle ;/
Tak mniej więcej wygląda topologia:
WAN1(adsl) ---> Debian(192.168.1.11) - | ---> Ruter(192.168.1.1) ---> Host(192.168.1.x) | WAN2(wifi) ---> AP(port WAN) ---------
wp.pl działa bez zarzutu, a onet.pl nie otwiera się wogóle.. ;/
Offline
jak znajdę krosa albo zaciskarkę to spróbuję ;)
router zwykły z wifi: WAN2 jest podpięty pod port WAN, a WAN1(serwer) jest wpięty w port LAN2 jako zwykły komputer w sieci udostępniający połączenie ;)
Offline
Blee Co to za AP ? i jaką bramę dajesz hostom ?
Ostatnio edytowany przez pasqdnik (2010-04-21 17:34:30)
Offline
Na 'pejcie' się nie znam :p
Nie widzę, gdzie tu się załączniki wrzuca, więc wkleję tutaj..
Zaciskarka będzie jutro dopiero :/
Ostatnio edytowany przez aeMaeTH (2010-04-22 08:53:28)
Offline
ekspertem nie jestem ale to nie ma prawa działać :)
zwykłe routery to nic innego jak router 2 portowy zintegrowany ze switchem 4 portowym
WAN to wejście, LAN to wyjście i nie przekierujesz ruchu wychodzącego przez port LAN (chyba, że na mieszasz ustawiając bramy i trasowanie ale to tylko spekulacje..)
jak odepniesz serwer powinno wszystko działać normalnie, może on ma jakimś dziwnym sposobem wpływ na trasowanie, ewentualnie AP ci się sypie/jest źle ustawiony
a teraz z drugiej beczki co chcesz osiągać ?
2 zsumowane łącza czy jedno stałe i drugie za pasowe ?
ale jak nie wybierzesz musisz wywalić router i wpiąć AP i modem do serwera i na nim ustawić trasowanie, dhcp, forward itp itp
Offline
Problem nieotwierających się niektórych stron jest prawdopodobnie w zbyt wysokim MTU
http://www.debianadmin.com/change-mtu-maximum-trans … nterface.html
Ostatnio edytowany przez buli (2010-04-22 11:44:50)
Offline
Ok... to może od początku, bo najwidoczniej nie zapoznałeś się z tematem z innego forum (patrz pierwszy post).
Od pewnego czasu przestały nam się w biurze otwierać NIEKTÓRE strony internetowe. Mamy w firmie postawiony serwer na Debian 5.0, do którego podłączony jest modem ADSL przez LAN. Wszystkie komputery są podłączone do rutera (AirLive z Tomato). W sieci mamy dwie bramy do internetu: jedna z serwera a druga bezpośrednio z AP (wifi). Wszystkie strony się otwierają w konsoli linuksa, natomiast już na komputerach w sieci jest problem. Na drugiej bramie oczywiście wszystko chodzi. Komputery w firmie są z różnymi systemami Windows, więc problem MUSI leżeć po stronie serwera.
Najprawdopodobniej coś nie tak z rutingiem w iptables.
Mam też zainstalowany pakiet denyhost, ale jak by to była jego wina to by na linuksie też strony nie chodziły..
Po krótce: wszystko działało jak ta lala ;)
Coś się spsuło i niestety nie wiem kiedy i dlaczego ;(
Przed chwilą wgrałem najnowszego tomato 1.27, więc router został wyczyszczony i dalej niektóre strony nie chodzą
Ostatnio edytowany przez aeMaeTH (2010-04-22 11:44:24)
Offline
buli napisał(-a):
Problem nieotwierających się niektórych stron jest prawdopodobnie w zbyt wysokim MTU
http://www.debianadmin.com/change-mtu-maximum-trans … nterface.html
MTU jest ustawione na 1500.
Jak zmieniłem na 1492 to się NIC nie otwierało ;)
Offline
Możesz pokazać ifconfig?
czy pc wpięty w port lan4 ma ten sam problem? chciałbym ustalić, że problem wynika na poziomie serwera..
Offline
debian:~# ifconfig eth0 Link encap:Ethernet HWaddr 00:23:54:5d:34:74 inet addr:192.168.1.11 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::223:54ff:fe5d:3474/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:344886 errors:0 dropped:0 overruns:0 frame:0 TX packets:315349 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:50413671 (48.0 MiB) TX bytes:301833307 (287.8 MiB) Interrupt:21 Base address:0xe000 eth1 Link encap:Ethernet HWaddr 00:30:4f:47:1b:9e inet6 addr: fe80::230:4fff:fe47:1b9e/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:744012 errors:0 dropped:0 overruns:0 frame:0 TX packets:694682 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:453065192 (432.0 MiB) TX bytes:259358842 (247.3 MiB) Interrupt:19 Base address:0x4c00 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:7929 errors:0 dropped:0 overruns:0 frame:0 TX packets:7929 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:4210551 (4.0 MiB) TX bytes:4210551 (4.0 MiB) ppp0 Link encap:Point-to-Point Protocol inet addr:213.238.80.118 P-t-P:195.114.190.151 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1 RX packets:742835 errors:0 dropped:0 overruns:0 frame:0 TX packets:693496 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:3 RX bytes:436652090 (416.4 MiB) TX bytes:244023522 (232.7 MiB)
Wszystkie PeCety są na WiFi. Nie wiem co to za różnica, ale mogę jutro podpiąć jakiś pod LAN4 ;)
Offline
mtu ustawiasz na ppp0? Masz tam 1492 to może sprawdź na 1500
Ostatnio edytowany przez buli (2010-04-22 20:08:25)
Offline
jakby cos z ppp0 bylo zle to by te stronki sie rowniez nie otwieraly na serwerze.. a sie otwieraja na xterm'ie :/
poza tym adsl (neo, netia) działa na mtu=1492..
Ostatnio edytowany przez aeMaeTH (2010-04-22 22:46:44)
Offline
Chciałem abyś wpiął kompa po lanie aby wykluczyć AP z którym łączy się PC1...PCn
Offline
Witam po weekendzie ;)
Sprawdziłem:
a\ komputer PC1 podpięty pod LAN4
b\ podpięty switch na drodze SERWER-PC1 (zaciskarki nie dostałem, więc krosa zrobić nie mogłem)
W obu przypadkach dzieje się to samo co normalnie w sieci na WiFi, czyli stronki NIEKTÓRE się wogóle nie otwierają, przeglądarka po prostu wisi i czeka na niewiadomo co..
Co ciekawe onet.pl się trochę załadował i wygląda tak:
Kolega przez weekend zasugerował, że to mogła jakaś poprawka do debiana zdziałać.. bo wcześniej wszystko działało i dopiero od nieco ponad miesiąca przestało :/
Bardzo proszę o dalsze pomysły bo skończy się reinstalacją debiana, a mam tam już sporo rzeczy zainstalowanych i zajmie mi kilka dni tego przywrócenie :(
Offline
pokaz jeszcze Twoj skrypt ktorym robisz maskarade i konfiguracje dhcpd
oraz cat /etc/resolv.conf
Offline
firewall
# wlaczenie w kernelu forwardowania /bin/echo 1 > /proc/sys/net/ipv4/ip_forward # Ochrona przed atakiem typu Smurf /bin/echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts # Nie aktceptujemy pakietow "source route" /bin/echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route # Nie przyjmujemy pakietow ICMP rediect, ktore moga zmienic tablice routingu /bin/echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects # Wlaczamy ochrone przed blednymi komunikatami ICMP error /bin/echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses # Wlaczenie mechanizmu wykrywania oczywistych falszerstw # (pakiety znajdujace sie tylko tablicy routingu) /bin/echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter /bin/echo 1 > /proc/sys/net/ipv4/tcp_timestamps /bin/echo 1 > /proc/sys/net/ipv4/conf/all/log_martians /bin/echo 10 > /proc/sys/net/ipv4/ipfrag_time /bin/echo 65536 > /proc/sys/net/ipv4/netfilter/ip_conntrack_max /bin/echo 36024 > /proc/sys/net/ipv4/tcp_max_syn_backlog # zwiekszenie rozmaru tablicy ARP /bin/echo 1024 > /proc/sys/net/ipv4/neigh/default/gc_thresh1 /bin/echo 4096 > /proc/sys/net/ipv4/neigh/default/gc_thresh2 /bin/echo 8192 > /proc/sys/net/ipv4/neigh/default/gc_thresh3 /bin/echo 1 > /proc/sys/net/ipv4/tcp_rfc1337 /bin/echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc /bin/echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses /bin/echo 60 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close_wait /bin/echo 360 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established /bin/echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout /bin/echo 2400 > /proc/sys/net/ipv4/tcp_keepalive_time /bin/echo 0 > /proc/sys/net/ipv4/tcp_window_scaling /bin/echo 0 > /proc/sys/net/ipv4/tcp_sack /bin/echo 20 > /proc/sys/net/ipv4/ipfrag_time /bin/echo 1280 > /proc/sys/net/ipv4/tcp_max_syn_backlog # Blokada przed atakami typu SYN FLOODING /bin/echo 1 > /proc/sys/net/ipv4/tcp_syncookies # Właczenie proxy arp - dzieki temu serwer nie zdycha po kilku #/bin/echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter # Zwiekszenie rozmiarutablic routingu /bin/echo "18192" > /proc/sys/net/ipv4/route/max_size # czyszczenie starych regul iptables -F iptables -X iptables -t nat -X iptables -t nat -F iptables -t mangle -F iptables -t mangle -X # ustawienie domyslnej polityki iptables -P INPUT ACCEPT iptables -P FORWARD ACCEPT iptables -P OUTPUT ACCEPT iptables -A INPUT -m conntrack --ctstate NEW -p tcp --tcp-flags SYN,RST,ACK,FIN,URG,PSH ACK -j DROP iptables -A INPUT -m conntrack --ctstate NEW -p tcp --tcp-flags SYN,RST,ACK,FIN,URG,PSH FIN -j DROP iptables -A INPUT -m conntrack --ctstate NEW -p tcp --tcp-flags SYN,RST,ACK,FIN,URG,PSH FIN,URG,PSH -j DROP # utrzymanie polaczen nawiazanych iptables -A INPUT -j ACCEPT -m state --state ESTABLISHED,RELATED iptables -A FORWARD -j ACCEPT -m state --state ESTABLISHED,RELATED iptables -A OUTPUT -j ACCEPT -m state --state ESTABLISHED,RELATED # udostepniaie internetu w sieci lokalnej iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -j MASQUERADE iptables -A FORWARD -s 192.168.1.0/24 -j ACCEPT
DHCP nie jest uruchomione, wszystkie komputery mają IP na sztywno wpisane, a na routerze jest dhcp na kilku dodatkowych klientów.
resolv.conf
nameserver 62.233.233.233 nameserver 213.241.79.37 search
Offline
rozumiem, że takie same dnsy masz na sztywno wpisane w komputerach końcowych?
I tak mi przyszło jeszcze na myśl.. pokaż wynik traceroute wykonanego dla strony która nie działa na PCn
Tutaj masz narzędzia online: http://noc.gts.pl/
Offline
ano zrobię i to jak będę jutro w biurze, ale powiem tylko, że zainstalowałem sobie (też na to wpadłem ;p) VisualRoute i jedna stronka przeszła do końca (nie pamiętam która), a tp.pl utknęła na jakimś firewallu.. jutro będą szczegóły :)
Dodane:
Poniżej traceroute dla stronki, która działa (wp.pl) i dwóch, które nie działają (tp.pl, microsoft.com)
Tracing the route to wp.pl: traceroute to wp.pl (212.77.100.101), 30 hops max, 40 byte packets 2 217.153.235.185 (217.153.235.185) 0.915 ms 0.897 ms 0.904 ms 3 157.25.248.57 (157.25.248.57) 1.576 ms 1.574 ms 1.598 ms 4 taro-dbp2-so-0-0-0-0.net.ipartners.pl (157.25.4.246) 1.372 ms 1.356 ms 1.421 ms 5 157.25.248.70 (157.25.248.70) 0.663 ms 0.653 ms 1.136 ms 6 atman.gix.net.pl (157.25.1.145) 1.223 ms 1.217 ms 1.212 ms 7 wp.ac-x.pl (212.91.0.19) 6.431 ms 6.460 ms 6.450 ms 8 do-r2.rtrd2.adm.wp-sa.pl (212.77.96.102) 6.428 ms do-r2.rtrd1.adm.wp-sa.pl (212.77.96.98) 6.392 ms do-r2.rtrd2.adm.wp-sa.pl (212.77.96.102) 6.418 ms 9 www.wp.pl (212.77.100.101) 7.161 ms 6.699 ms 6.670 ms Tracing the route to tp.pl: traceroute to tp.pl (217.97.216.10), 30 hops max, 40 byte packets 2 217.153.235.185 (217.153.235.185) 1.253 ms 1.359 ms 1.392 ms 3 157.25.248.57 (157.25.248.57) 1.308 ms 1.299 ms 1.292 ms 4 taro-dbp2-so-0-0-0-0.net.ipartners.pl (157.25.4.246) 1.077 ms 1.143 ms 1.159 ms 5 157.25.248.70 (157.25.248.70) 0.954 ms 0.933 ms 0.864 ms 6 80.50.131.177 (80.50.131.177) 1.276 ms 1.263 ms 1.279 ms 7 lodz-ar2.tpnet.pl (195.205.0.110) 3.110 ms 3.241 ms 3.108 ms 8 80.50.67.2 (80.50.67.2) 3.251 ms 3.311 ms 3.355 ms 9 * * * ... 30 * * * Tracing the route to microsoft.com: traceroute to microsoft.com (207.46.232.182), 30 hops max, 40 byte packets 2 217.153.235.185 (217.153.235.185) 0.896 ms 0.750 ms 0.723 ms 3 157.25.248.57 (157.25.248.57) 1.166 ms 1.160 ms 1.153 ms 4 taro-dbp1-so-0-0-0-0.net.ipartners.pl (157.25.4.237) 0.577 ms 0.567 ms 1.026 ms 5 plwaw1-so-1-0-0-0.net.ipartners.pl (157.25.248.34) 1.000 ms 0.993 ms 0.999 ms 6 war-b3-link.telia.net (213.248.99.157) 0.901 ms 0.893 ms 0.947 ms 7 war-b1-link.telia.net (80.91.249.148) 0.839 ms 0.948 ms 1.115 ms 8 hbg-bb2-link.telia.net (80.91.247.134) 16.764 ms 16.631 ms 16.789 ms 9 ldn-bb2-link.telia.net (80.91.247.45) 30.564 ms ldn-bb2-link.telia.net (80.91.254.219) 30.717 ms ldn-bb2-link.telia.net (80.239.147.185) 30.688 ms 10 ash-bb1-link.telia.net (80.91.251.209) 115.602 ms ash-bb1-link.telia.net (213.248.65.210) 109.907 ms 110.027 ms 11 microsoft-ic-119510-ash-bb1.c.telia.net (213.248.89.18) 116.296 ms 116.290 ms 116.257 ms 12 (209.240.199.99) 109.986 ms 109.982 ms 110.096 ms 13 xe-0-1-2-0.ch1-16c-1a.ntwk.msn.net (207.46.43.90) 127.274 ms 127.153 ms 127.113 ms 14 ge-3-1-0-0.co1-64c-1a.ntwk.msn.net (207.46.46.118) 176.816 ms 177.762 ms 177.020 ms 15 ge-7-0-0-0.co1-64c-1b.ntwk.msn.net (207.46.43.173) 191.203 ms 191.130 ms 191.115 ms 16 ge-7-2-0-0.wst-64cb-1b.ntwk.msn.net (207.46.46.116) 178.664 ms 178.637 ms 179.163 ms 17 ge-4-3-0-0.tuk-64cb-1b.ntwk.msn.net (207.46.46.162) 177.810 ms 189.298 ms 189.263 ms 18 ten1-2.tuk-76c-1a.ntwk.msn.net (207.46.46.17) 349.325 ms 303.224 ms 303.213 ms 19 po16.tuk-65ns-mcs-1b.ntwk.msn.net (207.46.35.142) 195.243 ms 195.261 ms 195.236 ms 20 * * * ... 30 * * *
Dodane:
Skończyły Wam się pomysły? Niedobrze..
To może pytanie pomocnicze: co kontroluje/ogranicza ruch w sieci oprócz iptables? Gdzie szukać winowajcy?
Ostatnio edytowany przez aeMaeTH (2010-04-30 07:29:20)
Offline
Witam ponownie po długiej przerwie.
Problem został "rozwiązany". Przyczyny nie znalazłem, więc spróbowałem czegoś innego. Ponieważ błąd występował w momencie przekazywania pakietów z serwera do rutera, postanowiłem zmienić sposób samego "przekazywania" i jednocześnie usprawnić internet w firmie. Jak? Instalując pakiet squid - serwer proxy. Teraz wszystko działa tak jak należy, a i łącze zostało odciążone w stopniu zauważalnym.
Pozdrawiam!
ps.
temacik do zamknięcia
Offline
W moim przypadku przyczyną była niezgodność MTU na interfejsie routera po stronie sieci wewnętrznej (było 1492) i na interfejsach stacji roboczych w niej (domyślnie 1500).
W dhcpd.conf dodałem dla podsieci podpiętej na tym interfejsie:
subnet 192.168.1.0 netmask 255.255.255.0 { # .... option interface-mtu 1492; # .... }
Objawem były okresowe problemy w działaniu GMail chat oraz niemożność połączenia do pogoda.onet.pl i innych stron.
Tcpdump-y odpalone na routerze jednocześnie na interfejsie zewnętrznym i wewnętrznym pokazywały, że w trakcie nawiązywania połączenia TCP ze strony stacji w sieci wewnętrznej do serwera na zewnątrz, niektóre pakiety odpowiedzi powracające z zewnętrznego serwera ginęły na routerze - widać było jak nadchodzą na interfejsie zewnętrznym routera, ale nie wychodzą na wewnętrznym.
Ostatnio edytowany przez olo (2010-08-02 10:31:21)
Offline