Połączenie ssh via VPN

[d.dzierzak82]

Witam.
Mam nadzieję, że wątek umieszczam we właściwym miejscu.
Na początek kilka słów o mojej sieci.
Firma posiada główny budynek i kilka oddziałów terenowych.
główny budynek posiada łącze dsl oraz oddziały mają swoje dsl-e
między głównym budynkiem a oddziałami połączenie realizowane jest przez zestawione vpn-y
Adresacja:
budynek główny:
10.1.1.0/24
zdalne biuro np:
10.1.5.0/24
Z mojego hosta mogę pingować komputery w zdalnych lokalizacjach, ale już nie mogę się podłączyć do nich przez ssh.
Wyłączyłem u siebie na próbę firewalla i dalej to sam pingi idą a ssh już nie.
Ja pracuję na linuksie i zdalnie też są linuksy.
żeby było śmieszniej mój współpracownik który pracuje na windowsie nie ma tego problemu.

P.S. sesje ssh w obrębie sieci 10.1.1.0 działają bez problemu
komputer mój --> switch --> komputer zdalny
10.1.1.188 --> switch --> 10.1.1.110

 problem pojawia się gdy sesja musi się przebić z

mojego komputera --> router --> VPN --> router --> komputer zdalny
np:
10.1.1.188 --> 10.1.1.1 --> VPN --> 10.1.5.1 --> 10.1.5.121

Proszę o pomoc

[Paweł Kraszewski]

1. Jak wygląda sprawa ustawień MTU? VPNy potrafią sporo zeżreć a złe ustawienie zabija sesje TCP.

2.  Czy jak próbujesz zrobić telnet (nie ssh) na port 22, to czy serwer SSH się przedstawia? Powinno pojawić się coś na kształt:

Kod: [Zaznacz]

> telnet xx.xx.xx.xx 22
Trying xx.xx.xx.xx...
Connected to xx.xx.xx.xx.
Escape character is '^]'.
SSH-2.0-OpenSSH_7.0

3. Jesteś pewien, kto odpowiada na pingi?

4. Czy próbowałeś odpalać SSH z monitorowaniem połączenia w WireSharku? To pozwoliłoby ogarnąć problem #1, jeżeli 3-way hanshake by się jednak odbył poprawnie a sesja umierała później.

[d.dzierzak82]

1. MTU wszędzie ustawione "default" 1500
2.
ping 10.1.7.80 (przez vpn-na)
PING 10.1.7.80 (10.1.7.80) 56(84) bytes of data.
64 bytes from 10.1.7.80: icmp_seq=1 ttl=62 time=42.2 ms
64 bytes from 10.1.7.80: icmp_seq=2 ttl=62 time=40.9 ms

telnet 10.1.7.80
Trying 10.1.7.80...
telnet: Unable to connect to remote host: Connection timed out

telnet 10.1.7.80:22
telnet: could not resolve 10.1.7.80:22/telnet: Name or service not known

3. tak jestem pewien kto odpowiada na pingi
4.
mam problem z eksploatacją tego narzędzia

[Paweł Kraszewski]

1. Na 95% jest to przyczyną problemu (trust me, pracuję dużo z różnymi VPNami - zarówno gotowymi, przez impementacje Linux/BSD aż po robione całkowicie od zera na własnym protokole). Zbij MTU na 1400 (bezpieczna wartość dla praktycznie wszystkich standardowych rozwiązań VPN) i zobacz, czy to coś da (wystarczy zmienić na urządzeniach końcowych)
2. Jak dokładnie popatrzysz na moją linijkę z telnetem na SSH, to tam nie ma dwukropka przed 22.
3. Rozumiem, że sprawdziłeś to TCPDUMP-em na pingowanym (nie pingującym) urządzeniu?
4. To dość kluczowe narzędzie do diagnostyki problemów sieciowych. Zapoznaj się z nim. To tak, jakby elektryk miał problem z użyciem multimetru albo budowlaniec z użyciem pionu (hm, to akurat częsta przypadłość).

Tutaj masz artykuł naświetający problem - mimo że Ciskowy, to mający zastosowanie do wszystkich rozwiązań VPN.

[d.dzierzak82]

1. zbiłem do 1300 MTU i dalej nic.
2. Próbowałem na różne sposoby, z tym samym efektem
3. Nie jeszcze nie sprawdzałem tcpdump-em
4. Wiem jak ważne jest to narzędzie uczę się go i wiresharka.

Ciekawostka i zagwostka:

maszyna virtualna (linux) -> host (windows)-> switch -> router ->VPN -> router ->switch -> linux
10.1.1.20                        -> 10.1.1.110 ->                                                                      -> 10.1.7.80
ssh w tym układzie działa z MTU 1500

nowy laptop dell(ubuntu 12.04) -> switch -> router -> VPN -> router ->switch -> 10.1.7.80
działa ssh bez problemu

mój komputer ubuntu 15.10 (10.1.1.188) vpn działają tylko w obrębie mojej sieci lan czyli 10.1.1.1- 10.1.1.254
maszyny virtulane -> mój komputer sytuacja jak wyżej

problem nie dotyczy tylko jednego komputera o adresie 10.1.7.80
mam zdalnie do ogarnięcia 60 stacji roboczych z linuxami

[d.dzierzak82]

Sprawdzałem tcpdump-em.
Tcpdump uruchomiony na zdalnym komputerze odpowiedział na
telnet 10.1.7.80 22 informacją 4 pakiety zablokowane
natomiast to samo polecenie wykonane z drugiego komputera (biurko obok) bez problemu przeszło a tcpdump zarejestrował komunikację

instalując ubuntu nie doinstalowałem firewalla,
poleceniem ufw disable wyłączyłem firewalla systemowego
później wydałem polecenie iptables -F
z komputera w mojej sieci poleceniem nmap 10.1.1.188 sprawdziłem porty
nmap zwrócił informację że tylko dwa porty są otwarte.

Nic z tego nie rozumiem.
Proszę o pomoc.

[d.dzierzak82]

Problem rozwiązany.
Rozwiązanie jak dla mnie bardzo dziwne i zaskakujące.
Zakup karty sieciowej na pci-e i zmiana adresu ip rozwiązały problem.
Wyłączenie karty zintegrowanej i przepisanie adresu ip do nowej katy nic nie dało, ale mój współpracownik zażartował sobie ze mnie mówiąc, że zmiana adresu ip rozwiąże ten problem. Nie spodziewał się że ja przestawię kartę z ustawień statycznych na dhcp (jest to absurdalne rozwiązanie i nawet mi do głowy by nie przyszło bo to niedorzeczność.). Po zmianie adresaci mogłem nawiązywać sesje ssh. więc adres wprowadziłem na stałe do ustawien karty sieciowej.

Wszystko teraz działa.

[Paweł Kraszewski]

Wygląda jak skutek działania jakiegoś firewalla albo IPS/IDS-a... Na zasadzie coś źle się logowałeś kilka razy i maszyna docelowa ci zbanowała IP...

[d.dzierzak82]

Jak zadziałało rozwiązanie ze zmiana karty sieciowej i IP to wróciłem do karty zintegrowanej i na niej zmieniłem IP - nic to nie dało.
Wszystkie wcześniejsze próby wykonywałem na wyłączonych firewalach.
Bardzo się cieszę, że zadziałało i jest ok, ale to nie rozwiązuje mojego problemu ponieważ nie znam przyczyny takiej sytuacji.