•  

    #ovh #linux #sysadmin #siecikomputerowe #openvpn

    Mirki, mam problem z failover-IP w OVH, pomożecie? Psuje mi OpenVPN...

    Pacjent: maszyna wirtualna Ubuntu 16.04 LTS z dwoma kartami sieciowymi, ens18 w podsieci lokalnej, ens19 z przybitym adresem publicznym zgodnie z instrukcją OVH. Do podsieci lokalnej jest dostęp z OpenVPN z adresu 10.8.0.0 - można wejść z niego na wszystkie maszyny i jest cacy.

    Problem pojawia się po włączeniu ens19 - tracę kontakt z podsiecią lokalną... bo na pingi, ssh i inne żądania puszczone z vpn-a odpowiada mi interfejs ens19 (publiczny). Wiadomo, odpowiada za to sposób w jaki OVH przekierowuje gateway (post-up route) ale po wywaleniu tego tracę dostęp do VM ze świata... Pomożecie?

    Konfiguracja VM (a: adres failover, b: adres hosta):
    `
    $vi /etc/network/interfaces
    auto ens18
    iface ens18 inet static
    address 192.168.0.10
    netmask 255.255.255.0
    network 192.168.0.0
    broadcast 192.168.0.255

    auto ens19
    iface ens19 inet static
    address a.a.a.a
    netmask 255.255.255.255
    network a.a.a.255
    broadcast a.a.a.a
    post-up route add b.b.b.254 dev ens19
    post-up route add default gw b.b.b.254

    dns-nameservers 8.8.8.8 8.8.4.4


    $ route -n
    Kernel IP routing table
    Destination Gateway Genmask Flags Metric Ref Use Iface
    0.0.0.0 b.b.b.254 0.0.0.0 UG 0 0 0 ens19
    b.b.b.254 0.0.0.0 255.255.255.255 UH 0 0 0 ens19
    192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 ens18
    `

    •  
      V.....2 via iOS

      +1

      @tylko_grzanki: ta maszyna to hostowana jest na dedyku? Public Cloud? No i pytanie czy odwrotna kolejność interfejsów nie wpływa na działanie routingu. Bujałem się z czymś podobnym u innego dostawcy. Musiałem wymusić routing a z czasem po prostu zmieniłem konfig wirtualki (zamieniłem kolejność interfejsów). Tak to co proponuje OVH nie powinno mieć wpływu na openvpna

    •  

      @Virgo92: Hostowana na dedyku z QEMU. Już podmieniam kolejność i patrzymy...

    •  
      V.....2 via iOS

      0

      @tylko_grzanki: nie daje Ci gwarancji ale takie jajca miałem z Linuchem :p oby pomogło

    •  

      @Virgo92: No niestety zamiana interface nie pomogła. Dalej to samo. Co ciekawe mam drugi serwer z analogiczną konfiguracją, configi kreska w kreskę identyczne - a działa. Czary :/

    •  
      V.....2 via iOS

      0

      @tylko_grzanki: a przenieś tamta maszynę na ten serwer i zobacz czy po zmianie adresacji się krzyczy. Tak wyeliminujesz soft albo operatora :p

    •  
      V.....2 via iOS

      0

      @tylko_grzanki: Hmm. A czy ovpn cośkolwiek loguje?

    •  
      V.....2 via iOS

      0

      No i debuguj przez novnc ;)

    •  
      l.....2

      +2

      Komentarz usunięty przez autora

    •  

      @Virgo92: nic, brak pakietów zwrotnych. Sprawdzałem tcpdump i lecą na drugi interface na inną podsieć, więc openvpn nie ma szans nic zalogować.

    •  

      @lis6502: to konfiguracja zalecana przez OVH, zaraz zobaczę czy wywalenie default coś da

    •  

      @lis6502: Kiszka. Po wywaleniu default IP przestaje być widoczne ze świata a serwer przestaje widzieć adresy publiczne.

    •  
      l.....2

      0

      Komentarz usunięty przez autora

    •  

      @lis6502: Kernel IP routing table
      Destination Gateway Genmask Flags Metric Ref Use Iface
      b.b.b.254 0.0.0.0 255.255.255.255 UH 0 0 0 ens19
      192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 ens18

      sęk w tym że VM nie jest widoczna ze świata w tym układzie. z openvpn rzecz jasna też.
      Wchodzę na nią pośrednio z innej wirtualki.

    •  
      l.....2

      +1

      Komentarz usunięty przez autora

    •  

      @lis6502: Próbowałem też tego i kiszka; nie pomaga, ze świata go nie widać ale VPN łapie. Coś mi się wydaje, że jedynym wyjściem jest jakiś magiczny wpis w iptables a w tej materii niestety zbyt mocny nie jestem.

      Tak nawiasem te cholerne ens-y to aliasy i można je zablokować w confie GRUB-a:
      GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0"
      ale i tak pół świata tego dziadostwa używa więc trzeba przywyknąć :/

      b.b.b.b dlatego, że to publiczne IP mojego hosta ;)

    •  
      l.....2

      0

      Komentarz usunięty przez autora

    •  

      @lis6502: Po kolei;
      serwer vpn jest na innej maszynie; daje adresację 10.8.0.0/24 i natuje się z masqaradą ze swojego ip 192.168.0.1 na podsieć 192.168.0.0/24 - i hula to ładnie i bezproblemowo na wszystkich maszynach poza tą, która ma dwa interface. Jak podniesiony jest tylko jej lokalny interface ens18 z adresem 192.168.0.10 wszystko jest cacy, ssh-uję się na niego z peceta przez VPN i z innych maszyn.
      Jak podniosę ens19 z tą pochrzanioną bramą od OVH - z innych maszyn w podsieci mogę się połączyć ale bezpośrednio z peceta po vpn już nie; tcpdump zeznaje, że ssh odpowiada zamiast na ens18 na ens19.

    •  
      l.....2

      0

      Komentarz usunięty przez autora

    •  

      @lis6502: tak, dokładnie. To tun ma podsieć 10.8.0.0/24 i ona jest natowana na 192.168.0.0/24 pozostałych maszyn.
      Z tym że VPN jest na innej wirtualce, nie na tej z którą jest problem.

    •  
      l.....2

      0

      Komentarz usunięty przez autora

    •  

      Tak też mi się wydaje @lis6502 problem dotyczy tylko tego co wylata z nata.

      ifconfig problematycznej witrualki:
      `ens18 Link encap:Ethernet HWaddr MAC_CIACH
      inet addr:192.168.0.10 Bcast:192.168.0.255 Mask:255.255.255.0
      UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
      RX packets:445773 errors:45 dropped:0 overruns:0 frame:45
      TX packets:261014 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:1000
      RX bytes:55444652 (55.4 MB) TX bytes:31638022 (31.6 MB)

      ens19 Link encap:Ethernet HWaddr MAC_CIACH
      inet addr:A.A.A.A Bcast:A.A.A.A Mask:255.255.255.255
      UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
      RX packets:417102 errors:0 dropped:0 overruns:0 frame:0
      TX packets:11946 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:1000
      RX bytes:26596713 (26.5 MB) TX bytes:742066 (742.0 KB)

      lo Link encap:Local Loopback
      inet addr:127.0.0.1 Mask:255.0.0.0
      UP LOOPBACK RUNNING MTU:65536 Metric:1
      RX packets:2455 errors:0 dropped:0 overruns:0 frame:0
      TX packets:2455 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:1
      RX bytes:1600498 (1.6 MB) TX bytes:1600498 (1.6 MB)`

    •  

      Maskowanie: A.A.A.A i Z.Z.Z.Z - ip faliover of OVH, Y.Y.Y.Y - ip publiczne hosta.

      Instrukcja OVH jak wypuścić na świat failover IP

      ifconfig virtualki dającej VPNa:
      `ens18 Link encap:Ethernet HWaddr MAC_CIACH
      inet addr:Z.Z.Z.Z Bcast:Z.Z.Z.Z Mask:255.255.255.255
      UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
      RX packets:1060700 errors:0 dropped:0 overruns:0 frame:0
      TX packets:37381 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:1000
      RX bytes:68664307 (68.6 MB) TX bytes:3132253 (3.1 MB)

      ens19 Link encap:Ethernet HWaddr MAC_CIACH
      inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0
      UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
      RX packets:491619 errors:0 dropped:0 overruns:0 frame:0
      TX packets:7347 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:1000
      RX bytes:289562411 (289.5 MB) TX bytes:686847 (686.8 KB)

      lo Link encap:Local Loopback
      inet addr:127.0.0.1 Mask:255.0.0.0
      UP LOOPBACK RUNNING MTU:65536 Metric:1
      RX packets:160 errors:0 dropped:0 overruns:0 frame:0
      TX packets:160 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:1
      RX bytes:11840 (11.8 KB) TX bytes:11840 (11.8 KB)

      tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
      inet addr:10.8.0.1 P-t-P:10.8.0.2 Mask:255.255.255.255
      UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
      RX packets:4715 errors:0 dropped:0 overruns:0 frame:0
      TX packets:3490 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:100
      RX bytes:379276 (379.2 KB) TX bytes:610371 (610.3 KB)`

      i jeszcze route -n z VPNa

      Destination Gateway Genmask Flags Metric Ref Use Iface
      0.0.0.0 Y.Y.Y.254 0.0.0.0 UG 0 0 0 ens18
      10.8.0.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0
      10.8.0.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
      Z.Z.Z.Z.254 0.0.0.0 255.255.255.255 UH 0 0 0 ens18
      192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 ens19

    •  

      Komentarz usunięty przez autora

    •  

      Komentarz usunięty przez autora

    •  

      @lis6502: Nie, na innej, 192.168.0.1. dedykowanej dla VPN. Problematyczna to 192.168.0.10

    •  

      Komentarz usunięty przez autora

    •  
      l.....2

      0

      Komentarz usunięty przez autora

    •  

      @lis6502: Jasne i tak jestem Ci wdzięczny że poświęcasz czas...
      Zmiana a w zasadzie - natowanie odbywa się na maszynie VPN-a za pomocą iptables:
      `iptables -L
      Chain INPUT (policy ACCEPT)
      target prot opt source destination

      Chain FORWARD (policy ACCEPT)
      target prot opt source destination
      ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
      all -- 10.8.0.0/24 192.168.0.1`

    •  
      l.....2

      0

      Komentarz usunięty przez autora

    •  

      @lis6502: OK, po kolei:
      traceroute -n onet.pl na maszynie z problemem przy wyłączonym failover IP
      iptables -t nat --list na maszynie z VPN

      Interfejsy obu maszyn widzą się bez problemu, działa wszystko jak trzeba. Problem jest tylko z nawiązaniem połączenia czymkowiek (w tym ICMP) z peceta via VPN.

      (wrzucam na pastebin, bo wykopowe formatowanie kodu to porażka)

    •  
      l.....2

      0

      Komentarz usunięty przez autora

    •  

      @lis6502: Zrobiłem obrazek by łatwiej było ogarnąć

      Problem sprawia maszyna B. Jak jej podniosę interface na świat - tracę połączenie z PC via VPN. Maszyny VPN, A i B nadal się widzą po podsieci 192.168.0.0/24. Tcpdump pokazuje, że pakiety wysłane z PC nie wracają odwrotną trasą a próbują wyjść na świat przez failover IP. Jednocześnie wszystkie inne usługi na maszynie B działają jak trzeba.

    •  
      l.....2

      0

      Komentarz usunięty przez autora

    •  

      @lis6502: już kilka dni grzeję sobie nad tym zwoje szczerze mówiąc, próbowałem nawet przejść na Ubuntu LTE 18.x ale problem idzie za mną jak cień :/ W sumie mogę wystawić SSH na adresie publicznym ale to cholernie nieeleganckie...

      Zaraz spróbuję sposobu z metryką i dam cynk czy zadziałało

    •  
      l.....2

      0

      Komentarz usunięty przez autora

    •  

      @tylko_grzanki: a tcpdump pokazuje ze maskarada dziala poprawnie i ruch ktory przychodzi do openvpn jest natowany na interfejs w sieci 192.168.0.0/24? Możesz w ogóle w jednym poście zebrać całość informacji:
      1) VPN VM:
      a) zawartość z /etc/network/interfaces lub interfaces.d/interfejsy
      b) # ip r
      c) # iptables-save
      d) # tcpdump -n -l -i any -c 10 host 192.168.0.10 (zakładam że to ipek failover VM)
      2) Failover VM:
      a) zawartość z /etc/network/interfaces lub interfaces.d/interfejsy
      b) # ip r
      c) # iptables-save
      d) # tcpdump -n -l -i any -c 10 host <nie wiem jaki jest ipek VPN vmki>

      Moim zdaniem jest problem z maskaradą, bo patrząc na tablicę routingu w pierwszym poście to ruch powinien wracać tędy:
      192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 ens18
      jeśli został poprawnie znatowany. Tablice rutingu działają na zasadzie najlepszego dopasowania 192.168.0.0/24 jest bardziej dopasowaną regułką niż 0.0.0.0/0

    •  

      @flor4s: Całość info w jednym pliku

      @lis6502: spoko, zawsze zapewniam sobie dostęp do tty zanim odetnę ssh. Najgorszy wstyd to dzwonić do providera że straciło się kontakt z maszyną....

    •  

      @tylko_grzanki: Dodaj na maszynie VM:
      -A POSTROUTING -s 10.0.8.0/24 -o ens19 -j MASQUERADE
      do tego wydaje mi sie ze ta linijka jest do usuniecia:
      -A POSTROUTING -s 192.168.0.0/24 -o ens19 -j MASQUERADE

      Po tych zmianach powinno działać. Możesz to też zrobić bez maskarady. Wtedy na maszynie B bym dodał do interfaces sekcji ens18:
      up route add -net 10.0.8.0 netmask 255.255.255.0 gw 192.168.0.1
      Albo w ramach szybkiego testu ręcznie wpis w tablicy rutingu:
      ip r a 10.0.8.0/24 via 192.168.0.1

      Pierwsza metoda ukrywa sieć VPNową za NATem, druga "rozgłasza" sieć VPNową przez twoją wewnętrzną sieć 192.168.0.0/24

      +: tylko_grzanki, l.....2
    •  

      Możesz dodać na maszynie VM:
      -A POSTROUTING -s 10.0.8.0/24 -o ens19 -j MASQUERADE
      do tego wydaje mi sie ze ta linijka jest do usuniecia:
      -A POSTROUTING -s 192.168.0.0/24 -o ens19 -j MASQUERADE


      @flor4s: Dzięki Mirku, działa jak złoto! Szukałem problemu zupełnie gdzie indziej a leżał pod nosem... Jak mówiłem iptables nie są moją mocną stroną i dopiero teraz widzę, że to logiczne i nie miało jak działać ( ͡° ͜ʖ ͡°)

    •  

      @tylko_grzanki: Spoko, iptables wymaga trochę otrzaskania się bo na początku nie jest specjalnie przejrzyste. Dużo łatwiej też polegać na iptables-save bo widzisz interfejsy, a iptables -L tego nie pokazuje.

      +: tylko_grzanki, l.....2
    •  

      Komentarz usunięty przez autora

    •  

      @lis6502: Są dwie różne metody rozwiązania tego problemu. Pierwsza metoda czyli zmiana w regułkach iptables spowoduje że sieć 10.8.0.0/24 będzie ukryta. U @tylko_grzanki regułki te były błędne dlatego sieć nie była ukryta co potwierdził tcpdump jaki załączył.
      Druga metoda zakłada, że nie ukrywamy sieci - czyli stan początkowy OPa. W takim wypadku musimy zapewnić trasę powrotną z maszynki B inną niż default - wtedy dodajemy trasę rutingu którą wspomniałeś. To są dwie różne metody rozwiązania problemu, a nie jedna składająca się z dwóch kroków.

      Oba rozwiązania bez problemu działają, pierwsze (czyli poprawiamy NATowanie i ukrywamy sieć) powoduje, że ograniczamy ilość połączeń jakie możemy przepuścić przez VPN do ilości wolnych portów na serwerze (no bo NAT) oraz dodatkowo dokładamy jakieś tam obciążanie tego serwera (mimo wszystko NAT coś zasobów zużywa). Nie jest to problemem na skalę dwóch maszyn naturalnie.
      Drugie rozwiązanie zakłada brak NATa. Zaletą jest brak wrzucania dodatkowego obciążenia na serwer, a wadą że na każdej VMce która ma być osiągalna przez VPN trzeba dodać trasę zwrotną do sieci VPN. Problem dodawania trasy powrotnej można rozwiązać narzędziami typu puppet, ansible etc. Bądź na każdym serwerze zainstalować coś odpowiedzialnego za routing - np quagga. Odpalić dynamiczny protokół routingu i w ten sposób rozgłaszać sieć VPN. Moglibyśmy to uznać za trzecią metodę rozwiązania problemu.
      Maskarada czyli NAT na koncentratorze VPN jest najprostszym i najlepszym rozwiązaniem tutaj, ja podrzuciłem też inne opcje, żeby lepiej pokazać z czego wynika problem. Jest to routing asymetryczny, który rozwiązujemy zapewniając aby trasa powrotna szła w ten sam sposób w jaki pakiet do nas dotarł. Czyli albo robiąc nata, albo ręcznie wpisując trasę powrotną do tablicy routingu hosta B.

      Najłatwiej zrozumieć istotę problemu poprzez rysunek i nałożenie na rysunek jak będzie przebiegać ruch pakietu. Trzeba tylko pamiętać, że regułki iptables były na początku błędne więc ruch do maszyny B przychodził z adresacji 10.8.0.0/24

      +: tylko_grzanki, l.....2
    •  

      @flor4s: W tym konkretnym wypadku ograniczenie połączeń nie ma znaczenia; VPN używany jest wyłącznie do zarządzania maszynami z poziomu powłoki, aktualizacji itd.

      Dzięki za obszerne wyjaśnienie, może jeszcze komuś w podobnej sytuacji się przyda.

