การอนุญาต SSH บนเซิร์ฟเวอร์ที่มีไคลเอนต์ OpenVPN ที่ใช้งานอยู่

ฉันมี VPS ที่รัน CentOS 7 ที่ฉันเชื่อมต่อกับ SSH ฉันต้องการเรียกใช้ไคลเอนต์ OpenVPN บน VPS เพื่อให้ปริมาณการใช้งานอินเทอร์เน็ตถูกส่งผ่าน VPN แต่ยังอนุญาตให้ฉันเชื่อมต่อกับเซิร์ฟเวอร์ผ่าน SSH เมื่อฉันเริ่ม OpenVPN เซสชัน SSH ของฉันจะถูกตัดการเชื่อมต่อและฉันไม่สามารถเชื่อมต่อกับ VPS ได้อีกต่อไป ฉันจะกำหนดค่า VPS เพื่ออนุญาตให้เปิดการเชื่อมต่อ SSH (พอร์ต 22) บน IP จริงของ VPS (104.167.102.77) ได้อย่างไร แต่ยังคงกำหนดเส้นทางทราฟฟิกขาออก (เช่นจากเว็บเบราว์เซอร์บน VPS) ผ่าน VPN

บริการ OpenVPN ที่ฉันใช้คือ PrivateInternetAccess และตัวอย่างไฟล์ config.ovpn คือ:

ลูกค้า
dev tun
proto udp
remote nl.privateinternetaccess.com 1194
resolv-retry อนันต์
nobind
ยังคงมีอยู่ที่สำคัญ
ยังคงมีอยู่-TUN
ca ca.crt
TLS-ลูกค้า
เซิร์ฟเวอร์ remote-cert-tls
รับรองความถูกต้องของผู้ใช้ผ่าน
comp-LZO
กริยา 1
reneg-sec 0
crl- ตรวจสอบ crl.pem

ip addr ของ VPS:

1: lo: mtu 65536 qdisc noqueue state UNKNOWN
    ลิงก์ / ลูปแบ็ค 00: 00: 00: 00: 00: 00 brd 00: 00: 00: 00: 00: 00
    inet 127.0.0.1/8 ขอบเขตโฮสต์แท้จริง
       valid_lft ตลอดกาล Preferred_lft ตลอดกาล
    inet6 :: โฮสต์ขอบเขต 1/128
       valid_lft ตลอดกาล Preferred_lft ตลอดกาล
2: ens33: mtu 1,500 qdisc pfifo_fast สถานะ up qlen 1000
    ลิงค์ / อีเธอร์ 00: 50: 56: เป็น: 16: f7 brd ff: ff: ff: ff: ff: ff
    inet 104.167.102.77/24 brd 104.167.102.255 ขอบเขต global ens33
       valid_lft ตลอดกาล Preferred_lft ตลอดกาล
    inet6 fe80 :: 250: 56ff: febe: 16f7 / 64 การเชื่อมโยงขอบเขต
       valid_lft ตลอดกาล Preferred_lft ตลอดกาล
4: tun0: mtu 1500 qdisc pfifo_fast สถานะ UNKNOWN qlen 100
    การเชื่อมโยง / ไม่มี
    inet 10.172.1.6 เพียร์ 10.172.1.5/32 ขอบเขตส่วนกลาง tun0
       valid_lft ตลอดกาล Preferred_lft ตลอดกาล

เส้นทาง IP ของ VPS:

0.0.0.0/1 ผ่าน 10.172.1.5 dev tun0
ค่าเริ่มต้นผ่าน 104.167.102.1 dev ens33 ตัวชี้วัดแบบคงที่ 1024
10.172.1.1 ผ่าน 10.172.1.5 dev tun0
10.172.1.5 dev tun0 การเชื่อมโยงเคอร์เนลขอบเขต src 10.172.1.6
104.167.102.0/24 dev ens33 การเชื่อมโยงขอบเขตเคอร์เนลโปรโต src 104.167.102.77
109.201.154.177 ผ่าน 104.167.102.1 dev ens33
128.0.0.0/1 ผ่าน 10.172.1.5 dev tun0

