Ingin menggunakan Linux di tempat kerja, tetapi VPN perusahaan tidak? Maka artikel ini dapat membantu, meskipun ini tidak akurat. Saya ingin memperingatkan sebelumnya bahwa saya memahami masalah administrasi jaringan dengan buruk, jadi mungkin saja saya melakukan semua yang salah. Di sisi lain, ada kemungkinan bahwa saya dapat menulis manual sedemikian rupa sehingga dapat dimengerti oleh orang awam, jadi saya menyarankan Anda untuk mencobanya.
Artikel ini memiliki banyak informasi tambahan, tetapi tanpa pengetahuan ini saya tidak akan bisa menyelesaikan masalah yang tiba-tiba saya miliki dengan pengaturan vpn. Saya pikir siapa pun yang mencoba menerapkan manual ini akan memiliki masalah yang tidak saya miliki, dan saya berharap informasi tambahan ini akan membantu menyelesaikan masalah ini sendiri.
Sebagian besar perintah yang digunakan dalam manual harus dijalankan melalui sudo, yang dihapus karena singkatnya. Ingatlah selalu.
Sebagian besar alamat ip sangat dikaburkan, jadi jika Anda melihat alamat seperti 435.435.435.435, harus ada beberapa ip normal khusus untuk kasing Anda.
Saya memiliki Ubuntu 18,04, tetapi saya pikir dengan beberapa perubahan panduan ini dapat diterapkan ke distribusi lain. Namun, dalam teks ini, Linux == Ubuntu.
Cisco terhubung
Mereka yang menggunakan Windows atau MacOS dapat terhubung ke VPN perusahaan kami melalui Cisco Connect, yang perlu menentukan alamat gateway dan memasukkan kata sandi setiap kali terhubung, yang terdiri dari bagian tetap dan kode yang dihasilkan oleh Google Authenticator.
Dalam kasus Linux, tidak mungkin untuk mendapatkan Cisco Connect, tetapi ternyata Google merekomendasikan untuk menggunakan openconnect, yang dibuat khusus untuk menggantikan Cisco Connect.
Buka koneksi
Secara teori, di ubunt ada antarmuka grafis khusus untuk openconnect tetapi tidak berfungsi untuk saya. Mungkin itu yang terbaik.
Di ubunt openconnect diinstal dari manajer paket.
apt install openconnect
Segera setelah instalasi, Anda dapat mencoba terhubung ke VPN
openconnect --user poxvuibr vpn.evilcorp.com
vpn.evilcorp.com adalah alamat VPN fiktif \
poxvuibr - nama pengguna fiktif
openconnect akan meminta Anda untuk memasukkan kata sandi, yang saya ingat, terdiri dari bagian dan kode tetap dari Google Authenticator, dan kemudian mencoba untuk terhubung ke vpn. Jika ternyata, selamat, Anda dapat dengan aman melewati bagian tengahnya, yang sangat menyusahkan dan langsung membahas tentang pembuka koneksi di latar belakang. Jika tidak berhasil, maka Anda dapat melanjutkan. Meskipun jika ternyata ketika menghubungkan, misalnya, dari Wi-Fi tamu di tempat kerja, dimungkinkan untuk bersukacita dan lebih awal, Anda harus mencoba mengulangi prosedur dari rumah.
Sertifikat
Dengan probabilitas tinggi, tidak ada yang akan mulai, dan knalpot openconnect akan terlihat seperti ini:
POST https://vpn.evilcorp.com/ Connected to 777.777.777.777:443 SSL negotiation with vpn.evilcorp.com Server certificate verify failed: signer not found Certificate from VPN server "vpn.evilcorp.com" failed verification. Reason: signer not found To trust this server in future, perhaps add this to your command line: --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 Enter 'yes' to accept, 'no' to abort; anything else to view: fgets (stdin): Operation now in progress
Di satu sisi, ini tidak menyenangkan, karena tidak ada koneksi ke VPN, tetapi di sisi lain, cara memperbaiki masalah ini dapat dipahami secara prinsip.
Kemudian server mengirimi kami sertifikat, yang menurutnya dapat ditentukan bahwa koneksi dilakukan ke server perusahaan asli, dan bukan ke penipu yang jahat, dan sertifikat ini tidak diketahui oleh sistem. Jadi dia tidak bisa memeriksa apakah server sebenarnya atau tidak. Jadi, untuk berjaga-jaga, itu berhenti bekerja.
Agar openconnect masih terhubung ke server, Anda perlu secara eksplisit memberi tahu sertifikat mana yang harus berasal dari server VPN menggunakan kunci --servercert
Dan Anda dapat mengetahui sertifikat mana yang dikirim server kepada kami langsung dari openconnect yang dicetak. Di sini dari bagian ini:
To trust this server in future, perhaps add this to your command line: --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 Enter 'yes' to accept, 'no' to abort; anything else to view: fgets (stdin): Operation now in progress
Dengan perintah ini Anda dapat mencoba menghubungkan lagi
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com
Mungkin itu berfungsi sekarang, maka Anda bisa pergi ke akhir. Tapi Ubunta secara pribadi menunjukkan ara dalam bentuk ini
POST https://vpn.evilcorp.com/ Connected to 777.777.777.777:443 SSL negotiation with vpn.evilcorp.com Server certificate verify failed: signer not found Connected to HTTPS on vpn.evilcorp.com XML POST enabled Please enter your username and password. POST https://vpn.evilcorp.com/ Got CONNECT response: HTTP/1.1 200 OK CSTP connected. DPD 300, Keepalive 30 Set up DTLS failed; using SSL instead Connected as 192.168.333.222, using SSL NOSSSSSHHHHHHHDDDDD 3 NOSSSSSHHHHHHHDDDDD 3 RTNETLINK answers: File exists /etc/resolvconf/update.d/libc: Warning: /etc/resolv.conf is not a symbolic link to /run/resolvconf/resolv.conf
/etc/resolv.conf
# Generated by NetworkManager search gst.evilcorpguest.com nameserver 127.0.0.53
/run/resolvconf/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN # 127.0.0.53 is the systemd-resolved stub resolver. # run "systemd-resolve --status" to see details about the actual nameservers. nameserver 192.168.430.534 nameserver 127.0.0.53 search evilcorp.com gst.publicevilcorp.com
habr.com akan diselesaikan, tetapi tidak mungkin untuk masuk ke sana. Alamat seperti jira.evilcorp.com tidak menyelesaikan sama sekali.
Apa yang terjadi di sini tidak jelas bagi saya. Tetapi percobaan menunjukkan bahwa jika Anda menambahkan baris ke /etc/resolv.conf
nameserver 192.168.430.534
maka alamat di dalam VPN akan secara ajaib teratasi dan akan mungkin untuk memutarnya, yaitu mencari alamat DNS yang harus diselesaikan, mencari di /etc/resolv.conf, dan tidak ke tempat lain.
Jika ada koneksi ke VPN dan berfungsi, Anda dapat memastikan tanpa perubahan di /etc/resolv.conf, untuk ini cukup masuk ke browser bukan nama simbolis sumber daya dari vpn, tetapi alamat ip-nya
Hasilnya adalah dua masalah
- pada koneksi ke VPN, dns tidak diambil
- semua lalu lintas melewati vpn, yang tidak memungkinkan Anda untuk pergi ke Internet
Apa yang akan saya lakukan sekarang akan saya katakan, tetapi pertama-tama otomatisasi kecil.
Entri otomatis dari kata sandi yang diperbaiki
Pada saat ini, Anda kemungkinan besar telah memasukkan kata sandi setidaknya lima kali dan prosedur ini sudah cukup membuat Anda lelah. Pertama, karena kata sandi panjang, dan kedua, karena saat memasukkan, Anda harus menyimpan dalam jangka waktu yang tetap
Solusi akhir untuk masalah ini tidak termasuk dalam artikel, tetapi dapat dilakukan agar bagian kata sandi tetap tidak harus dimasukkan berkali-kali.
Misalkan bagian tetap dari kata sandi adalah fixedPassword, dan bagian dari Google Authenticator 567 987. Seluruh kata sandi openconnect dapat dilewatkan melalui input standar menggunakan argumen --passwd-on-stdin.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdin
Sekarang Anda dapat terus-menerus kembali ke perintah yang dimasukkan terakhir dan hanya mengubah sebagian dari Google Authenticator di sana.
VPN Perusahaan tidak mengizinkan akses Internet.
Secara umum, itu tidak terlalu merepotkan ketika untuk pergi ke hub Anda harus menggunakan komputer terpisah. Kurangnya kemampuan untuk menyalin dan menempel dengan stackoverfow umumnya dapat melumpuhkan pekerjaan, sehingga sesuatu harus dilakukan.
Hal ini diperlukan untuk mengatur, sehingga ketika Anda perlu pergi ke sumber daya dari jaringan internal, Linux pergi ke vpn, dan ketika Anda perlu pergi ke hub, ia pergi ke Internet.
openconnect setelah memulai dan membangun koneksi dengan vpn, mengeksekusi skrip khusus, yang terletak di / usr / share / vpnc-scripts / vpnc-script. Beberapa variabel ditransfer ke skrip input, dan itu melakukan konfigurasi vpn. Sayangnya, saya tidak dapat menemukan cara untuk membagi arus lalu lintas antara vpn perusahaan dan seluruh internet menggunakan skrip asli.
Rupanya khusus untuk orang-orang seperti saya, utilitas vpn-slice dikembangkan, yang memungkinkan Anda untuk mengarahkan lalu lintas melalui dua saluran tanpa menari dengan rebana. Ya, itu artinya, Anda harus menari, tetapi dukun tidak perlu.
Membagi traffic dengan vpn-slice
Pertama, vpn-slice harus diinstal, Anda harus mengetahuinya sendiri. Jika ada pertanyaan di komentar, saya akan menulis posting terpisah tentang ini. Tapi ini adalah program python biasa, jadi seharusnya tidak ada kesulitan. Saya mengatur menggunakan virtualenv.
Dan kemudian Anda perlu menggunakan utilitas, menggunakan kunci --script yang menunjukkan openconnect bahwa alih-alih skrip standar Anda perlu menggunakan vpn-slice
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin \ --script "./bin/vpn-slice 192.168.430.0/24 " vpn.evilcorp.com
Dalam --script, sebuah baris dilewatkan dengan perintah yang perlu dipanggil, bukan script. ./bin/vpn-slice - path ke file executable vpn-slice 192.168.430.0/24 - mask dari alamat yang akan dikunjungi di vpn. Di sini, maksud saya bahwa jika alamat dimulai dengan 192.168.430, maka sumber daya dengan alamat ini harus dicari di dalam vpn
Sekarang situasinya hampir normal. Hampir. Sekarang Anda dapat masuk ke hub dan Anda dapat masuk ke sumber daya perusahaan internal dengan ip, tetapi Anda tidak bisa masuk ke sumber daya perusahaan internal dengan nama simbolik. Jika Anda mendaftarkan korespondensi nama simbolis dan alamat di host, semuanya akan berfungsi. Dan bekerja sampai perubahan ip. Linux sekarang dapat pergi ke Internet atau ke jaringan perusahaan, tergantung pada ip. Tetapi DNS non-perusahaan masih digunakan untuk menentukan alamat.
Masalahnya masih dapat terwujud dalam bentuk ini - semuanya baik-baik saja di tempat kerja, dan di rumah Anda dapat mengakses sumber daya internal perusahaan hanya dengan ip. Ini karena ketika Anda terhubung ke Wi-Fi perusahaan, DNS perusahaan juga digunakan, dan di dalamnya alamat simbolis dari tekad VPN, meskipun masih tidak mungkin untuk pergi ke alamat seperti itu tanpa menggunakan VPN.
Modifikasi otomatis dari file host
Jika Anda dengan sopan meminta vpn-slice, maka setelah menaikkan VPN, ia dapat pergi ke DNS-nya, menemukan alamat IP sumber daya yang diperlukan di sana dengan nama simbolisnya dan memasukkannya di host. Setelah VPN dimatikan, alamat ini akan dihapus dari host. Untuk melakukan ini, berikan nama simbolis ke vpn-slice sebagai argumen. Itu dia.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin --script "./bin/vpn-slice 192.168.430.0/24 jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com
Sekarang semuanya harus bekerja baik di kantor maupun di pantai.
Cari alamat semua subdomain di DNS yang diberikan VPN
Jika ada beberapa alamat dalam jaringan, maka pendekatan dengan secara otomatis memodifikasi file host cukup berhasil. Tetapi jika ada banyak sumber daya di jaringan, maka Anda akan terus-menerus perlu menambahkan baris seperti zoidberg.test.evilcorp.com ke skrip zoidberg ini adalah nama dari salah satu tempat uji.
Tetapi sekarang kita memiliki sedikit pemahaman tentang mengapa kebutuhan ini dapat dihilangkan.
Jika, setelah menaikkan VPN, lihat di / etc / hosts, Anda dapat melihat, ini adalah baris
192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOCREATED
Ya, dan baris baru ditambahkan ke resolv.conf. Singkatnya, vpn-slice entah bagaimana menentukan di mana server dns untuk vpn berada.
Sekarang kita perlu memastikan bahwa untuk mengetahui alamat ip dari nama domain yang berakhir dengan evilcorp.com, Linux pergi ke dns perusahaan, dan jika ada hal lain yang diperlukan, maka ke default.
Saya mencari Google untuk waktu yang lama dan menemukan bahwa fungsi seperti itu ada di luar kotak. Ini merujuk pada kemampuan untuk menggunakan server dns dnsmasq lokal untuk menyelesaikan nama.
Artinya, Anda dapat membuat Linux selalu pergi ke server dns lokal untuk alamat ip, yang pada gilirannya, tergantung pada nama domain, akan mencari ip pada server dns eksternal yang sesuai.
Untuk mengelola segala sesuatu yang berkaitan dengan jaringan dan koneksi jaringan, Ubunt menggunakan NetworkManager, dan antarmuka grafis untuk memilih, misalnya, koneksi Wi-Fi hanya bagian depannya.
Kita perlu menaiki konfigurasinya.
- Buat file di /etc/NetworkManager/dnsmasq.d/evilcorp
address = /. evilcorp.com/192.168.430.534
Perhatikan poin sebelum evilcorp. Ini menandakan dnsmasq bahwa semua subdomain evilcorp.com harus dicari di dns perusahaan.
- Beri tahu NetworkManager untuk menggunakan dnsmasq untuk menyelesaikan nama
Konfigurasi manajer jaringan terletak di /etc/NetworkManager/NetworkManager.conf Anda perlu menambahkan di sana:
[utama]
dns = dnsmasq
- Mulai kembali NetworkManager
service network-manager restart
Sekarang, setelah terhubung ke VPN menggunakan sekelompok openconnect dan vpn-slice, ip akan terdeteksi secara normal bahkan jika Anda tidak menambahkan alamat simbolis ke argumen ke vpnslice.
Cara masuk melalui VPN ke layanan terpisah
Setelah ternyata terhubung ke vpn, saya sangat senang selama dua hari, dan kemudian ternyata jika Anda terhubung ke VPN bukan dari jaringan kantor, surat tidak berfungsi. Gejala yang akrab, bukan?
Email kami ada di mail.publicevilcorp.com, yang berarti tidak masuk dalam aturan dnsmasq dan alamat server email dicari melalui DNS publik.
Yah, kantor masih menggunakan DNS di mana alamat ini berada. Ya, saya pikir begitu. Bahkan, setelah menambahkan baris ke dnsmasq
address = / mail.publicevilcorp.com / 192.168.430.534
situasinya belum berubah. ip tetap sama. Saya harus pergi bekerja.
Dan hanya kemudian, ketika saya menyelidiki situasi dan sedikit menyelesaikan masalah, satu orang pintar mengatakan kepada saya bagaimana menyelesaikannya. Itu perlu untuk terhubung ke server surat tidak hanya seperti itu, tetapi melalui vpn
Saya menggunakan vpn-slice untuk mengakses VPN ke alamat yang dimulai dengan 192.168.430. Dan di server surat, bukan hanya alamat simbolis bukan subdomain dari evilcorp, ia juga memiliki alamat IP yang tidak dimulai dengan 192.168.430. Dan tentu saja dia tidak membiarkan siapa pun keluar dari jaringan umum.
Agar Linux dapat melalui VPN dan ke server mail, Anda perlu menambahkannya ke vpn-slice. Misalkan alamat pengirim adalah 555.555.555.555
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin --script "./bin/vpn-slice 555.555.555.555 192.168.430.0/24" vpn.evilcorp.com
Script untuk menaikkan VPN dengan satu argumen
Semua ini, tentu saja, sangat tidak nyaman. Ya, Anda dapat menyimpan teks ke file dan menyalin-menempelnya ke konsol, daripada mengetik dengan tangan Anda, tetapi itu masih tidak cukup menyenangkan. Untuk memudahkan proses, Anda bisa membungkus perintah dalam skrip yang akan berlokasi di PATH. Dan kemudian Anda hanya perlu memasukkan kode yang diperoleh dari Google Authenticator
#!/bin/sh echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin \ --script "./bin/vpn-slice 192.168.430.0/24 jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com
Jika Anda memasukkan skrip ke connect ~ evilcorp ~ Anda bisa menulis di konsol
connect_evil_corp 567987
Tapi sekarang, bagaimanapun, untuk beberapa alasan Anda harus menjaga konsol tempat openconnect terbuka
Buka peluncuran di latar belakang
Untungnya, penulis openconnect merawat kami dan menambahkan kunci khusus - latar belakang ke program, yang membuat program bekerja di latar belakang setelah diluncurkan. Jika Anda menjalankannya seperti ini, maka setelah peluncuran Anda dapat menutup konsol
#!/bin/sh echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 \ --user poxvuibr \ --passwd-on-stdin \ --background \ --script "./bin/vpn-slice 192.168.430.0/24 jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com
Sekarang tidak jelas ke mana log itu pergi. Log umumnya tidak benar-benar diperlukan bagi kami, tetapi Anda tidak pernah tahu. openconnect dapat mengarahkan mereka ke syslog, di mana mereka akan tetap utuh. Anda perlu menambahkan kunci --syslog ke perintah
#!/bin/sh echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 \ --user poxvuibr \ --passwd-on-stdin \ --background \ --syslog \ --script "./bin/vpn-slice 192.168.430.0/24 jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com \
Jadi, ternyata openconnect bekerja di suatu tempat di latar belakang dan tidak mengganggu siapa pun, tetapi cara menghentikannya tidak jelas. Yaitu, Anda bisa, tentu saja, menyaring knalpot ps dengan grep dan mencari proses dengan nama yang openconnect, tetapi entah bagaimana suram. Terima kasih kepada penulis yang memikirkan hal ini. Openconnect memiliki kunci --pid-file, yang dengannya Anda dapat menginstruksikan openconnect untuk menulis ID prosesnya ke sebuah file.
#!/bin/sh echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 \ --user poxvuibr \ --passwd-on-stdin \ --background \ --syslog \ --script "./bin/vpn-slice 192.168.430.0/24 jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com \ --pid-file ~/vpn-pid
Sekarang Anda selalu dapat memakukan proses dengan perintah
kill $(cat ~/vpn-pid)
Jika tidak ada proses, kill akan bersumpah, tetapi itu tidak akan menimbulkan kesalahan. Jika tidak ada file, maka tidak ada hal buruk yang akan terjadi, sehingga Anda dapat dengan aman mematikan proses di baris pertama skrip.
kill $(cat ~/vpn-pid) #!/bin/sh echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 \ --user poxvuibr \ --passwd-on-stdin \ --background \ --syslog \ --script "./bin/vpn-slice 192.168.430.0/24 jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com \ --pid-file ~/vpn-pid
Sekarang Anda dapat menyalakan komputer, buka konsol dan jalankan perintah, berikan kode dari Google Authenticator. Konsol kemudian dapat dipaku.
Tanpa vpn-slice. Alih-alih kata penutup
Sangat sulit untuk memahami bagaimana hidup tanpa vpn-slice. Saya harus banyak membaca dan google. Untungnya, ketika saya menghabiskan begitu banyak waktu dengan masalah ini, manual teknis dan bahkan openconnect man membaca seperti novel yang menarik.
Sebagai hasilnya, saya menemukan bahwa vpn-slice, seperti skrip asli, memodifikasi tabel routing ke jaringan yang terpisah.
Tabel perutean
Secara sederhana, tabel seperti itu di kolom pertama yang berisi di mana alamat tempat Linux ingin pergi harus dimulai, dan yang kedua melalui adaptor jaringan yang pergi ke alamat ini. Sebenarnya, ada lebih banyak kolom, tetapi ini tidak mengubah esensi.
Untuk melihat tabel routing, Anda perlu menjalankan perintah ip route
default via 192.168.1.1 dev wlp3s0 proto dhcp metric 600 192.168.430.0/24 dev tun0 scope link 192.168.1.0/24 dev wlp3s0 proto kernel scope link src 192.168.1.534 metric 600 192.168.430.534 dev tun0 scope link
Di sini, setiap baris bertanggung jawab ke mana harus pergi untuk mengirim pesan ke beberapa alamat. Yang pertama adalah deskripsi di mana alamat harus dimulai. Untuk memahami cara menentukan bahwa 192.168.0.0/16 berarti bahwa alamat tersebut harus dimulai dengan 192.168, Anda perlu mencari google apa penutup alamat IP itu. After dev adalah nama adaptor tempat pesan harus dikirim.
Untuk VPN, Linux membuat adaptor virtual - tun0. Untuk lalu lintas untuk semua alamat yang dimulai dengan 192.168 untuk menjalaninya, baris menjawab
192.168.0.0/16 dev tun0 scope link
Anda juga dapat melihat kondisi tabel perutean saat ini menggunakan perintah route -n (alamat ip sangat berbakat secara anonim) Perintah ini menghasilkan hasil dalam bentuk yang berbeda dan umumnya tidak digunakan lagi, tetapi knalpotnya sering ditemukan di manual online dan Anda harus dapat membacanya.
Di mana alamat ip untuk rute harus dimulai dapat dipahami dari kombinasi kolom Destination dan Genmask. Bagian-bagian dari alamat ip yang nomor 255 sesuai dalam Genmask diperhitungkan, dan yang mana 0 tidak. Yaitu, kombinasi dari Destination 192.168.0.0 dan Genmask 255.255.255.0 berarti bahwa jika alamat dimulai dengan 192.168.0, maka permintaan untuk itu akan mengikuti rute ini. Dan jika Tujuan 192.168.0.0 tetapi Genmask adalah 255.255.0.0, maka permintaan ke alamat yang dimulai dengan 192.168 akan mengikuti rute ini
Untuk mengetahui apa yang sebenarnya dilakukan vpn-slice, saya memutuskan untuk melihat kondisi tabel sebelum dan sesudah
Sebelum menyalakan VPN, sudah seperti ini
route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0 222.222.222.0 0.0.0.0 255.255.255.0 U 600 0 0 wlp3s0 333.333.333.333 222.222.222.1 255.255.255.255 UGH 0 0 0 wlp3s0
Setelah memanggil openconnect tanpa vpn-slice, itu menjadi demikian
route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0 0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0 222.222.222.0 0.0.0.0 255.255.255.0 U 600 0 0 wlp3s0 333.333.333.333 222.222.222.1 255.255.255.255 UGH 0 0 0 wlp3s0 192.168.430.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0 192.168.430.534 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
Dan setelah memanggil openconnect dalam kombinasi dengan vpn-slice seperti ini
Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0 222.222.222.0 0.0.0.0 255.255.255.0 U 600 0 0 wlp3s0 333.333.333.333 222.222.222.1 255.255.255.255 UGH 0 0 0 wlp3s0 192.168.430.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0 192.168.430.534 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
Dapat dilihat bahwa jika Anda tidak menggunakan vpn-slice, maka openconnect secara eksplisit menulis bahwa Anda harus melalui vpn ke semua alamat kecuali ditunjukkan secara terpisah.
Di sini:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0
Di dekat sana segera ditunjukkan jalur lain yang harus digunakan jika alamat yang dicoba Linux tidak cocok dengan topeng apa pun dari tabel.
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0
Sudah ditulis di sini bahwa dalam hal ini Anda harus melalui adaptor Wi-Fi standar.
Saya percaya bahwa jalur untuk VPN digunakan karena ini adalah yang pertama di tabel routing.
Dan secara teoritis, jika Anda menghapus jalur default ini dari tabel routing, maka dalam hubungannya dengan openconnect dnsmasq harus memastikan operasi normal.
Saya mencoba
route del default
Dan itu berhasil.
Mengalihkan permintaan ke server email tanpa vpn-slice
Tapi saya juga punya mail server dengan alamat 555.555.555.555, yang mana Anda juga harus melalui vpn. Rute ke sana juga harus ditambahkan dengan tangan.
ip route add 555.555.555.555 via dev tun0
Dan sekarang semua aturannya. Jadi Anda bisa melakukannya tanpa vpn-slice, tetapi Anda harus tahu apa yang Anda lakukan. Saya sekarang berpikir untuk menambahkan penghapusan rute default dan menambahkan rute untuk mailer setelah terhubung ke vpn ke baris terakhir skrip asli openconnect, hanya untuk membuat jumlah komponen yang bergerak di sepeda saya lebih kecil.
Mungkin, seseorang untuk memahami cara mengkonfigurasi VPN akan merasa cukup dengan kata penutup ini. Tetapi ketika saya mencoba untuk memahami apa dan bagaimana melakukannya, saya membaca banyak manual yang berfungsi untuk penulis, tetapi untuk beberapa alasan tidak bekerja untuk saya dan memutuskan untuk menambahkan di sini semua bagian yang saya temukan. Saya akan sangat senang dengan hal seperti itu.