Cho phép SSH trên máy chủ có ứng dụng khách OpenVPN đang hoạt động

Tôi có một VPS chạy CentOS 7 mà tôi kết nối với SSH. Tôi muốn chạy ứng dụng khách OpenVPN trên VPS để lưu lượng truy cập internet được định tuyến qua VPN, nhưng vẫn cho phép tôi kết nối với máy chủ qua SSH. Khi tôi khởi động OpenVPN, phiên SSH của tôi bị ngắt kết nối và tôi không thể kết nối với VPS nữa. Làm cách nào tôi có thể định cấu hình VPS để cho phép các kết nối SSH (cổng 22) đến được mở trên IP thực tế của VPS (104.167.102.77), nhưng vẫn định tuyến lưu lượng đi (như từ trình duyệt web trên VPS) thông qua VPN?

Dịch vụ OpenVPN mà tôi sử dụng là PrivateINETAccess và một tệp config.ovpn mẫu là:

khách hàng
nhà phát triển
proto udp
từ xa nl.privateiNETaccess.com 1194
độ phân giải-thử lại vô hạn
quý tộc
khóa liên tục
kiên trì
ca ca.crt
khách hàng
máy chủ cert-tls
auth-user-pass
comp-lzo
động từ 1
đổi mới 0 giây
crl-xác minh crl.pem

Địa chỉ ip của VPS:

1: lo: mtu 65536 qdisc noqueue state UNKNOWN
    liên kết / loopback 00: 00: 00: 00: 00 brd 00: 00: 00: 00: 00: 00
    inet 127.0.0.1/8 phạm vi máy chủ lo
       valid_lft mãi mãi ưa thích_lft mãi mãi
    inet6 :: máy chủ phạm vi 1/128
       valid_lft mãi mãi ưa thích_lft mãi mãi
2: ske33: mtu 1500 qdisc pfifo_fast state UP qlen 1000
    liên kết / 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 phạm vi toàn cầu33
       valid_lft mãi mãi ưa thích_lft mãi mãi
    inet6 fe80 :: 250: 56ff: febe: 16f7 / 64 phạm vi liên kết
       valid_lft mãi mãi ưa thích_lft mãi mãi
4: tun0: mtu 1500 qdisc pfifo_fast trạng thái UNKNOWN qlen 100
    liên kết / không
    inet 10.172.1.6 ngang hàng 10.172.1.5/32 phạm vi toàn cầu tun0
       valid_lft mãi mãi ưa thích_lft mãi mãi

Lộ trình ip của VPS:

0.0.0.0/1 qua 10.172.1.5 dev tun0
mặc định thông qua 104.167.102.1 dev ske33 proto tĩnh số liệu 1024
10.172.1.1 qua 10.172.1.5 dev tun0
10.172.1.5 dev tun0 proto kernel scope link src 10.172.1.6
104.167.102.0/24 dev obl33 proto kernel scope scope src 104.167.102.77
109.201.154.177 qua 104.167.102.1 dev obl33
128.0.0.0/1 qua 10.172.1.5 dev tun0

Tôi đang gặp vấn đề tương tự như vậy và đã cố gắng khắc phục được mô tả trong bài đăng trên diễn đàn này .

Ý tưởng là hiện tại khi bạn kết nối với địa chỉ IP công cộng của mình, các gói trả về đang được định tuyến qua VPN. Bạn cần buộc các gói này được định tuyến qua giao diện công cộng của bạn.

Những lệnh tuyến này hy vọng sẽ thực hiện được mẹo:

quy tắc ip thêm từ bảng xxxx 128

tuyến ip thêm bảng 128 vào yyyy / y dev ethX

lộ trình ip thêm bảng 128 mặc định qua zzzz

Trong đó xxxx là IP công cộng của bạn, yyyy / y phải là mạng con của địa chỉ IP công cộng của bạn, ethX phải là giao diện Ethernet công cộng của bạn và zzzz phải là cổng mặc định.

Lưu ý rằng điều này không hiệu quả với tôi (sử dụng Debian và PrivateINETAccess) nhưng có thể giúp bạn giải quyết.

Điều này có thể hơi muộn, nhưng ...

Vấn đề là cổng mặc định bị OpenVPN thay đổi và phá vỡ kết nối SSH hiện tại của bạn trừ khi bạn thiết lập các tuyến thích hợp trước khi bạn khởi động OpenVPN.