ฉันมีปัญหาที่คล้ายกันนี้และพยายามแก้ไขที่อธิบายไว้ในโพสต์ฟอรัมนี้

แนวคิดคือในปัจจุบันเมื่อคุณเชื่อมต่อกับที่อยู่ IP สาธารณะของคุณแพ็กเก็ตส่งคืนจะถูกกำหนดเส้นทางผ่าน VPN คุณต้องบังคับให้แพ็กเก็ตเหล่านี้ถูกกำหนดเส้นทางผ่านส่วนต่อประสานสาธารณะ

คำสั่งเส้นทางเหล่านี้หวังว่าจะทำเคล็ดลับ:

กฎ ip เพิ่มจาก xxxx ตาราง 128

เส้นทาง ip เพิ่มตาราง 128 ถึง yyyy / y dev ethX

เส้นทาง ip เพิ่มตาราง 128 เริ่มต้นผ่านทาง zzzz

โดยที่ xxxx คือ IP สาธารณะของคุณ, yyyy / y ควรเป็นซับเน็ตของที่อยู่ IP สาธารณะของคุณ, ethX ควรเป็นอินเตอร์เฟสอีเทอร์เน็ตสาธารณะของคุณ, และ zzzz ควรเป็นเกตเวย์เริ่มต้น

โปรดทราบว่าสิ่งนี้ไม่ได้ผลสำหรับฉัน (โดยใช้ Debian และ PrivateInternetAccess) แต่อาจช่วยคุณได้

อาจจะช้าไปหน่อย แต่ ...

ปัญหาคือเกตเวย์เริ่มต้นได้รับการเปลี่ยนแปลงโดย OpenVPN และทำให้การเชื่อมต่อ SSH ปัจจุบันของคุณหยุดชะงักเว้นแต่คุณจะตั้งค่าเส้นทางที่เหมาะสมก่อนที่คุณจะเริ่ม OpenVPN

สิ่งต่อไปนี้ใช้ได้ผลสำหรับฉัน มันใช้ iptables และ ip (iproute2) ด้านล่างจะถือว่าอินเตอร์เฟสเกตเวย์เริ่มต้นก่อนที่จะเริ่ม OpenVPN คือ "eth0" แนวคิดคือเพื่อให้แน่ใจว่าเมื่อทำการเชื่อมต่อกับ eth0 แม้ว่า eth0 จะไม่ใช่เกตเวย์เริ่มต้นอินเตอร์เฟสอีกต่อไปแพ็กเก็ตตอบกลับสำหรับการเชื่อมต่อจะกลับไปที่ eth0 อีกครั้ง

คุณสามารถใช้หมายเลขเดียวกันสำหรับเครื่องหมายการเชื่อมต่อเครื่องหมายไฟร์วอลล์และตารางเส้นทาง ฉันใช้ตัวเลขที่แตกต่างเพื่อทำให้ความแตกต่างระหว่างพวกเขาชัดเจนยิ่งขึ้น

# 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

===

UPDATE:

ผลงานดังกล่าวดีสำหรับฉันใน Debian Jessie แต่ในระบบ Wheezy ที่เก่ากว่าฉันเพิ่งพบว่าฉันต้องเพิ่ม "ผ่าน" ลงในรายการตารางเส้นทาง:

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

มี "12.345.67.89" ต้องเป็นเกตเวย์ที่ไม่ใช่ VPN ดั้งเดิม

จากคำตอบ @MrK ฉันได้เขียนโค้ดง่าย ๆ ที่นี่เพื่อให้ทำงานได้เร็วขึ้นคุณจึงไม่ต้องตรวจสอบอินเตอร์เฟส / 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+)')

ฉันได้ลองใช้สคริปต์นี้ใน VPS ของฉันแล้วและทำงานได้อย่างสมบูรณ์

อืมดูเหมือนว่า ip subnet ทับซ้อน .... โดยที่ไม่รู้เพิ่มเติมเกี่ยวกับรูปแบบไอพีของคุณนอกเหนือจากไอพีสาธารณะสำหรับ ternmination vpn ของคุณเป็น nl.privateinternetaccess.com ไม่สามารถบอกได้อย่างแน่นอน

