Dotaz: Linuxový server /router/ + wifi

[alanos]

Ahoj , stojím před úkolem zprovoznit v naší síti i bezdrátovou síť. A teĎ nevím jestli to mám řešit tak že do stávajícího linux routeru /debian/ mám přidat wifi kartu která umožňuje vysílat a nebo do sítě píchnout nějaké AP /asi TP link/ a prostřednictvím něho zpřístupnit bezdrátovou síť. Chtěl bych aby bylo pod jedním rozsahem sitě /192.168.4.1-100 LAN a 192.168.4.100-150 WIFI/ jestli to tak půjde. Pokud by mi mohl někdo poradit s případnými argumenty .. Děkuji.

Odpovědi

[NN]

Pokud ti karta v routeru pokryje pozadovanou oblast,muzes pouzit i kartu, ale predpokladam, ze bude jednoduzsi pouzit vhodne nasmerovane AP, pripadne nekolik AP. Takze predevsim zalezi pro kolik klientu bude bezdratova sit urcena a jakou oblast bude pokryvat.

NN

[alanos]

No dosah sitě budu muset asi řešit nějakou silnější anténou /směrovou neb plac před kanclema je velký :o)./ klientů bude cca 10 /max. reálně ale asi 5ks/, tudíž nic moc velkého . Jen kontrolní dotaz pokud bych tam pichnul AP a server mu přidělil IP 192.168.4.100 dá se potom na tom AP navolit aby on přidloval IP v rozsahu 192.168.4.101-150 , při předpokladu že server tyto IP adresy nepoužíva.

[nway]

Wi-Fi router AP nastavit do režimu Bridge, nastavit mu adresu (static nebo dynamic) a o ostatní se bude starat server/router/Debian. Na AP nastavit jen přístup bezdrátových klientů. Tento způsob komunikace dnes umí snad i ta "nejlevněší" krabička.

[alanos]

Jo jasně TP links to umí, děkuji za nakopnutí já jsem na režim bridge uplně zapoměl , to bude asi tím že jsem si to AP ještě nepořídíl a pořádně nekouknul co t oumí :o). Volím tedy AP .

[Matěj Vaňátko]

Určitě si kup nějaké AP. Z vlastní zkušenosti doporučuji ASUS (např. známé WL-500g)nebo TP-Link. Naopak nedoporučuji D-Link (zvlášť DI-524)... Ale jestli mohu doporučit, nedělej to v 1 subnetu. Rozděl si Wifi a LAN síť. Nejen např. kvůli bezpečnosti, ale i efektivitě provozu. Na Debianu si pak jen nastav patřičné routovací politiky a je to

[alanos]

Hm, něco dělám špatně ... koupil jsem TP link a dal jsem tam teda jiný subnet /on to stejně jinak neumožňoval/ AP tedy poskytuje síť v rozsahu 192.168.1.100-199 .Ale nějak jsem zablambořil na serveru , net normalně v té síti funguje. ALe problém nastal : na sereveru jsmou naroutované sítě :

Směrovací tabulka v jádru pro IP
Adresát         Brána           Maska           Přízn Metrik Odkaz  Užt Rozhraní
hranice         10.222.104.1    255.255.255.255 UGH   0      0        0 eth0
192.168.159.254 *               255.255.255.255 UH    0      0        0 ppp0
praha           10.222.104.1    255.255.255.255 UGH   0      0        0 eth0
192.168.160.0   *               255.255.255.0   U     0      0        0 tap1
192.168.4.0     *               255.255.255.0   U     0      0        0 eth1
192.168.2.0     *               255.255.255.0   U     0      0        0 tun0
192.168.17.0    *               255.255.255.0   U     0      0        0 tun0
192.168.16.0    *               255.255.255.0   U     0      0        0 tun0
10.222.104.0    *               255.255.255.0   U     0      0        0 eth0
192.168.159.0   *               255.255.255.0   U     0      0        0 ppp0
default         10.222.104.1    0.0.0.0         UG    100    0        0 eth0

pokud se na notebooku připojím přes WIFI tak normálně jakoukoliv IP naroutovanou na serveru pingnu. Problém je v tom že na subnetu 192.168.16.0 běží smaba a http. Bohužel na sambu ani http se nedostanu /byť tu IP pingnu/ Na ostaní IP běží RDP a tam se normálně připojím. LAN je 192.168.4.0 /eth1/ WAN je 10.222.104.1 /eth0/. Netuším kde by mohl být zakopaný pes.

[alanos]

Tohle vypíše server při pokusu dostat se z notebooku na http
ip 192.168.4.100 je IP TP linku
tcpdump -i eth1 -l -vv -n -s 0 host 192.168.16.250