Điều gì sau đây làm việc cho tôi. Nó sử dụng iptables và ip (iproute2). Dưới đây, giả định rằng giao diện cổng mặc định trước khi OpenVPN được khởi động là "eth0". Ý tưởng là để đảm bảo rằng khi kết nối với eth0 được thực hiện, ngay cả khi eth0 không còn là giao diện cổng mặc định nữa, các gói phản hồi cho kết nối sẽ quay trở lại eth0.

Bạn có thể sử dụng cùng một số cho dấu kết nối, dấu tường lửa và bảng định tuyến. Tôi đã sử dụng các số riêng biệt để làm cho sự khác biệt giữa chúng rõ ràng hơn.

# 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

===

CẬP NHẬT:

Những điều trên hoạt động tốt với tôi trên Debian Jessie. Nhưng trên một hệ thống Wheezy cũ hơn, tôi vừa thấy rằng tôi cần thêm "thông qua" vào mục nhập bảng định tuyến:

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

Có "12.345.67.89" phải là cổng không phải VPN gốc.

Dựa trên câu trả lời @MrK, tôi đã viết một số mã đơn giản ở đây để thực hiện công việc nhanh hơn để bạn không phải kiểm tra giao diện / 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+)')

Tôi đã thử tập lệnh này trên 4 VPS của tôi và nó hoạt động hoàn hảo.

hmm âm thanh giống như mạng con ip trùng lặp .... mà không biết thêm về sơ đồ ip của bạn, ngoài ip công khai cho ternmination vpn của bạn như nl.privateiNETaccess.com, không thể chắc chắn.

vì vậy, ví dụ, nếu mạng con từ xa ở phía bên kia của nl.privateiNETaccess.com là 10.32.43.0/24 và phiên bản của bạn nằm trong một vpc aws có mạng con là 10.32.44.0/24. nhưng máy khách ssh nguồn của bạn tồn tại vào ngày 10.32.43.0/24 (phía bạn của aws vpc), nó sẽ không hoạt động, vì lưu lượng truy cập ssh trở lại sẽ bị đẩy nhầm qua vpn đến hà lan.

cung cấp thông tin ip / subnet đầy đủ để được trợ giúp thêm về điều này.

...

ok, vì vậy ... có vẻ như tuyến đường mặc định của bạn nằm trong đường hầm, sau khi bạn kết nối với nl:

0.0.0.0/1 qua 10.172.1.5 dev tun0

để bạn có thể thay đổi điều đó sau khi bạn kết nối. rất nhiều lần máy chủ vpn cung cấp cho bạn các tuyến không có thật. đặc biệt tại quân đoàn cẩu thả. trong trường hợp này, họ đang đẩy một tuyến mặc định cho bạn để tất cả lưu lượng truy cập từ hộp vps sẽ chuyển sang nl. thay đổi tuyến mặc định thành 104.167.102.x hoặc bất kỳ cổng mạng con nào của bạn tại nhà cung cấp ur vps.

Khi bạn đưa VPN lên, cổng mặc định của bạn sẽ được thay thế. Điều này có nghĩa là bất kỳ lưu lượng truy cập nào được tạo từ hoặc định tuyến qua hộp của bạn sẽ được chuyển tiếp đến cổng VPN.

Một giải pháp đơn giản là lọc tất cả lưu lượng truy cập mà bạn không muốn định tuyến qua VPN và làm một cái gì đó khác với nó. Một khả năng là chọn lưu lượng truy cập được tạo từ hộp của bạn bằng địa chỉ nguồn cục bộ của bạn và định tuyến nó qua cổng cục bộ của bạn. Điều này cho phép các dịch vụ như SSH hoạt động đúng.

Chúng tôi sẽ làm điều đó ở đây. Đầu tiên, tạo một bảng định tuyến mới và thêm một tuyến mặc định định tuyến mọi thứ thông qua cổng cục bộ của bạn:

# <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>

Tiếp theo, tạo quy tắc bộ lọc gói mới đánh dấu tất cả lưu lượng truy cập rời khỏi hộp của bạn từ một địa chỉ nguồn nhất định với một số định danh.

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

Cuối cùng, tạo một chính sách định tuyến chọn tất cả lưu lượng truy cập được đánh dấu đã nói ở trên và định tuyến nó bằng bảng được tạo ở trên.

ip rule add fwmark <mark> table <table>

Một lần nữa, các giá trị <mark>và <table>là định danh tùy ý của sự lựa chọn của riêng bạn.

Đối với tôi, việc tự chạy máy chủ OpenVPN trong pfSense là bỏ chọn cài đặt "Buộc tất cả lưu lượng truy cập IPv4 do khách hàng tạo qua đường hầm."