Linux'u işyerinizde kullanmak istiyorsunuz ancak kurumsal VPN'iniz buna izin vermiyor mu? O zaman bu makale yardımcı olabilir, ancak bu kesin değildir. Ağ yönetimi konularını iyi anlamadığım konusunda sizi şimdiden uyarmak isterim, dolayısıyla her şeyi yanlış yapmış olmam mümkündür. Öte yandan sıradan insanların da anlayabileceği şekilde bir rehber yazmam mümkün o yüzden denemenizi tavsiye ederim.
Makale pek çok gereksiz bilgi içeriyor, ancak bu bilgi olmasaydı, VPN kurulumunda beklenmedik bir şekilde karşıma çıkan sorunları çözemezdim. Bu kılavuzu kullanmaya çalışan herkesin bende olmayan sorunlarla karşılaşacağını düşünüyorum ve bu ekstra bilgilerin bu sorunları kendi başlarına çözmelerine yardımcı olacağını umuyorum.
Bu kılavuzda kullanılan komutların çoğunun sudo aracılığıyla çalıştırılması gerekir; bu, kısa olması açısından kaldırılmıştır. Aklında tut.
Çoğu IP adresi ciddi şekilde gizlenmiştir, dolayısıyla 435.435.435.435 gibi bir adres görürseniz, sizin durumunuza özel olarak orada normal bir IP bulunmalıdır.
Ubuntu 18.04'üm var, ancak küçük değişikliklerle kılavuzun diğer dağıtımlara da uygulanabileceğini düşünüyorum. Ancak bu metinde Linux == Ubuntu.
Cisco Bağlantısı
Windows veya MacOS kullananlar, ağ geçidi adresini belirtmesi ve her bağlandığınızda sabit bir parçadan ve Google Authenticator tarafından oluşturulan bir koddan oluşan bir şifre girmesi gereken Cisco Connect aracılığıyla kurumsal VPN'imize bağlanabilir.
Linux durumunda, Cisco Connect'i çalıştıramadım, ancak özellikle Cisco Connect'in yerini almak üzere yapılmış bir openconnect kullanma önerisini Google'da aramayı başardım.
Açık bağlantı
Teorik olarak Ubuntu'nun openconnect için özel bir grafik arayüzü var, ancak bu bende işe yaramadı. Belki de böylesi daha iyidir.
Ubuntu'da paket yöneticisinden openconnect kurulur.
apt install openconnectKurulumdan hemen sonra bir VPN'ye bağlanmayı deneyebilirsiniz
openconnect --user poxvuibr vpn.evilcorp.comvpn.evilcorp.com hayali bir VPN'in adresidir
poxvuibr - hayali kullanıcı adı
openconnect sizden sabit bir parça ve Google Authenticator'dan gelen bir koddan oluşan bir şifre girmenizi isteyecek ve ardından vpn'ye bağlanmaya çalışacaktır. Eğer işe yararsa, tebrikler, çok zahmetli olan orta kısmı güvenle atlayabilir ve arka planda openconnect'in çalışması konusuna geçebilirsiniz. Eğer işe yaramazsa devam edebilirsiniz. Örneğin iş yerindeki bir misafir Wi-Fi'sinden bağlanırken işe yaradıysa da, sevinmek için henüz çok erken olabilir; prosedürü evden tekrarlamaya çalışmalısınız.
sertifika
Hiçbir şeyin başlamama olasılığı yüksektir ve openconnect çıktısı şuna benzer:
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 progressBir yandan bu rahatsız edici çünkü VPN ile bağlantı yoktu, ancak diğer yandan bu sorunun nasıl çözüleceği prensipte açık.
Burada sunucu bize, bağlantının kötü bir dolandırıcıya değil, yerel şirketimizin sunucusuna yapıldığını belirleyebileceğimiz bir sertifika gönderdi ve bu sertifika sistem tarafından bilinmiyor. Bu nedenle sunucunun gerçek olup olmadığını kontrol edemiyor. Ve böylece, her ihtimale karşı çalışmayı durdurur.
Openconnect'in sunucuya bağlanabilmesi için —servercert anahtarını kullanarak VPN sunucusundan hangi sertifikanın gelmesi gerektiğini açıkça belirtmeniz gerekir.
Ayrıca sunucunun bize hangi sertifikayı gönderdiğini doğrudan openconnect'in yazdırdığı belgeden öğrenebilirsiniz. İşte bu parçadan:
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 progressBu komutla tekrar bağlanmayı deneyebilirsiniz
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.comBelki şimdi çalışıyor, o zaman sonuna geçebilirsiniz. Ama şahsen Ubunta bana bu formda bir incir gösterdi
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.comhabr.com çözecektir ama oraya gidemeyeceksiniz. Jira.evilcorp.com gibi adresler hiçbir şekilde çözümlenmiyor.
Burada ne olduğu benim için net değil. Ancak deney şunu gösteriyor: satırı /etc/resolv.conf dosyasına eklerseniz
nameserver 192.168.430.534daha sonra VPN içindeki adresler sihirli bir şekilde çözümlenmeye başlayacak ve siz bunların arasında dolaşabilirsiniz; yani, DNS'nin adresleri çözümlemek için aradığı şey, başka bir yerde değil, özellikle /etc/resolv.conf dosyasında görünür.
VPN ile bir bağlantı olduğunu ve /etc/resolv.conf dosyasında herhangi bir değişiklik yapmadan çalıştığını doğrulayabilirsiniz; bunu yapmak için tarayıcıya VPN'deki kaynağın sembolik adını değil, IP adresini girin.
Sonuç olarak iki sorun var
- Bir VPN'ye bağlanırken DNS'leri alınmıyor
- tüm trafik internete erişime izin vermeyen VPN üzerinden geçiyor
Şimdi size ne yapacağınızı anlatacağım ama önce biraz otomasyon.
Şifrenin sabit kısmının otomatik girişi
Şimdiye kadar büyük ihtimalle şifrenizi en az beş kez girmişsinizdir ve bu prosedür sizi çoktan yormuştur. Birincisi, şifrenin uzun olması ve ikincisi, giriş yaparken sabit bir süreye uymanız gerektiği için
Sorunun nihai çözümü yazıda yer almıyordu ancak şifrenin sabit kısmının defalarca girilmesine gerek kalmayacağından emin olabilirsiniz.
Şifrenin sabit kısmının sabitPassword olduğunu ve Google Authenticator'dan gelen kısmının 567 olduğunu varsayalım. Şifrenin tamamı --passwd-on-stdin argümanı kullanılarak standart giriş yoluyla openconnect'e aktarılabilir.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdinArtık sürekli olarak son girilen komuta dönebilir ve orada Google Authenticator'ın yalnızca bir bölümünü değiştirebilirsiniz.
Kurumsal bir VPN internette gezinmenize izin vermez.
Genel olarak Habr'a gitmek için ayrı bir bilgisayar kullanmak zorunda kalmanız pek de sakıncalı değil. Stackoverfow'dan kopyalayıp yapıştıramamak genellikle işi felç edebilir, bu nedenle bir şeyler yapılması gerekir.
Bunu bir şekilde organize etmemiz gerekiyor ki, iç ağdan bir kaynağa erişmeniz gerektiğinde Linux VPN'e, Habr'a gitmeniz gerektiğinde ise İnternet'e gitsin.
openconnect, vpn'yi başlatıp bağlantı kurduktan sonra, /usr/share/vpnc-scripts/vpnc-script'te bulunan özel bir komut dosyasını çalıştırır. Bazı değişkenler komut dosyasına girdi olarak aktarılır ve VPN'yi yapılandırır. Ne yazık ki, yerel bir komut dosyası kullanarak kurumsal bir VPN ile İnternet'in geri kalanı arasındaki trafik akışını nasıl böleceğimi bulamadım.
Görünüşe göre, vpn-slice yardımcı programı özellikle benim gibi insanlar için geliştirildi ve bu, tefle dans etmeden trafiği iki kanal üzerinden göndermenize olanak tanıyor. Yani dans etmen gerekecek ama şaman olmana gerek yok.
VPN dilimini kullanarak trafik ayırma
Öncelikle vpn-slice kurmanız gerekecek, bunu kendiniz çözmeniz gerekecek. Yorumlarda soru olursa bu konuyla ilgili ayrı bir yazı yazacağım. Ancak bu normal bir Python programı olduğundan herhangi bir zorluk yaşanmayacaktır. Virtualenv kullanarak kurulum yaptım.
Daha sonra, openconnect için standart komut dosyası yerine vpn-slice kullanmanız gerektiğini belirten -script anahtarı kullanılarak yardımcı programın uygulanması gerekir.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin
--script "./bin/vpn-slice 192.168.430.0/24 " vpn.evilcorp.com --script, komut dosyası yerine çağrılması gereken bir komut içeren bir dize iletilir. ./bin/vpn-slice - vpn-slice çalıştırılabilir dosyasının yolu 192.168.430.0/24 - vpn'de gidilecek adreslerin maskesi. Burada demek istediğimiz adres 192.168.430 ile başlıyorsa VPN içerisinde bu adrese sahip kaynağın aranması gerekmektedir.
Durum artık neredeyse normal olmalı. Neredeyse. Artık Habr'a gidip şirket içi kaynağa ip ile gidebilirsiniz ancak şirket içi kaynağa sembolik isimle gidemezsiniz. Ana bilgisayarlarda sembolik ad ile adres arasında bir eşleşme belirlerseniz her şey çalışmalıdır. Ve ip değişene kadar çalışın. Linux artık IP'ye bağlı olarak İnternet'e veya intranete erişebilir. Ancak adresi belirlemek için hâlâ kurumsal olmayan DNS kullanılıyor.
Sorun şu şekilde de kendini gösterebilir - işte her şey yolunda, ancak evde dahili kurumsal kaynaklara yalnızca IP üzerinden erişebilirsiniz. Bunun nedeni, kurumsal Wi-Fi'ye bağlandığınızda kurumsal DNS'nin de kullanılması ve VPN kullanmadan böyle bir adrese gitmenin hala imkansız olmasına rağmen VPN'den gelen sembolik adreslerin burada çözümlenmesidir.
Hosts dosyasının otomatik olarak değiştirilmesi
VPN-slice kibarca sorulursa, VPN'yi yükselttikten sonra DNS'sine gidebilir, orada gerekli kaynakların IP adreslerini sembolik adlarıyla bulabilir ve bunları ana bilgisayarlara girebilir. VPN kapatıldıktan sonra bu adresler ana bilgisayarlardan kaldırılacaktır. Bunu yapmak için, sembolik adları vpn-slice'a argüman olarak iletmeniz gerekir. Bunun gibi.
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 Artık her şey hem ofiste hem de sahilde çalışmalı.
VPN tarafından verilen DNS'deki tüm alt alan adlarının adreslerini arayın
Ağda az sayıda adres varsa, hosts dosyasını otomatik olarak değiştirme yaklaşımı oldukça işe yarar. Ancak ağda çok fazla kaynak varsa, o zaman sürekli olarak zoidberg.test.evilcorp.com gibi satırları komut dosyasına eklemeniz gerekecektir. zoidberg, test tezgahlarından birinin adıdır.
Ancak artık bu ihtiyacın neden ortadan kaldırılabileceğini biraz anladık.
VPN'i yükselttikten sonra /etc/hosts dosyasına bakarsanız bu satırı görebilirsiniz.
192.168.430.534 dns0.tun0 # vpn-slice-tun0 OTOMATİK OLUŞTURULDU
Ve resolv.conf'a yeni bir satır eklendi. Kısacası vpn-slice bir şekilde vpn için dns sunucusunun nerede bulunduğunu belirledi.
Artık evilcorp.com ile biten bir alan adının IP adresini bulmak için Linux'un kurumsal DNS'ye gittiğinden ve başka bir şeye ihtiyaç duyulursa o zaman varsayılan DNS'ye gittiğinden emin olmamız gerekiyor.
Uzun bir süre Google'da arama yaptım ve bu tür işlevlerin Ubuntu'da kutudan çıktığı gibi mevcut olduğunu gördüm. Bu, adları çözümlemek için yerel DNS sunucusu dnsmasq'ını kullanma yeteneği anlamına gelir.
Yani, Linux'un IP adresleri için her zaman yerel DNS sunucusuna gitmesini sağlayabilirsiniz; bu sunucu da alan adına bağlı olarak ilgili harici DNS sunucusunda IP'yi arayacaktır.
Ubuntu, ağlar ve ağ bağlantılarıyla ilgili her şeyi yönetmek için NetworkManager'ı kullanır ve örneğin Wi-Fi bağlantılarını seçmek için kullanılan grafik arayüz bunun yalnızca bir ön ucudur.
Yapılandırmasına tırmanmamız gerekecek.
- /etc/NetworkManager/dnsmasq.d/evilcorp'ta bir dosya oluşturun
adres=/.evilcorp.com/192.168.430.534
Evilcorp'un önündeki noktaya dikkat edin. Bu, dnsmasq'a evilcorp.com'un tüm alt alan adlarının kurumsal DNS'de aranması gerektiğinin sinyalini verir.
- NetworkManager'a ad çözümlemesi için dnsmasq kullanmasını söyleyin
Ağ yöneticisi yapılandırması /etc/NetworkManager/NetworkManager.conf dosyasında bulunur. Buraya eklemeniz gerekir:
[ana] dns=dnsmasq
- NetworkManager'ı yeniden başlatın
service network-manager restartArtık, openconnect ve vpn-slice kullanarak bir VPN'e bağlandıktan sonra, vpnslice argümanlarına sembolik adresler eklemeseniz bile ip normal şekilde belirlenecektir.
VPN aracılığıyla bireysel hizmetlere nasıl erişilir?
VPN'ye bağlanmayı başardıktan sonra iki gün boyunca çok mutlu oldum ve sonra VPN'ye ofis ağı dışından bağlanırsam postanın çalışmadığı ortaya çıktı. Belirti tanıdık değil mi?
Maillerimiz mail.publicevilcorp.com adresinde bulunmaktadır yani dnsmasq kuralına girmemektedir ve mail sunucu adresi public DNS üzerinden aranmaktadır.
Ofis hala bu adresi içeren DNS'yi kullanıyor. İşte bu düşündüğüm şey. Aslında satırı dnsmasq'a ekledikten sonra
adres=/mail.publicevilcorp.com/192.168.430.534
durum hiç değişmedi. ip aynı kaldı. İşe gitmem gerekiyordu.
Ve ancak daha sonra, durumu daha derinlemesine araştırıp sorunu biraz anladığımda, akıllı bir kişi bana sorunu nasıl çözeceğimi söyledi. Posta sunucusuna sadece bu şekilde değil, VPN aracılığıyla bağlanmak gerekiyordu
VPN üzerinden 192.168.430 ile başlayan adreslere gitmek için vpn-slice kullanıyorum. Ve posta sunucusunun evilcorp'un alt alanı olmayan sembolik bir adresi olduğu gibi 192.168.430 ile başlayan bir IP adresi de yok. Ve elbette genel ağdan kimsenin kendisine gelmesine izin vermiyor.
Linux'un VPN üzerinden posta sunucusuna gidebilmesi için onu vpn-slice'a da eklemeniz gerekir. Diyelim ki postanın adresi 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 Tek argümanla VPN'yi yükseltmek için komut dosyası
Bütün bunlar elbette pek uygun değil. Evet, metni elle yazmak yerine bir dosyaya kaydedip konsola kopyalayıp yapıştırabilirsiniz, ancak yine de pek hoş değil. İşlemi kolaylaştırmak için komutu PATH'de bulunacak bir komut dosyasına sarabilirsiniz. Daha sonra yalnızca Google Authenticator'dan aldığınız kodu girmeniz gerekecektir.
#!/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 Komut dosyasını connect~evilcorp~'a koyarsanız, konsola yazmanız yeterlidir
connect_evil_corp 567987Ancak şimdi bazı nedenlerden dolayı hala openconnect'in çalıştığı konsolu açık tutmanız gerekiyor
Arka planda openconnect'i çalıştırma
Neyse ki, openconnect yazarları bizimle ilgilendi ve programa özel bir anahtar ekledi -background, bu da programın başlatıldıktan sonra arka planda çalışmasını sağlar. Bu şekilde çalıştırırsanız, başlattıktan sonra konsolu kapatabilirsiniz.
#!/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 Artık günlüklerin nereye gittiği belli değil. Genel olarak günlüklere gerçekten ihtiyacımız yok, ancak bunu asla bilemezsiniz. openconnect onları sistem günlüğüne yönlendirebilir, burada güvende tutulacaklar. komuta –syslog anahtarını eklemeniz gerekir
#!/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 Ve böylece, openconnect'in arka planda bir yerde çalıştığı ve kimseyi rahatsız etmediği ortaya çıktı, ancak bunun nasıl durdurulacağı belli değil. Yani, elbette grep kullanarak ps çıktısını filtreleyebilir ve adı openconnect içeren bir işlemi arayabilirsiniz, ancak bu bir şekilde sıkıcıdır. Bunu düşünen yazarlara da teşekkür ederim. Openconnect'in, openconnect'e işlem tanımlayıcısını bir dosyaya yazması talimatını verebileceğiniz bir -pid dosyası anahtarı vardır.
#!/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-pidArtık bir işlemi her zaman komutla öldürebilirsiniz
kill $(cat ~/vpn-pid)Eğer herhangi bir işlem yoksa kill küfür eder ama hata atmaz. Dosya orada değilse, o zaman da kötü bir şey olmayacak, böylece betiğin ilk satırında işlemi güvenli bir şekilde sonlandırabilirsiniz.
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-pidArtık bilgisayarınızı açabilir, konsolu açabilir ve Google Authenticator'dan gelen kodu ileterek komutu çalıştırabilirsiniz. Daha sonra konsol çivilenebilir.
VPN dilimi olmadan. Son söz yerine
VPN dilimi olmadan nasıl yaşanacağını anlamanın çok zor olduğu ortaya çıktı. Çok okumak ve Google'da araştırma yapmak zorunda kaldım. Neyse ki, bir sorunla bu kadar çok zaman geçirdikten sonra, teknik kılavuzlar ve hatta man openconnect heyecan verici romanlar gibi okunuyor.
Sonuç olarak, yerel komut dosyası gibi vpn-slice'ın yönlendirme tablosunu ağları ayıracak şekilde değiştirdiğini öğrendim.
Yönlendirme tablosu
Basitçe söylemek gerekirse, bu, ilk sütunda Linux'un gitmek istediği adresin neyle başlaması gerektiğini, ikinci sütunda ise bu adreste hangi ağ bağdaştırıcısının geçeceğini içeren bir tablodur. Aslında daha çok konuşmacı var ama bu özü değiştirmiyor.
Yönlendirme tablosunu görüntülemek için ip rota komutunu çalıştırmanız gerekir.
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 Burada her satır, bir adrese mesaj göndermek için gitmeniz gereken yerden sorumludur. Birincisi, adresin nerede başlaması gerektiğinin açıklamasıdır. 192.168.0.0/16'nın adresin 192.168 ile başlaması gerektiği anlamına geldiğini nasıl belirleyeceğinizi anlamak için IP adresi maskesinin ne olduğunu Google'da aramanız gerekir. dev'den sonra mesajın gönderilmesi gereken bağdaştırıcının adı gelir.
VPN için Linux sanal bir adaptör yaptı - tun0. Hat, 192.168 ile başlayan tüm adreslerin trafiğinin içinden geçmesini sağlar
192.168.0.0/16 dev tun0 scope link Komutu kullanarak yönlendirme tablosunun mevcut durumuna da bakabilirsiniz. rota -n (IP adresleri akıllıca anonimleştirilmiştir) Bu komut, sonuçları farklı bir biçimde üretir ve genellikle kullanımdan kaldırılır, ancak çıktısı genellikle İnternet'teki kılavuzlarda bulunur ve onu okuyabilmeniz gerekir.
Bir rotanın IP adresinin nereden başlaması gerektiği Destination ve Genmask sütunlarının birleşiminden anlaşılabilir. IP adresinin Genmask'taki 255 sayısına karşılık gelen kısımları dikkate alınır, ancak 0'ın olduğu kısımlar dikkate alınmaz. Yani, Hedef 192.168.0.0 ve Genmask 255.255.255.0'ın birleşimi, adres 192.168.0 ile başlıyorsa isteğin bu rotayı takip edeceği anlamına gelir. Hedef 192.168.0.0 ancak Genmask 255.255.0.0 ise 192.168 ile başlayan adreslere yapılan istekler bu rotayı izleyecektir.
VPN-slice'ın gerçekte ne işe yaradığını anlamak için tabloların önceki ve sonraki durumlarına bakmaya karar verdim.
VPN'yi açmadan önce böyleydi
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 wlp3s0Openconnect'i vpn-slice olmadan çağırdıktan sonra bu hale geldi
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 tun0Ve bunun gibi vpn-slice ile birlikte openconnect'i çağırdıktan sonra
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 tun0Vpn dilimini kullanmazsanız, openconnect'in, özellikle belirtilenler dışındaki tüm adreslere vpn aracılığıyla erişilmesi gerektiğini açıkça yazdığı görülebilir.
İşte burada:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0Orada, yanında, Linux'un geçmeye çalıştığı adresin tablodaki herhangi bir maskeyle eşleşmemesi durumunda kullanılması gereken başka bir yol hemen belirtilir.
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0Burada zaten bu durumda standart bir Wi-Fi adaptörü kullanmanız gerektiği yazılmıştır.
Yönlendirme tablosunda ilk yol olduğu için VPN yolunun kullanıldığına inanıyorum.
Ve teorik olarak, bu varsayılan yolu yönlendirme tablosundan kaldırırsanız, dnsmasq openconnect ile birlikte normal çalışmayı sağlamalıdır.
Denedim
route del defaultVe her şey işe yaradı.
İstekleri vpn-slice olmadan bir posta sunucusuna yönlendirme
Ancak 555.555.555.555 adresli bir posta sunucum da var ve ona da VPN aracılığıyla erişilmesi gerekiyor. Buna giden rotanın da manuel olarak eklenmesi gerekir.
ip route add 555.555.555.555 via dev tun0Ve şimdi her şey yolunda. Yani vpn-slice olmadan da yapabilirsiniz ancak ne yaptığınızı iyi bilmeniz gerekir. Şimdi yerel openconnect betiğinin son satırına varsayılan rotanın kaldırılmasını ve vpn'ye bağlandıktan sonra posta göndericisi için bir rota eklemeyi düşünüyorum, böylece bisikletimde daha az hareketli parça olur.
Muhtemelen bu sonsöz birisinin VPN'in nasıl kurulacağını anlaması için yeterli olacaktır. Ancak neyi, nasıl yapacağımı anlamaya çalışırken, yazarın işine yarayan ama nedense işime yaramayan pek çok rehber okudum ve bulduğum tüm parçaları buraya eklemeye karar verdim. Böyle bir şeye çok sevineceğim.
Kaynak: habr.com