ตัวอย่างเช่นถ้ารีโมตซับเน็ตบนอีกด้านหนึ่งของ nl.privateinternetaccess.com คือ 10.32.43.0/24 และอินสแตนซ์ของคุณอยู่ใน aws vpc ซึ่งซับเน็ตคือ 10.32.44.0/24 แต่ไคลเอ็นต์ ssh ต้นทางของคุณใช้งานอยู่ที่ 10.32.43.0/24 (ด้านข้างของ aws vpc ของคุณ) มันจะไม่ทำงานเนื่องจากการรับส่งข้อมูล ssh กลับจะถูกผลักดันอย่างผิดพลาดมากกว่า VPN ไปยังเนเธอร์แลนด์

ให้ข้อมูลเต็ม ip / subnet เพื่อรับความช่วยเหลือเพิ่มเติม

...

ตกลงดังนั้น ... ดูเหมือนว่าเส้นทางเริ่มต้นของคุณจะอยู่ในอุโมงค์หลังจากที่คุณเชื่อมต่อกับ nl:

0.0.0.0/1 ผ่าน 10.172.1.5 dev tun0

เพื่อให้คุณสามารถเปลี่ยนได้หลังจากที่คุณเชื่อมต่อ เซิร์ฟเวอร์ VPN หลายครั้งให้เส้นทางปลอมแก่คุณ พิเศษที่กองพลน้อยที่เลอะเทอะ ในกรณีนี้พวกเขากำลังผลักดันเส้นทางเริ่มต้นให้กับคุณดังนั้นทราฟฟิกทั้งหมดจากกล่อง vps จะไปที่ nl เปลี่ยนเส้นทางเริ่มต้นเป็น 104.167.102.x หรืออะไรก็ตามเกตเวย์ซับเน็ตของคุณอยู่ที่ผู้ให้บริการ vps ของคุณ

เมื่อคุณนำ VPN ขึ้นเกตเวย์เริ่มต้นของคุณจะถูกแทนที่ ซึ่งหมายความว่าการรับส่งข้อมูลใด ๆ ที่สร้างขึ้นหรือส่งผ่านกล่องของคุณจะถูกส่งต่อไปยังเกตเวย์ VPN

ทางออกที่ง่ายคือกรองการรับส่งข้อมูลทั้งหมดที่คุณไม่ต้องการกำหนดเส้นทางผ่าน VPN และทำอย่างอื่นด้วย สิ่งหนึ่งที่เป็นไปได้คือการรับส่งข้อมูลที่สร้างขึ้นจากกล่องของคุณด้วยที่อยู่ต้นทางของคุณและกำหนดเส้นทางผ่านเกตเวย์ท้องถิ่นของคุณ สิ่งนี้ทำให้บริการต่างๆเช่น SSH ทำงานได้อย่างถูกต้อง

เราจะทำที่นี่ ขั้นแรกให้สร้างตารางเส้นทางใหม่และเพิ่มเส้นทางเริ่มต้นซึ่งกำหนดเส้นทางทุกอย่างผ่านเกตเวย์ท้องถิ่นของคุณ:

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

ถัดไปสร้างกฎตัวกรองแพ็คเก็ตใหม่ที่ทำเครื่องหมายปริมาณการใช้งานทั้งหมดที่ออกจากกล่องของคุณจากแหล่งที่มาที่ระบุด้วยตัวระบุบางอย่าง

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

ขั้นสุดท้ายให้สร้างนโยบายการกำหนดเส้นทางที่เลือกทราฟฟิกที่ทำเครื่องหมายไว้ข้างต้นทั้งหมดแล้วกำหนดเส้นทางโดยใช้ตารางที่สร้างขึ้นด้านบน

ip rule add fwmark <mark> table <table>

อีกครั้งค่าของ<mark>และ<table>เป็นตัวระบุที่คุณเลือกเอง

สำหรับฉันที่ใช้เซิร์ฟเวอร์ OpenVPN ด้วยตนเองใน pfSense ก็คือการยกเลิกการตั้งค่า "บังคับให้การรับส่งข้อมูล IPv4 ที่ไคลเอ็นต์สร้างขึ้นทั้งหมดผ่านอุโมงค์"