Zezwalanie na SSH na serwerze z aktywnym klientem OpenVPN

Mam VPS z systemem CentOS 7, z którym łączę się za pomocą SSH. Chciałbym uruchomić klienta OpenVPN na VPS, aby ruch internetowy był kierowany przez VPN, ale nadal pozwalał mi łączyć się z serwerem przez SSH. Kiedy uruchamiam OpenVPN, moja sesja SSH zostaje rozłączona i nie mogę już połączyć się z moim VPS. Jak skonfigurować VPS, aby umożliwić przychodzące połączenia SSH (port 22), aby były otwarte na rzeczywistym adresie IP VPS (104.167.102.77), ale nadal kierowały ruch wychodzący (np. Z przeglądarki internetowej na VPS) przez VPN?

Używam usługi OpenVPN PrivateInternetAccess, a przykładowy plik config.ovpn to:

klient
dev tun
proto udp
zdalny nl.privateinternetaccess.com 1194
resolv-retry nieskończoność
nobind
trwały klucz
persist-tun
ca ca.crt
klient tls
serwer zdalnego certyfikatu tls
auth-user-pass
comp-lzo
czasownik 1
reneg-sec 0
crl-Verify crl.pem

Adres IP VPS:

1: lo: mtu 65536 qdisc stan noqueue NIEZNANY
    link / loopback 00: 00: 00: 00: 00: 00 brd 00: 00: 00: 00: 00: 00
    inet 127.0.0.1/8 zakres host lo
       valid_lft na zawsze preferowany_lft na zawsze
    Host inet6 :: 1/128
       valid_lft na zawsze preferowany_lft na zawsze
2: ens33: mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link / ether 00: 50: 56: be: 16: f7 brd ff: ff: ff: ff: ff: ff
    inet 104.167.102.77/24 brd 104.167.102.255 zakres globalny ens33
       valid_lft na zawsze preferowany_lft na zawsze
    inet6 fe80 :: 250: 56ff: febe: 16f7 / 64 link scope
       valid_lft na zawsze preferowany_lft na zawsze
4: tun0: mtu 1500 qdisc pfifo_fast stan NIEZNANY qlen 100
    link / none
    inet 10.172.1.6 peer 10.172.1.5/32 scope global tun0
       valid_lft na zawsze preferowany_lft na zawsze

Trasa ip VPS:

0.0.0.0/1 przez 10.172.1.5 dev tun 0
domyślnie poprzez 104.167.102.1 dev ens33 proto static metric 1024
10.172.1.1 via 10.172.1.5 dev tun 0
10.172.1.5 dev tun0 proto link do zakresu jądra src 10.172.1.6
104.167.102.0/24 dev ens33 proto kernel scope link src 104.167.102.77
109.201.154.177 via 104.167.102.1 dev ens33
128.0.0.0/1 przez 10.172.1.5 dev tun 0

Mam podobny problem i próbowałem naprawić opisany w tym poście na forum .

Chodzi o to, że obecnie, gdy łączysz się z publicznym adresem IP, pakiety zwrotne są kierowane przez VPN. Musisz wymusić, aby te pakiety były kierowane przez interfejs publiczny.

Mam nadzieję, że te polecenia trasy załatwią sprawę:

Dodaj regułę ip z tabeli xxxx 128

ip route dodaj tabelę 128 do rrrr / r dev ethX

ip route dodaj tabelę 128 domyślnie przez zzzz

Gdzie xxxx jest twoim publicznym adresem IP, rrrr / y powinno być podsiecią twojego publicznego adresu IP, ethX powinien być twoim publicznym interfejsem Ethernet, a zzzz powinien być domyślną bramą.

Zauważ, że to nie zadziałało dla mnie (używając Debiana i PrivateInternetAccess), ale może ci pomóc.

To może być trochę za późno, ale ...

Problem polega na tym, że brama domyślna zostaje zmieniona przez OpenVPN, i to przerywa twoje obecne połączenie SSH, chyba że skonfigurujesz odpowiednie trasy przed uruchomieniem OpenVPN.

To, co następuje, działa dla mnie. Wykorzystuje iptables i ip (iproute2). Poniżej zakłada się, że domyślnym interfejsem bramy przed uruchomieniem OpenVPN jest „eth0”. Chodzi o to, aby podczas nawiązywania połączenia z eth0, nawet jeśli eth0 nie był już domyślnym interfejsem bramy, pakiety odpowiedzi dla połączenia wracały ponownie do eth0.

Możesz użyć tego samego numeru dla znaku połączenia, znaku zapory i tablicy routingu. Użyłem różnych liczb, aby różnice między nimi były bardziej widoczne.

