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
mam dosyc dziwny problem z połączeniem ssh.
jest serwer który stoi sobie w vlanie 7 adres 172.16.16.10. jako że ja jestem w osobnym vlanie to do niego moge dostac sie przes routerek, który spina oba vlany.
172.16.16.10(samba)-----[switch vlan7, trunk]----[/dev/vlan7 (router VPN) tun0]- - - klient vpn 172.17.2.16 172.16.16.1 172.17.2.1
będąc zalogowanym po ssh do routera VPN robie ssh 172.16.16.10. loguje sie bez problemu (kwestie resolvingu roziwazane w /etc/hosts). wpisuje "ls" listuje mi katalog. ale wpisuje np. "ps ax", "cat plik" i wisi mi terminal :( moge sobie klikac i klikac i nic :(. w tym samym czasie zapuściłem tcpdumpa na routerze VLAN na interfejsie vlan7 i w momecie "zwisu" terminala gdy coś klikam to lecą jakieś pakiety w obie strony.
ale
na routerze mam postawiony OpenVPN który routuje też do tego serwerka samby i o dziwo przez vpn nie ma tych problemow.
co może być powodem takiego zwisu terminala??
Ostatnio edytowany przez Nicram (2010-10-21 21:26:41)
Offline
problem lezy po stronie interfejsu vlanowego:
root@tes:/etc# ping 172.21.7.10 -s 1468 -c1 PING 172.21.7.10 (172.21.7.10) 1468(1496) bytes of data. 1476 bytes from 172.21.7.10: icmp_seq=1 ttl=64 time=0.705 ms --- 172.21.7.10 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.705/0.705/0.705/0.000 ms root@tes:/etc# ping 172.21.7.10 -s 1469 -c1 PING 172.21.7.10 (172.21.7.10) 1469(1497) bytes of data. --- 172.21.7.10 ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms
przez vlan nie przechodzi pakiet wiekszy niz 1468 :(
czy to jest przypadłość vlanu czy czegoś jeszcze nie zrobiłem?
nie jest to czasem wina mtu??
probowałem zwiększyć do 1522 (wyczytałem ze przy vlanach powinno ustawiac 1522 na ethernecie)
# ifconfig eth2 mtu 1522 SIOCSIFMTU: Zły argument
Ostatnio edytowany przez Nicram (2010-11-10 16:14:57)
Offline
skoro nie przechodzi wiekszy niz 1468 to ustaw mtu na 1468+naglowki lub po prostu na 1468 (conajmniej dla interfejsu vlanowego) ... powinno to rozwiazac problem ...
edit: naglowki to 8 bajtow icmp + naglowek IP
Offline
bercik napisał(-a):
skoro nie przechodzi wiekszy niz 1468 to ustaw mtu na 1468+8 lub po prostu na 1468 (conajmniej dla interfejsu vlanowego) ... powinno to rozwiazac problem ...
qrde, no tak. zbyt oczywiste żeby wziąć to pod uwage. ja próbowałem zwiększać, kombinowałem, a wystarczyło zmniejszyć.
wielkie dzięki. teraz widzę, że działa jak powinno :)
metodą prób i błędów ustawiłem mtu na 1492 - to maksymalna wartość przy jakiej idą pakiety. może nie tyle co "idą" ale co są fragmentowane.
------------
troche za wcześnie się cieszyłem. wartości mtu zmieniałem gdy miałem w drugim oknie odpalone:
tcpdump -ni vlan7 icmp
wówczas po zmniejszeniu mtu pingi szły. jak odpalam tcpdumpa bez wchodzenia w tryp promisc (tcpdump -pni vlan7 icmp) to nie ida
18:47:15.925672 IP 172.21.7.1 > 172.21.7.10: ICMP echo request, id 49419, seq 18, length 1448 18:47:15.925681 IP 172.21.7.1 > 172.21.7.10: icmp 18:47:15.926428 IP 172.21.7.10 > 172.21.7.1: icmp 18:47:16.933672 IP 172.21.7.1 > 172.21.7.10: ICMP echo request, id 49419, seq 19, length 1448 18:47:16.933682 IP 172.21.7.1 > 172.21.7.10: icmp 18:47:16.934453 IP 172.21.7.10 > 172.21.7.1: icmp
są requesty, ale odpowiedzi już nie :(
aczkolwiek host 172.21.7.10 odpowiada
18:51:22.537357 IP 172.21.7.1 > 172.21.7.10: ICMP echo request, id 53771, seq 35, length 1448 18:51:22.537403 IP 172.21.7.1 > 172.21.7.10: icmp 18:51:22.537435 IP 172.21.7.10 > 172.21.7.1: ICMP echo reply, id 53771, seq 35, length 1480 18:51:22.537441 IP 172.21.7.10 > 172.21.7.1: icmp
ping wiekszy nie idzie, ale transfer pomędzy hostami jest ok, ssh nie zwiesza się.
już się pogubiłem :( czemu tak sie dzieje, ze icmp w tym przypadku "nie dochodzi"?
Ostatnio edytowany przez Nicram (2010-11-10 19:05:15)
Offline