środa, 10 lutego 2016

IPSEC VPN i problemy z ssh

Wbijałem się ostatnio do testowych maszyn, które zostały mi wystawione przy pomocy Shrew Software VPN. To cudo bazuje na IPSEC i IKE. W Fedorę jest wbudowany klient tego VPNu i jego postanowiłem użyć:

ike.x86_64 : Shrew Soft VPN Client For Linux

Od dostawcy VPNu dostałem profil PCF, który się prawie zaimportował. Nie wciągnął sobie adresu bramki, wartości klucza PSK i identyfikatora klucza. O ile bramka i identyfikator są tekstowe, o tyle PSK jest zaszyfrowany i musiałem go wyciągnąć oddzielnie od dostawcy. (cisco-decrypt tu nie pomaga :-\ )

Po zapięciu połączenia dostajemy interfejs tap0:

12: tap0: <BROADCAST,UP,LOWER_UP> mtu 1200 qdisc noqueue state UNKNOWN group default qlen 500
    link/ether 56:55:f3:de:c3:32 brd ff:ff:ff:ff:ff:ff
    inet 192.168.254.69/32 brd 192.168.254.69 scope global tap0
       valid_lft forever preferred_lft forever


Okazało się, że trafiam na ciekawy objaw: 
SSH do hosta zawisa na 

debug1: SSH2_MSG_KEXINIT sent.

Żeby było zabawniej jak robię telnet na port 22 tegoż hosta to SSH odpowiada.

Po googlaniu okazało się, że istotne jest MTU, które VPN domyślnie ustawia na 1380, co według różnych forów jest zbyt dużą wartością, dlatego zmniejszyłem ją do 1200. 
To problemu nie rozwiązało. Dalsze przeszukiwanie sieci pokazało jeszcze jedną sugestię. Linux wydaje się ignorować informacje o fragmentowaniu pakietów przez routery po drodze. Ale znalazłem zaklęcie, które to naprawia. miałem trochę szczęścia, bo wkleiłem je bez zrozumienia i działa :-)

firewall-cmd --direct --add-passthrough ipv4 -I OUTPUT -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Teraz muszę rozkminić jak to ubrać w regułkę, którą firewalld będzie łykał i monitorował, bo dodanie "passthrough" jest mało zgrabne.

Brak komentarzy:

Prześlij komentarz