Skocz do zawartości
MarcinV

Problem z SSH po VPN na CT proxmox

Polecane posty

Witajcie,

 

mam problem z ssh do maszyny podłączonej przez vpn do mikrotika gdzie podłączony jest serwer z proxmoxem a na nim maszyna lxc, która próbuje podłączyć się po ssh do maszyny zdalnej. Poniżej rysunek obrazujący mniej więcej układ.

 

 

 

Generalnie aktualnie jest tak:

 

Serwer A pinguje wszystkie urządzenia w sieci, ssh możliwe również do wszystkich urządzeń (wlącznie z LXC1 i LXC2)

Serwer B pinguje serwer A oraz możliwe jest połączenie ssh (oraz naturalnie do LXC1 oraz LXC2)

LXC1 i LXC2 pinguje serwer A oraz B ale ssh jest możliwe tylko miedzy nimi nawzajem i serwerem B.

 

Potrzebuje ssh z LXC1 do Serwera A ponieważ idzie synchronizacja po rsync.

 

Bardzo proszę o jakieś wskazówki...

 

 

post-43456-0-40869500-1480855453_thumb.png

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Skoro LXC1 i LXC2 pinguje Serwer A, to nie szukaj w routingu i sieci. Sprawdz filtry na ssh, w serwerze i na iptables. Sprawdz czy z LXC1 możesz się zatelnetować na port ssh Serwera A. Ewentualnie gdzieś jest dropowany ruch na firewalu dla nowych połączeń tego typu. Ale najpierw telnet z LXC1 na port ssh serwera A to podstawa.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Więc tak:

 

na adres lokalny (10.10.0.3)

 

telnet nie idzie

ssh nie idzie

ping idzie

 

na adres publiczny (212.29.240.xxx)

 

telnet idzie

ssh idzie

ping idzie

 

Z samego hosta ssh też idzie na serwer po vpn i adresacji lokalnej. Jeden z klientów windows może podmontować sobie zasoby smb po adresacji lokalnej. Sądzę że problem jest gdzieś na samych maszynach LXC.

Edytowano przez MarcinV (zobacz historię edycji)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

wychodzi na to że tak.

root@reserve:/script# tcpdump -i ppp0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
15:29:13.080391 IP vps1.venkos.pl.44450 > 10.10.0.3.57185: Flags [S], seq 71134641, win 29200, options [mss 1410,sackOK,TS val 163204272 ecr 0,nop,wscale 7], length 0

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Rozumiem, że to ssh na porcie 57185. Jeśli tak to faktycznie ruch dochodzi, więc trzeba szukać na serwer A. (host.allow, host.deny, allowusers w sshd_config, firewall).

 

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

root@vps1:~# ssh -v root@10.10.0.3 -p 57185
OpenSSH_6.7p1 Debian-5+deb8u3, OpenSSL 1.0.1t  3 May 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 10.10.0.3 [10.10.0.3] port 57185.

do host.allow dałem sshd:ALL ale to też nic nie dało.

 

 

 

 

Edit.

 

kiedy łącze się z LXC1 do Serwera B to w tcpdumpie widać ewidentnie że łącze się z ip lokalnego, kiedy łączę się z SerweraB do SerweraA to też widać ip remote (10.10.0.2) natomiast kiedy łącze się z LXC1 do SerweraA to łączę się jako domena (vps1.venkos.pl). Czy może mieć to wpływ?

Edytowano przez MarcinV (zobacz historię edycji)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

 

 

Czy może mieć to wpływ?

Tak. Obstawiam zbyt "agresywną" maskaradę na mikrotiku.

Pokaż config jego firewalla.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Dobra już wiem, na MT jest zrobiony NAT publicznych adresów na lokalne.

      chain=dstnat action=dst-nat to-addresses=192.168.1.4 protocol=tcp dst-address=31.179.152.xxx log=no log-prefix="" 

 1    chain=srcnat action=src-nat to-addresses=31.179.152.xxx protocol=tcp src-address=192.168.1.4 log=no log-prefix="" 

Przekazane wszystkie porty. scrnat jest potrzebny ponieważ serwer pocztowy dzięki temu legitymuje się odpowiednim ip a nie adresem bramy, co za tym idzie inne serwery nie odrzucają wiadomości przez błędny RevDNS. po wyłączeniu drugiej reguły idzie wszystko bdb.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Druga reguła jest zbyt agresywna. Wyklucz (via dst-address !=) wszystkie adresacje prywatne, które używasz ;).

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

O to chodziło? Dzięki temu ssh z LXC1 do Serwera A jest możliwe. Czy mogę dodać np całe podsieci?

 

    chain=dstnat action=dst-nat to-addresses=192.168.1.4 protocol=tcp 
      dst-address=31.179.152.xxx log=no log-prefix="" 

 1    chain=srcnat action=src-nat to-addresses=31.179.152.xxx protocol=tcp 
      src-address=192.168.1.4 dst-address=!10.10.0.3 log=no log-prefix="" 

 

 

Edit.

 

 

Użyłem dst-address-list

 1    chain=srcnat action=src-nat to-addresses=31.179.152.xxx protocol=tcp 
      src-address=192.168.1.4 dst-address-list=!Test log=no log-prefix=""

oraz stworzyłem listę:

[root@Venkos MT] /ip firewall address-list> print
Flags: X - disabled, D - dynamic 
 #   LIST              ADDRESS                               TIMEOUT             
 0   Test              192.168.1.0/24                       
 1   Test              10.10.0.0/24  

Ma prawo to prawidłowo działać?

Edytowano przez MarcinV (zobacz historię edycji)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Dokładnie o to chodziło ;)
Regułkę SNATującą sieć 192.168.1.0/24 (bo zakładam, że gdzieś niżej też masz taką) także uzupełnij o dst-address-list=!Test.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Masz na mysli maskaradę? Zrobione są dwie, na siec 192.168.1.0/24 i na 10.10.0.0/24.

 

 

edit.

 

 

Jeszcze jedno pytanie. Rsync puszczony na publiczny ip osiąga ok 32 Mbps czyli max mojego łącza, a po VPN już tylko 16-17 Mbps.Tak duza utrata jest przy vpn?

Edytowano przez MarcinV (zobacz historię edycji)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Tak - maskarada też powinna mieć wykluczenie adresów dst. Inaczej z innych komputerów będziesz miał podobne problemy (chyba, że maskarada ma ustawiony dodatkowo out-interface, to wtedy ten filtr zrobi się niejako samoczynnie).

 

Takie wyłączenie należy stosować, gdyż bez niego ruch z sieci macierzystej do jakiejkolwiek innej (nawet, jeżeli ta inna sieć jest bezpośrednio połączona do routera) powoduje nałożenie translacji SNAT/maskarady i w konsekwencji... wypchnięcie domyślną trasą routingu ze zmienionym adresem, niezależnie od ustawień tablicy routingu.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Bądź aktywny! Zaloguj się lub utwórz konto

Tylko zarejestrowani użytkownicy mogą komentować zawartość tej strony

Utwórz konto

Zarejestruj nowe konto, to proste!

Zarejestruj nowe konto

Zaloguj się

Posiadasz własne konto? Użyj go!

Zaloguj się


×