Sambungkan homeserver saya, menjalankan server OpenVPN, ke VPN eksternal


0

Situasi Berikut.

Salah satu server saya menjalankan server OpenVPN serta Server OpenSSH (dan beberapa hal lainnya) , keduanya dapat diakses dari jarak jauh.

Ketika saya tidak di rumah, saya biasanya terhubung ke server tersebut melalui VPN dan membuka beberapa sesi SSH melalui ip publik dari server tersebut.

Saya ingin menyambungkan homeserver saya ke VPN eksternal, sehingga semua lalu lintas (keluar) yang melewati server saya juga disalurkan melalui VPN eksternal.

|MobilePhone|---VPN ----|
                        |
|Other Dev|-----SSH ----|----VPN---->| Homeserver | --- VPN ---> | External Provider |
                        |               ^
|Laptop|--SSH/NFS/VPN---|               |
                                        |
                                        |
|Laptop|--------SSH---------------------|

Saya masih ingin dapat SSH ke server saya melalui (sebelumnya) IP publik. Perute saya masih terhubung langsung ke ISP saya, jadi lalu lintas masuk apa pun harus langsung diteruskan ke server, jadi saya pikir itu harus dimungkinkan.

Naif seperti saya, saya pikir, mungkin hanya berfungsi jika saya menghubungkan server saya ke VPN eksternal melalui tun1 (tun0 digunakan oleh server) dan saya baik untuk pergi. Konfigurasi klien VPN eksternal telah nobindditetapkan, jadi seharusnya tidak ada konflik pada port juga.

Saya masih bisa melihat output dari koneksi openvpn. Namun tidak lama setelah itu, semua koneksi saya terputus.

* Saya sekarang tidak dapat terhubung ke VPN saya atau SSH ke dalamnya. Apache juga tidak dapat dijangkau lagi. Saya kira tidak akan ada apa-apa

Router saya masih merespons ping pada alamat IP publiknya.

Saya kira menghubungkan ke VPN mengambil alih antarmuka jaringan server saya atau sesuatu ke arah ini. Jadi itu harus menjadi masalah routing.

Tetapi saya tidak yakin apa yang sebenarnya terjadi di sana dan hal-hal apa yang harus saya ubah agar ini berhasil.

Saya ingin mengerti mengapa ini tidak berhasil seperti yang saya coba.

Apa yang perlu saya pelajari untuk mengatur skenario seperti itu dengan benar?

Catatan :

  • Saya berpikir tentang paket yang dikembalikan. Tapi saya pikir saya entah bagaimana dapat mengatur rute, sehingga semua paket yang berasal dari ip internal router saya akan dikirim kembali ke router bukan melalui VPN?
  • Sesuatu seperti ip route add 192.168.0.0/24 via 192.168.0.1 dev eth1?

Memperbarui

Saya berhasil melangkah lebih jauh dengan menambahkan baris berikut ke /etc/network/interfaces

up ip rule add from 192.168.0.0/24 table 128 || true
up ip route add table 128 to 192.168.0.0/24 dev eth0 || true
up ip route add table 128 default via 192.168.178.1 || true

Ini memungkinkan saya untuk mengakses apache dan SSH ke server saya melalui IP publik aslinya bahkan ketika server terhubung ke VPN eksternal.

Saya kira itu tidak tentang apa yang ada dalam pikiran saya, setiap paket yang berasal dari LAN atau router saya dialihkan melalui eth0 menggunakan router saya sebagai gateway default, bukan adaptor tun1 VPN eksternal.

Sejauh ini baik.

Masalah yang saya alami sekarang adalah, ketika laptop saya terhubung ke server OpenVPN yang berjalan di server saya, setiap koneksi terputus.

Saya kira masalahnya mirip dengan masalah aslinya. Paket-paket yang berasal dari laptop saya, terhubung melalui VPN (172.16.0.10), jangan dialihkan kembali ke laptop karena paket yang dikembalikan akan dikirim melalui gateway default, yang merupakan VPN eksternal yang terhubung dengan server saya.

Saya mengutak-atik tabel routing mencoba untuk merutekan apa pun yang berasal dari 172.16.0.0 kembali ke 172.16.0.xx via tun0. Akhirnya saya mengacaukan tabel perutean dan sekarang permintaan apa pun habis ketika laptop saya terhubung ke server VPN saya, terlepas dari apakah server saya terhubung ke VPN eksternal atau tidak.

Saya membersihkan tabel routing dan me-reboot server, berharap untuk memperbaiki setidaknya ini lagi.

Saya tidak yakin apakah itu bisa menjadi masalah bahwa laptop saya terhubung ke lan saya (192.168.178.xx) juga.


Layanan Anda seperti SSH & HTTP tidak akan berfungsi dari IP publik Anda yang sebenarnya. Jika Anda memikirkannya, paket yang masuk akan sampai ke server, tetapi paket yang kembali ke klien Anda akan diteruskan melalui VPN dan tampaknya berasal dari IP yang sama sekali berbeda.
heavyd

Reboot memperbaiki masalah. SSH dan HTTP berfungsi ketika server berada di belakang VPN eksternal, tetapi saya masih tidak memiliki petunjuk bagaimana membuat sesuatu berfungsi ketika laptop saya pada gilirannya terhubung ke server VPN saya.
C5H8NNaO4

1
Anda perlu MENGATASI paket yang datang dari laptop Anda dan kemudian keluar melalui VPN "lain". Sesuatu seperti ini harus melakukannya:iptables -t nat -A POSTROUTING -o tun1 -j MASQUERADE
András Korn

@ AndrásKorn Wow, terima kasih banyak, itu berhasil! Itu sangat membantu, ini membuat saya sibuk 5 jam terakhir. Apakah Anda ingin membungkusnya menjadi jawaban? Saya masih harus membaca tentang itu sebelum saya bisa memasukkannya dalam jawaban saya sendiri.
C5H8NNaO4

@ C5H8NNaO4, tentu, ini dia. Senang bisa membantu.
András Korn

Jawaban:


1

Masalah Anda adalah bahwa paket-paket yang dikirim oleh notebook Anda dikirim melalui tautan VPN dari homeserver menggunakan alamat sumber aslinya ( tunkemungkinan besar dari antarmuka laptop ). Paket-paket ini harus dijatuhkan oleh penyedia VPN Anda, tetapi meskipun tidak, paket balasan tidak akan menemukan jalannya ke laptop Anda.

Solusinya adalah memastikan paket balasan juga melewati homeserver Anda; untuk mencapai itu, mereka tampaknya adalah balasan yang dikirim ke pemilik rumah Anda. Oleh karena itu, Anda perlu menulis ulang alamat sumber pada paket yang keluar dari tun1antarmuka homeservers ke IP antarmuka itu, menggunakan mis.

iptables -t nat -A POSTROUTING -o tun1 -j MASQUERADE

Menggunakan tcpdump -nlvvv -i tun1Anda dapat memeriksa apa yang dilakukan perintah iptables terhadap lalu lintas keluar Anda. Jika Anda menggunakan tcpdump untuk melihat lalu lintas di tempat pertama, Anda mungkin akan segera menyadari apa yang salah. :)


Terima kasih banyak. - tcpdumpAkan sangat berguna di masa depan, saya kira saya harus membaca beberapa manual :)
C5H8NNaO4
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.