Problem z SSH po VPN na CT proxmox

[MarcinV 0]

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...

 

 

[kolszak 0]

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.

[MarcinV 0]

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 Grudzień 9, 2016 przez MarcinV (zobacz historię edycji)

[kolszak 0]

tcpdump i sprawdź czy ruch ssh przychodzi na serwer A z LXC1.

[MarcinV 0]

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

[kolszak 0]

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).

 

[Bartosz Z 236]

A:

ssh -v root@ip -p port

Co ciekawego mówi?

[MarcinV 0]

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 Grudzień 9, 2016 przez MarcinV (zobacz historię edycji)

[kafi 2425]

 

 

Czy może mieć to wpływ?

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

Pokaż config jego firewalla.

[MarcinV 0]

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.

[kafi 2425]

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

[MarcinV 0]

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 Grudzień 10, 2016 przez MarcinV (zobacz historię edycji)

[kafi 2425]

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.

[MarcinV 0]

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 Grudzień 10, 2016 przez MarcinV (zobacz historię edycji)

[kafi 2425]

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.