Etkin bir OpenVPN istemcisi olan bir sunucuda SSH'ye izin verme

SSH ile bağlandığım CentOS 7 çalıştıran bir VPS'im var. İnternet trafiğinin VPN üzerinden yönlendirilmesi için VPS'de bir OpenVPN istemcisi çalıştırmak istiyorum, ancak yine de sunucuya SSH aracılığıyla bağlanmama izin veriyor. OpenVPN'i başlattığımda, SSH oturumumun bağlantısı kesiliyor ve artık VPS'ime bağlanamıyorum. VPS'yi, gelen SSH (bağlantı noktası 22) bağlantılarının VPS'nin gerçek IP'sinde (104.167.102.77) açılmasına izin verecek, ancak yine de giden trafiği (VPS'deki bir web tarayıcısından olduğu gibi) VPN üzerinden yönlendirecek şekilde nasıl yapılandırabilirim?

Kullandığım OpenVPN hizmeti PrivateInternetAccess ve örnek bir config.ovpn dosyası:

müşteri
dev tun
proto udp
remote nl.privateinternetaccess.com 1194
sonsuz tekrar deneme
nobind
inat anahtar
inat-tun
ca ca.crt
tls-istemci
remote-cert-tls sunucusu
Yetk kullanım geçişli
comp-lzo
fiil 1
reneg-sn 0
crl-verify crl.pem

VPS'nin ip adresi:

1: lo: mtu 65536 qdisc noqueue durumu BİLİNMİYOR
    bağlantı / geridöngü 00: 00: 00: 00: 00: 00 brd 00: 00: 00: 00: 00: 00
    inet 127.0.0.1/8 kapsam ana bilgisayarı
       sonsuza kadar geçerli_lft tercih sonsuza kadar
    inet6 :: 1/128 kapsam ana bilgisayarı
       sonsuza kadar geçerli_lft tercih sonsuza kadar
2: ens33: mtu 1500 qdisc pfifo_fast durum YUKARI qlen 1000
    bağlantı / eter 00: 50: 56: be: 16: f7 brd ff: ff: ff: ff: ff: ff
    inet 104.167.102.77/24 brd 104.167.102.255 kapsam küresel ens33
       sonsuza kadar geçerli_lft tercih sonsuza kadar
    inet6 fe80 :: 250: 56ff: febe: 16f7 / 64 kapsam bağlantısı
       sonsuza kadar geçerli_lft tercih sonsuza kadar
4: tun0: mtu 1500 qdisc pfifo_fast durumu BİLİNMİYOR qlen 100
    bağlantı / yok
    inet 10.172.1.6 eş 10.172.1.5/32 kapsam küresel tun0
       sonsuza kadar geçerli_lft tercih sonsuza kadar

VPS'nin ip rotası:

10.172.1.5 dev tun0 üzerinden 0.0.0.0/1
104.167.102.1 dev ens33 proto statik metrik 1024 ile varsayılan
10.172.1.1 10.172.1.5 dev tun0 üzerinden
10.172.1.5 dev tun0 proto çekirdeği kapsam bağlantısı src 10.172.1.6
104.167.102.0/24 dev ens33 proto çekirdek kapsam bağlantısı src 104.167.102.77
109.201.154.177 104.167.102.1 dev ens33 aracılığıyla
10.172.1.5 dev tun0 üzerinden 128.0.0.0/1

Ben buna benzer bir sorun yaşıyorum ve bu forum yazı açıklanan tarif çalışıyor .

Fikir şu anda genel IP adresinize bağlandığınızda, iade paketlerinin VPN üzerinden yönlendirilmesidir. Bu paketleri genel arayüzünüz üzerinden yönlendirilmeye zorlamanız gerekir.

Bu rota komutları umarım işe yarayacaktır:

ip kural xxxx tablo 128 ekleyin

ip yolu yyyy / y dev ethX'e tablo 128 ekle

ip rota ekleme tablosu 128 zzzz üzerinden varsayılan

Xxxx genel IP'niz olduğunda, yyyy / y genel IP adresinizin alt ağı, ethX genel Ethernet arabiriminiz ve zzzz varsayılan ağ geçidi olmalıdır.

Bunun benim için işe yaramadığını (Debian ve PrivateInternetAccess kullanarak) ancak size yardımcı olabileceğini unutmayın.

Bu biraz geç olabilir, ama ...

Sorun, varsayılan ağ geçidinin OpenVPN tarafından değiştirilmesidir ve OpenVPN'i başlatmadan önce uygun yolları ayarlamadığınız sürece geçerli SSH bağlantınızı keser.

