RSS Feed

‘vpn’ Category

  1. OpenVPN – No buffer space available (code=55)

    Maj 13, 2015 by 0verlord

    Klikam OpenVPNa dla klienta – musiał się podłączyć do bazy na hoście, ale że host był odfiltrowany od wszelkiego zła (tj. Internetu) trzeba było przepuścić ruch przez vpna.

    W skrócie dla niecierpliwych – taki komunikat oznacza, że wygenerowaliśmy pętlę routingu – np. że wypychamy do klienta (push) trasę do IP, która musi być dostępny normalnie, nie przez vpna – jeżeli serwer vpn ma ipka 1.2.3.4 a w konfigu OpenVPNa wypychamy trasę na ten ipek (push „route 1.2.3.4 255.255.255.0 192.168.1.1”) przez vpna, którego właśnie zestawiamy – tak się dzieje.
    Oczywiście to jest logiczne i naturalne, ale czasem ucieka w pogoni za Innym Lepszym Sensem i z powodu nadmiaru pracy.

    U mnie było tak, że początkowo baza stała na virtualce (konkretnie w LXC). Wtedy OpenVPN stał sobie na głównym hoście i pushował trasy do virtualki dla klientów. Prawie działało, bo ogólnie Firebird takich ustawień nie lubi z kilku powodów (opowieść na inną notkę). Natomiast wtedy OpenVPN się zestawiał.
    Szybka zmiana i „dostrojenie” konfiguracji i jak się okazało, wypchnąłem trasę na IP hosta, na którym stał OpenVPN. Stąd komunikat jak w temacie i ciągłe rekonekty i brak komunikacji.

    Czyli drogie dzieci – po takim komunikacie na kliencie, szukamy w konfigu, co to za jadowita trasa nam się wypycha, a nie powinna i w efekcie zapętla nam się routing.


  2. OpenVPN, Mikrotik i Bad LZO decompression header byte

    Marzec 25, 2013 by 0verlord

    mikrotik

    Mikrotik to ogólnie fajny sprzęt i sporo może. Niestety kilka rzeczy jest nie do końca zaimplementowanych. Jedną z tych rzeczy jest OpenVPN.

    Mimo najnowszej wersji softu i na wydawałoby się – poprawnego konfiga, tym razem nie chciał się połączyć.
    Objawy były takie, że łączyło mnie, a po jakimś czasie do loga szedł komunikat
    Inactivity timeout (--ping-restart)
    i oczywiście rozłączało, potem łączyło znowu, znowu nie mogłem nic pingnąć po drugiej stronie i tak w kółko.

    Logi śmiecił jeszcze komunikat pt:
    Bad LZO decompression header byte: (numerek)

    To już w ogóle było pozornie bez związku, ale poszedłem tropem tegoż węża. Po stronie klienta próbowałem to wyłączyć ustawiając
    use-compression=no

    w /ppp profile, ale to nic nie dało. Rzut oka do konfiga po stronie serwera ujawnił straszliwa prawdę – była tam odkomentowana dyrektywa comp-lzo.
    Zakoment, restart openvpna i tadam.wav.

    Podsumowując:

    1. mikrotik obsługuje OpenVPNa w trybie klienta, ale tylko po TCP, udp nie jest zaimplementowane.
    2. … za to obsługuje autoryzację zarówno po certyfikacie, jak i po userze/haśle.
    3. klient nie rozumie kompresji – po stronie serwera trzeba wyłaczyć comp-lzo
    4. jeżeli nie mamy kontroli nad serwerem, i nie możemy tam dodać trasy do podsieci zza naszego vpna, trzeba dodać regułkę maskarady na interfejsie ovpn-out1 (czy też jakkolwiek się u Was nazywa)


  3. OpenVPN i WrwrWrwrWrwrWrwr w logu oraz Need IPv6

    Marzec 6, 2012 by 0verlord

    Jeżeli przy konfiguracji OpenVPNa w logu pojawiają się długie linijki jak w temacie przy każdym ruchu sieciowym (najlepiej widać na przykładzie pinga) to należy zmniejszyć poziom debuga w konfigu. Poziom debuga „verb 2” załatwi problem.

    Need IPv6 code in mroute_extract_addr_from_packet – ten komunikat jest trochę głupszy, bo rozwiązaniem jest wyłączenie protokołu ipv6 na interfejsie tun. Problemem jest sterownik tun pod Windowsy, nie obsługuje jeszcze ipv6 wystarczająco stabilnie, żeby chłopaki puścili go do produkcji. Albo zrobi się jak w przypadku innych narzędzi opensourcowych – nowe wersje tylko dla płacących klientów. Taki los.

    Jak na razie nie musiałem pchać ipv6 po tunelach OpenVPNowych, więc nawet ciężko mi się wypowiedzieć.


  4. Windows, vpn, pptp, poczta i Subiekt

    Sierpień 26, 2011 by 0verlord

    Z cyklu ciekawostek do zapamiętania. Jest sobie pan klient. Pan klient ma sobie koncentratorek vpnka po pptp na Debianie (6.x). Ma przez to działać Subiekt oraz poczta z lokalnego serwera (cachujący imap z fetchmailem).

    Problem: poczta przychodząca działa, wychodząca stoi i łapie timeout, Subiekt znajduje serwer i łączy się z bazą, ale tak przy pi*oko 88% pokazuje, że wystąpił błąd, i nie da się znaleźć listy podmiotów, albo że struktura danych podmiotu nie jest prawidłowa.
    W tym samym czasie program serwisowy łączy się i widzi dokładnie wszystkie bazy i pozwala na operacje na nich (np. backup).

    Diagnoza była długa i bolała, mnie i pana klienta. Natomiast jak się okazało, ten DSL telepsowy, który pan klient ma u siebie, wymaga zmniejszenia rozmiaru ramki na ifejsie natującym do 1490 (przy 1500 przechodzi tylko ping). Problem u pana klienta zniknął, jak zmniejszyłem rozmiar ramki na tunelu poniżej 1200 (1196 dokładnie). Defaultowo robiło się 1496, co przekraczało maksymalny rozmiar ramki i nara).

    Poprawia się to tak,że do /etc/ppp/pptpd-options dodaje się opcje
    mtu 1490.

    I działa. Działa. Działa. Działa…. Zjadło mi to kilka dobrych godzin…

    UPDATE: 09-10-2011

    Jeżeli natomiast przy próbie pobrania poczty zrywa połączenie z VPNem, należy ramkę zmniejszyć jeszcze bardziej. Rekordowo małe MTU mam u pewnego problemowego klienta ustawione na 900. Inaczej próba pobrania poczty generuje jadowite pakiety, które kładą tunel.