[tylko_grzanki]

#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

[tylko_grzanki]

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

[tylko_grzanki]

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

[tylko_grzanki]

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

[tylko_grzanki]

@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

[tylko_grzanki]

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

[tylko_grzanki]

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

[tylko_grzanki]

@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

[flor4s]

@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

[tylko_grzanki]

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

[flor4s]

@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

[tylko_grzanki]

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ć ( ͡° ͜