Takip eden benim için işe yarıyor. İptables ve ip (iproute2) kullanır. Aşağıda, OpenVPN başlatılmadan önceki varsayılan ağ geçidi arayüzünün "eth0" olduğu varsayılmaktadır. Fikir, eth0 ile bağlantı kurulduğunda, eth0 artık varsayılan ağ geçidi arayüzü olmasa bile, bağlantı için yanıt paketlerinin tekrar eth0'a geri dönmesini sağlamaktır.

Bağlantı işareti, güvenlik duvarı işareti ve yönlendirme tablosu için aynı numarayı kullanabilirsiniz. Aralarındaki farkları daha belirgin hale getirmek için farklı sayılar kullandım.

# 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

===

GÜNCELLEME:

Yukarıdakiler Debian Jessie için benim için iyi çalışıyor. Ama eski bir Wheezy sisteminde ben sadece yönlendirme tablosu girişine "üzerinden" eklemeniz gerektiğini buldum:

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

Orijinal VPN olmayan ağ geçidi "12.345.67.89" olmalıdır.

@MrK yanıtına dayanarak, işi daha hızlı yapmak için buraya basit bir kod yazdım, böylece arayüzleri / IP'yi kontrol etmeniz gerekmez:

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+)')

Bu komut dosyasını VPS'imin 4'ünde denedim ve mükemmel çalışıyor.

hmm ip alt ağ örtüşme gibi geliyor .... nl.privateinternetaccess.com gibi vpn ternmination için genel ip dışında, ip şeması hakkında daha fazla bilgi bilmeden, emin olamaz.

örneğin, nl.privateinternetaccess.com'un diğer tarafındaki uzak alt ağ 10.32.43.0/24 ise ve örneğiniz, alt ağı 10.32.44.0/24 olan bir aws vpc'sindeyse. ancak kaynak ssh istemciniz 10.32.43.0/24 (aws vpc tarafınız) üzerinde yaşıyor, işe yaramayacaktır, çünkü dönüş ssh trafiği yanlışlıkla vpn üzerinden Hollanda'ya itilecektir.

bu konuda daha fazla yardım için tam ip / alt ağ bilgileri sağlayın.

...

tamam, yani ... nl'ye bağlandıktan sonra varsayılan rotanız tünelde gibi görünüyor:

10.172.1.5 dev tun0 üzerinden 0.0.0.0/1

bağlandıktan sonra bunu değiştirebilirsiniz. birçok kez vpn sunucuları sahte yollar verir. özellikle özensiz kolordu. bu durumda, vps kutusundan gelen tüm trafik nl olacak şekilde size varsayılan bir yol bastırıyorlar. varsayılan yolu 104.167.102.x olarak veya ur vps sağlayıcısında alt ağ geçidiniz varsa değiştirin.

VPN'yi açtığınızda, varsayılan ağ geçidiniz değiştirilir. Bu, kutunuzdan oluşturulan veya kutunuzdan yönlendirilen tüm trafiğin VPN ağ geçidine yönlendirileceği anlamına gelir.

Basit bir çözüm, VPN üzerinden yönlendirmek istemediğiniz tüm trafiği filtrelemek ve onunla başka bir şey yapmaktır. Bir olasılık, kutunuzdan oluşturulan trafiği yerel kaynak adresinizle almak ve yerel ağ geçidinizden yönlendirmektir. Bu, SSH gibi hizmetlerin düzgün çalışmasını sağlar.

Bunu burada yapacağız. İlk olarak, yeni bir yönlendirme tablosu oluşturun ve her şeyi yerel ağ geçidinize yönlendiren varsayılan bir rota ekleyin:

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

Ardından, kutunuzu belirli bir kaynak adresten terk eden tüm trafiği bazı tanımlayıcılarla işaretleyen yeni bir paket filtresi kuralı oluşturun.

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

Son olarak, yukarıda belirtilen işaretli trafiği alan ve yukarıdaki oluşturulan tabloyu kullanarak yönlendiren bir yönlendirme politikası oluşturun.

ip rule add fwmark <mark> table <table>

Bir kez daha, değerleri <mark>ve <table>kendi seçtiğiniz rastgele tanımlayıcılar.

Benim için OpenVPN sunucusunu pfSense'te çalıştırırken, "İstemci tarafından oluşturulan tüm IPv4 trafiğini tünelden zorla" ayarının işaretini kaldırmak oldu.