# set "connection" mark of connection from eth0 when first packet of connection arrives
sudo iptables -t mangle -A PREROUTING -i eth0 -m conntrack --ctstate NEW -j CONNMARK --set-mark 1234

# set "firewall" mark for response packets in connection with our connection mark
sudo iptables -t mangle -A OUTPUT -m connmark --mark 1234 -j MARK --set-mark 4321

# our routing table with eth0 as gateway interface
sudo ip route add default dev eth0 table 3412

# route packets with our firewall mark using our routing table
sudo ip rule add fwmark 4321 table 3412

===

AKTUALIZACJA:

Powyższe działa dobrze dla mnie w Debian Jessie. Ale w starszym systemie Wheezy właśnie odkryłem, że muszę dodać „via” do wpisu tablicy routingu:

# our routing table with eth0 as gateway interface
sudo ip route add default dev eth0 via 12.345.67.89 table 3412

Tam „12.345.67.89” musi być oryginalną bramą inną niż VPN.

Na podstawie odpowiedzi @MrK napisałem tutaj prosty kod, aby przyspieszyć wykonanie zadania, dzięki czemu nie musisz sprawdzać interfejsów / adresu IP:

ip rule add from $(ip route get 1 | grep -Po '(?<=src )(\S+)') table 128
ip route add table 128 to $(ip route get 1 | grep -Po '(?<=src )(\S+)')/32 dev $(ip -4 route ls | grep default | grep -Po '(?<=dev )(\S+)')
ip route add table 128 default via $(ip -4 route ls | grep default | grep -Po '(?<=via )(\S+)')

Wypróbowałem ten skrypt na 4 moich VPS i działa idealnie.

hmm wygląda na to, że podsieć ip nakłada się na siebie .... nie wiedząc więcej o twoim schemacie ip, innym niż publiczny ip dla twojej ternminacji VPN jako nl.privateinternetaccess.com, nie jest tego pewne.

na przykład jeśli zdalna podsieć po drugiej stronie nl.privateinternetaccess.com to 10.32.43.0/24, a Twoja instancja znajduje się w vs vpc, której podsieć to 10.32.44.0/24. ale twój źródłowy klient ssh żyje 10.32.43.0/24 (twoja strona aws vpc), to nie będzie działać, ponieważ ruch powrotny ssh będzie błędnie przekazywany przez vpn do Holandii.

podaj pełne informacje o adresie IP / podsieci, aby uzyskać dodatkową pomoc.

...

ok, więc ... wygląda na to, że twoja domyślna trasa jest w tunelu po podłączeniu do nl:

0.0.0.0/1 przez 10.172.1.5 dev tun 0

więc możesz to zmienić po połączeniu. wiele razy serwery VPN dają fałszywe trasy. szczególnie w niechlujnym korpusie. w tym przypadku pchają domyślną trasę do ciebie, więc cały ruch z vps box będzie nl. zmień domyślną trasę na 104.167.102.x lub inną bramę podsieci ur, która znajduje się u dostawcy vps.

Po uruchomieniu VPN twoja brama domyślna jest zastępowana. Oznacza to, że wszelki ruch generowany z twojego urządzenia lub kierowany przez niego będzie przekierowywany do bramy VPN.

Prostym rozwiązaniem jest odfiltrowanie całego ruchu, którego nie chcesz kierować przez VPN i zrobienie z nim czegoś innego. Jedną z możliwości jest odebranie ruchu generowanego z twojego urządzenia za pomocą lokalnego adresu źródłowego i skierowanie go przez lokalną bramę. Dzięki temu usługi takie jak SSH działają poprawnie.

Zrobimy to tutaj. Najpierw utwórz nową tabelę routingu i dodaj domyślną trasę, która trasuje wszystko przez bramę lokalną:

# <table> is any number between 2 and 252.
# Check /etc/iproute2/rt_tables for more info.
ip route add default via <gateway> table <table>
ip route add <lan-addr> dev <device> table <table>

Następnie utwórz nową regułę filtrowania pakietów, która oznaczy cały ruch wychodzący z twojego adresu źródłowego z pewnym identyfikatorem.

# <mark> is any number.
iptables -tmangle -AOUTPUT -s<local-addr> -jMARK --set-mark <mark>

Na koniec utwórz zasadę routingu, która zbiera cały wyżej zaznaczony ruch i kieruje go przy użyciu wygenerowanej tabeli powyżej.

ip rule add fwmark <mark> table <table>

Jeszcze raz wartości <mark>i <table>są dowolnymi identyfikatorami według własnego wyboru.

Dla mnie z uruchomieniem serwera OpenVPN w pfSense było odznaczenie ustawienia „Wymuś cały ruch IPv4 generowany przez klienta przez tunel”.