Skocz do zawartości


 

Zdjęcie

Problem z SSH po VPN na CT proxmox

Problem z SSH po VPN na CT proxmox

  • Proszę się zalogować aby odpowiedzieć
14 odpowiedzi na ten temat

Problem z SSH po VPN na CT proxmox

#1 MarcinV

MarcinV

    Nowy użytkownik

  • Nowy
  • 7 postów
  • Firma:Venkos
  • Imię:Marcin
  • Nazwisko:B

Napisany 04 grudzień 2016 - 13:46

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

 

 

Załączone pliki


  • 0

#2 kolszak

kolszak

    Nowy użytkownik

  • Użytkownicy
  • 3 postów
  • Imię:Karol
  • Nazwisko:Olszewski

Napisany 08 grudzień 2016 - 18:30

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.


  • 0

#3 MarcinV

MarcinV

    Nowy użytkownik

  • Nowy
  • 7 postów
  • Firma:Venkos
  • Imię:Marcin
  • Nazwisko:B

Napisany 09 grudzień 2016 - 20:24

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.


Edytowany przez MarcinV, 09 grudzień 2016 - 20:24.

  • 0

#4 kolszak

kolszak

    Nowy użytkownik

  • Użytkownicy
  • 3 postów
  • Imię:Karol
  • Nazwisko:Olszewski

Napisany 09 grudzień 2016 - 21:22

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


  • 0

#5 MarcinV

MarcinV

    Nowy użytkownik

  • Nowy
  • 7 postów
  • Firma:Venkos
  • Imię:Marcin
  • Nazwisko:B

Napisany 09 grudzień 2016 - 21:31

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


  • 0

#6 kolszak

kolszak

    Nowy użytkownik

  • Użytkownicy
  • 3 postów
  • Imię:Karol
  • Nazwisko:Olszewski

Napisany 09 grudzień 2016 - 22:24

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

 


  • 0

#7 Bartosz Z

Bartosz Z

    Weteran WHT

  • WHT Pro
  • PipPipPipPipPipPipPipPip
  • 857 postów
  • Skąd:Lubelskie
  • Imię:Bartosz

Napisany 09 grudzień 2016 - 22:31

A:
ssh -v root@ip -p port
Co ciekawego mówi?
  • 0

#8 MarcinV

MarcinV

    Nowy użytkownik

  • Nowy
  • 7 postów
  • Firma:Venkos
  • Imię:Marcin
  • Nazwisko:B

Napisany 09 grudzień 2016 - 22:40


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?


Edytowany przez MarcinV, 09 grudzień 2016 - 23:40.

  • 0

#9 kafi

kafi

    Weteran WHT

  • WHT Pro
  • PipPipPipPipPipPipPipPip
  • 3412 postów

Napisany 10 grudzień 2016 - 00:20

Czy może mieć to wpływ?

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

Pokaż config jego firewalla.


  • 0

#10 MarcinV

MarcinV

    Nowy użytkownik

  • Nowy
  • 7 postów
  • Firma:Venkos
  • Imię:Marcin
  • Nazwisko:B

Napisany 10 grudzień 2016 - 00:42

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.


  • 0

#11 kafi

kafi

    Weteran WHT

  • WHT Pro
  • PipPipPipPipPipPipPipPip
  • 3412 postów

Napisany 10 grudzień 2016 - 10:42

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


  • 0

#12 MarcinV

MarcinV

    Nowy użytkownik

  • Nowy
  • 7 postów
  • Firma:Venkos
  • Imię:Marcin
  • Nazwisko:B

Napisany 10 grudzień 2016 - 13:18

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ć?


Edytowany przez MarcinV, 10 grudzień 2016 - 13:27.

  • 0

#13 kafi

kafi

    Weteran WHT

  • WHT Pro
  • PipPipPipPipPipPipPipPip
  • 3412 postów

Napisany 10 grudzień 2016 - 13:44

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.


  • 0

#14 MarcinV

MarcinV

    Nowy użytkownik

  • Nowy
  • 7 postów
  • Firma:Venkos
  • Imię:Marcin
  • Nazwisko:B

Napisany 10 grudzień 2016 - 13:59

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?


Edytowany przez MarcinV, 10 grudzień 2016 - 14:00.

  • 0

#15 kafi

kafi

    Weteran WHT

  • WHT Pro
  • PipPipPipPipPipPipPipPip
  • 3412 postów

Napisany 10 grudzień 2016 - 14:43

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.


  • 0





0 użytkowników czyta ten temat

0 użytkowników, 0 gości, 0 anonimowych użytkowników