08:29:11.808340 IP (tos 0x0, ttl 63, id 22566, offset 0, flags [DF], proto TCP (6), length 64)
    192.168.4.100.53577 > 192.168.16.250.80: Flags [.], cksum 0xf570 (correct), seq 706, ack 603, win 56, options [nop,nop,TS val 129702 ecr 1543246609,nop,nop,sack 1 {2029:2030}], length 0

ovšem na http se nedostanu , nic se nezobrazí. Už si nevím rady kde mám hledat chybu.

[NN]

Udelej si tcpdump jeste na odchozim rozhrani,podle:

192.168.16.0    *               255.255.255.0   U     0      0        0 tun0

je to tun0.

NN

[alanos]

Tak to vypsalo tohle : samozřejmě vice řádku ale ty jsou z počatku dumpu :o)

12:50:23.422632 IP (tos 0x0, ttl 62, id 39179, offset 0, flags [DF], proto TCP (6), length 64)
    192.168.17.12.39250 > 192.168.16.250.5000: Flags [.], cksum 0xc759 (correct), seq 354, ack 1, win 46, options [nop,nop,TS val 4294953927 ecr 1544813672,nop,nop,sack 1 {1429:2592}], length 0
12:50:28.372595 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.17.12 > 192.168.16.250: ICMP echo request, id 287, seq 1, length 64

[alanos]

Akorát jsem se hlasil na http://server:5000 takže je tam místo 80portu 5000port ale u 80 to děla to samé.

[alanos]

Po čase to už vypisovalo jen tohle.:

12:50:38.526017 IP (tos 0x0, ttl 63, id 34188, offset 0, flags [none], proto ICMP (1), length 84)
    192.168.16.250 > 192.168.17.12: ICMP echo reply, id 2335, seq 1, length 64
12:50:43.540209 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.17.12 > 192.168.16.250: ICMP echo request, id 3359, seq 1, length 64
12:50:43.581056 IP (tos 0x0, ttl 63, id 34189, offset 0, flags [none], proto ICMP (1), length 84)
    192.168.16.250 > 192.168.17.12: ICMP echo reply, id 3359, seq 1, length 64

[NN]

Dobry, jelikoz to vypada, ze ICMP funguje, zameril bych se na TCP a pouzil telnet a tcpdump. Pokud se ti nekte na routeru prepise na vystupnim rozhrani port musis se podivat do iptables, jesli si to nekde neprepisujes. Podle vystupu to vypada, ze je tam nejaky DNAT, ktery je nastavecny na libovolne rozhrani..

NN

[alanos]

Je tam jenom maškarada a potom přesměrování na RDP ....
iptables -t nat -L -vn

Chain PREROUTING (policy ACCEPT 1113K packets, 105M bytes)
 pkts bytes target     prot opt in     out     source               destination         
  153  7204 DNAT       tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           tcp dpt:3389 to:192.168.4.53 

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
2393K  182M MASQUERADE  all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT 1975K packets, 155M bytes)
 pkts bytes target     prot opt in     out     source               destination 

jestli mám odchytit něco dalšího tak mi prosím napiš jak, jelikož mé vědomosti jsou v koncích.

[alanos]

Jen pro upřesnění na tom serveru jak jsis všiml běží openvpn server , a pokud se připojím k openvpn tak vše funguje jak má, dostanu se jak na sambu tak na http./rozhrani tap1/

[alanos]

Nikoho nic nenapadá ? Omlouvám se za topnutí ale nemohu to pořád dořešit.

[alanos]

No tak jsem přišel teda na jednu věc , když do složky home /na serveru/ dám třeba jeden soubor *.txt /teda malé velikosti. Tak se normálně objeví a já ho otevřu , bohužel pokud je soubor trochu větší /nebo složka obsahuje moc souboru/ dostanu hlášku že patrně server nereaguje, spojení bylo příliš dlouho neaktivní . Zkouším jak z notebooku na kterem je linux tak z win . Tudíž to padá v momentě kdy je tam moc dat.

[Filip Jirsák]

Není problém v nastavení MTU? Při přenosu toho většího souboru projde víc paketů i s maximální velikostí MTU, nebo to zastaví hned první velký paket?

[alanos]

MTU je na všech siťovkách 1500, virtuální síťovka tun0 má 1412.

[alanos]

Tak jsem to teď zkoušel jak z WIN tak Linuxu a opravdu pokud má načíst větší objem dat tak to spadne okamžitě. Udělal jsem schválně pár adresářů s podadresáři a dal tam soubory o malé velikosti, v tom případě vše funguje pokud do HOME nalinkuji /ln -s/ nějaký adresář s větším obsahem tak to spadne. Zvláštní je ale že když se připojím přes ten openvpn tak to jede normálně i s velkými soubory.

SAMBA server ---> cisco router >> ----------internet ----------------<< linuxrouter <---> muj notebook
                        |___________________vpn tunel____________________|                 