Gorące dyskusje ostatnie 12h

  • avatar

    Życie życie jest nobelom

    #przegryw #stulejacontent #takbylo #heheszki #pdk #zalesie

    odpowiedzi (6)

  • avatar

    Interesuje Was #ama z policjantem pracującym w wydziale zabójstw w Warszawie? Mającym do czynienia z naprawdę brutalnymi przypadkami.
    #pytanie #warszawa

    odpowiedzi (55)

  • avatar

    Biały eko faszysta przeprowadza zamach w NZ na meczety. Ginie 50 osób. Cały świat w żałobie, pseudo gwiazdki płaczą na twitterach i instagramach, obwiniaja za zamach białych prawaków(mimo, że manifest mówi jasno i wyraźnie jakie poglądy miał Tarrant).

    Islamiści ze Sri Lanki przeprowadzają zamach na kilka celów jednocześnie. Ginie 321 osób. Reakcja świata? Meh. Kogo katole obchodzą XD
    easter worshippers XD

    Lewica jest obrzydliwa. Dzieli ludzi na gorszych i lepszych. Można odnieść wrażenie, że marzy im się pewna segregacja ze względu na poglądy czy wiarę.

    Nie chodzi mi tylko o te ataki.
    Spójrzmy co się dzieje na amerykańskich uniwersytetach gdzie na wykłady zapraszani są różni mówcy. Ale to tylko gdy pojawiają się prawicowcy zaczynają się awantury i blokowanie sal. Ben Shapiro(żyd swoją drogą) Milo(homoś) Kirk, Molyneux, Peterson i nawet ostatnio Legutko są blokowani i nie dopuszczani do młodzieży bo jeszcze przypadkiem młodzież zobaczy, że komunizm nie jest jedyną właściwą drogą. Identyczna sytuacja jest w UK gdzie ostatnio Bosak musiał wynajmować sale od masonerii po tym jak lewactwo ich blokowało XD Korwin z rok temu musiał zorganizować spotkanie na świeżym powietrzu bo lewactwo kwiczało. W Londynie odwołano targi książki prawicowej i wiele innych rzeczy..

    Lewica i tolerancja... Wszystkim się wydaje, że powinno to iść w parze niestety jest zupełnie inaczej. Masz inne poglądy? Będziesz ponosił tego konsekwencje i będziesz spychany na margines.

    #bekazlewactwa #4konserwy #neuropa.ru #islam
    pokaż całość

    odpowiedzi (33)