na linux router běží open vpn server když se připojím pomocí openvpn clienta z muj notebook tak to šlape, pokud ale jsem jen v síti za linux router tak jsou ty problémy o kterých píši výše. OpenVPN server tam samozřejmě běží z důvodu jiného než abych se k němu připojoval z vnitření sítě :o).

[Filip Jirsák]

A opravdu všude těch 1500 projde?

[alanos]

No já se podíval jen na nastavení síťovek , nevím jak to mám reálně změřit , to bych poprosit o radu.

[Filip Jirsák]

Zkusil bych třeba ping -s 1492, to by mělo poslat paket dlouhý 1500 bajtů. Vyzkoušejte různé hodnoty okolo, která velikost ještě projde a která už ne.

[alanos]

ping -s 1492 samba
PING server (192.168.16.250) 1492(1520) bytes of data.
1500 bytes from server (192.168.16.250): icmp_req=1 ttl=61 time=85.1 ms
1500 bytes from server (192.168.16.250): icmp_req=2 ttl=61 time=85.1 ms


ping -s 6000 samba
PING server (192.168.16.250) 6000(6028) bytes of data.
6008 bytes from server (192.168.16.250): icmp_req=1 ttl=61 time=196 ms
6008 bytes from server (192.168.16.250): icmp_req=2 ttl=61 time=196 ms
6008 bytes from server (192.168.16.250): icmp_req=3 ttl=61 time=196 ms

dále pořád stejně .. jen se zvyšuje odezva

pingováno z mojeho notebooku.

[Petr Tomášek]

Auuu... tak to je kurňa velký ping.

Můj ping pres wifi (54Mb) vypadá takhle:

$ ping branka
PING branka (192.168.***.10) 56(84) bytes of data.
64 bytes from shaar (192.168.***.10): icmp_req=1 ttl=64 time=1.92 ms
64 bytes from shaar (192.168.***.10): icmp_req=2 ttl=64 time=1.44 ms
64 bytes from shaar (192.168.***.10): icmp_req=3 ttl=64 time=1.99 ms
64 bytes from shaar (192.168.***.10): icmp_req=4 ttl=64 time=1.51 ms

Takže bych si tipnul, že se ti tam ztrácejí packety, ergo bude na vině nejspíš kolize s jinou bezdrátovou sítí, ergo bych tam hodil nějaké sektorové antény, případně těch AP tam dal víc.

Jo, bacha na to, nejnovější "n" standard je na pikaču, protože zabírá de facto celou šíři spektra na 2.4 GHz, takže už nejde si hrát s kanály. (Nebo jinak, jeden spoj 802.11n ti spolehlivě zaruší veškeré další sítě v okolí...)

[alanos]

Ten samba server je v jiném městě to cisco je tam připojeno přes tel. linku , já sem připojil notebook přes UTP /pro jistotu/, ale jak jsem psal výše , pokud se připojím na linux-router k openvpn tak vše šlape bez problému ./ale ty pingu jsou stejne , jen to nepadá a normálně načtu všechny data co potřebuji./

[mato]

pozor na DF flag, skusal by som ping pomocou:

ping -M do -s 1492 $DST

[alanos]

Hmm tak jsem zajel osobně do toho města kde je ten samba server, a zkusil dát ping z tamější vnitřní sítě .

ping -M do -s 1492 sambaserver
From spuctum (192.168.16.83) icmp_seq=1 Frag needed and DF set (mtu = 1500)
--- server ping statistics ---
0 packets transmitted, 0 received, +82625 errors

a po množství řádku jsem to zastavil a konec výpisu vidíte výše . Akorát nevím co to znamená. Ještě vyzkouším ten ping jak se dostanu do sítě za linux-router .

[houska]

"spuctum" ti pise, ze ten paket co jsi poslal je potreba fragmentovat (asi proto, ze tam kam ho ma poslat je MTU mensi nez tech 1500), ale ten paket ma priznak "dont fragment" cili nefragmentovat, takze se tam nedostane

[alanos]

Takže nejvyšší číslo z ktereho jsem dostal odezvu je

ping -M do -s 1472 samba
1480 bytes from samba (192.168.16.250): icmp_req=1 ttl=64 time=2.20 ms

může být něco špatně ? Osobně si myslím že ne...

[alanos]

Takže na vině je MTA , pokud to jede přes vpn tak paket ma max. velikost 1200 , pokud to jede normálně posílá to 1472 a to už nezvládá. Jelikož ciscu nerozumím musel jsem to nechat profíkoví , ten zatím hledá proč to děla. Dám vědět jak to dopadlo.

[alanos]

Musel jsem na XP klientech /i linux klientech/ změnit nastavení síťovky až na MTU 1250 aby to začalo pracovat jak má. Profík od Cisca mi zdělil že je to vinou ADSL připojení, jelikož mi nezbývá než mu věřit ...ale MTU 1250 se mi zdá docela malo.