Tünel kapalı, ama makine hâlâ açıkmış gibi davranıyor: bir sorgu zaman aşımına uğrayana kadar asılı kalıyor ve bir rota artık var olmayan bir arayüze işaret ediyor. Bu, bağlantı kesme yardımcısını çalıştırmadan ölen bir openconnect sürecinin imzasıdır. Oluşturduğu ağ durumu hâlâ kurulu ve sistemdeki başka hiçbir şey onu nasıl kaldıracağını bilmiyor.

Makineyi durumun oluşturulduğu sırayla dolaşın: süreç, bağlantı, rota, çözümleyici. Her adım istemcinin gerçekten gittiğini mi yoksa yalnızca terminalinizden mi koptuğunu söyler ve bu ayrım bir şeyi onarıp onarmayacağınıza karar verir.

Yapılandırmayla değil, süreçle başlayın

Bir rotaya dokunmadan önce bir terminal açın ve neyin hâlâ çalıştığını sorun. pgrep -a openconnect her örneği bağımsız değişkenleriyle listeler, bu da pid dosyasını ve ona verilen betiği gösterir. Beklemediğiniz bir süreç, hayalet tüneli herhangi bir günlükten daha hızlı açıklar.

Hiçbir şey çalışmıyorsa bağlantıya bakın. ip link show tun0 arayüzün hayatta kalıp kalmadığını söyler ve ip route show dev tun0 hâlâ ona bağlı olan rotaları listeler. Ardından çözümleyiciyi şununla denetleyin resolvectl status. Değiştirmeden önce üç çıktının hepsini not edin, çünkü o kayıt daha sonra eski bir girdiyi yeniden ayırt etme yolunuzdur.

Kaybolan bir arayüz genellikle rotalarını yanında götürür. Bağlantıdan sonra kalan rotalar genellikle sürecin hâlâ canlı olduğu veya cihazın ikinci bir istemciye ait olduğu anlamına gelir.

Değişiklikleri geri alan şey yardımcı betiktir

openconnect arayüzü, rotaları veya çözümleyici girdilerini kendisi kaldırmaz. Harici bir yardımcı çağırır, /etc/vpnc/vpnc-script bir upstream derlemesinde ve /usr/share/vpnc-scripts/vpnc-script Debian ve Ubuntu paketlerinde, şununla seçilir -s. Tüneli kuran betik onu söken betiktir.

Süreç o yardımcıyı çağırmadan çıkarsa durum kalır. OpenConnect kılavuzu betik olmadan yönlendirme ve ad hizmetinin düzgün çalışmayacağını açıkça belirtir ve yardımcıyı çıkışta arayüz durumunu söken bileşen olarak tanımlar. Bu yüzden istemciyi şununla başlattığınızda yol önemlidir -s.

O yola hangi sinyalin ulaştığı sürümler arasında değişti. 7.06 kılavuzu SIGTERM'i betiği atlayan anlık çıkış olarak ele alır. Güncel derlemeler INT ve TERM'i oturumun kapatıldığı ve yardımcının çalıştığı temiz bir duruş olarak belgeler. İki davranıştan birini varsaymak yerine gerçekten sahip olduğunuz ikili dosyanın SIGNALS bölümünü okuyun.

man openconnect | sed -n '/^SIGNALS/,/^LIMITATIONS/p'

Derlemenizin belgelediği sinyali gönderin

Sinyali bildiğinizde süreci kalıpla değil pid ile durdurun.

pgrep -a openconnect
sudo kill -INT "$(cat /var/run/openconnect.pid)"

Ardından çıkış durumuna güvenmek yerine birinci bölümdeki üç denetimi yineleyin. ip link show tun0 başarısız olmalı, ip route show dev tun0 hiçbir şey yazdırmamalı ve resolvectl status artık VPN bağlantısını listelememelidir.

SIGHUP bir durdurma düğmesi değildir: bağlantıyı keser, betiği çalıştırır ve oturumu şununla sürdürülebilir bırakır --cookie. SIGUSR2 anında yeniden bağlanmayı zorlar. SIGKILL temizliği tamamen atlar ve bu makalenin konusu tam olarak bu durumdur.

resolv.conf dosyasını değiştirmeden çözümleyiciyi onarın

Çoğu Ubuntu sisteminde /etc/resolv.conf systemd-resolved'e giden bir sembolik bağlantıdır, düzenlemeniz gereken bir dosya değildir. Onu değiştirmek yalnızca VPN için değil her ağ için ad çözümlemesini bozar. Bunun yerine tünelin kaydını kaldırın:

resolvectl revert tun0
resolvectl query example.com

Sistem systemd-resolved yerine resolvconf kullanıyorsa, arayüz başına kayıt bağlantıyı bırakması söylenene kadar kalır ve resolvconf -d tun0 eşdeğer eylemdir. Komutu seçmeden önce hangi çözümleyicinin kullanıldığını denetleyin.

Ölü bağlantının arkasındaki bir sunucuya hâlâ yönelen sorgu zaman aşımına uğrayana kadar asılı kalır ve bu gecikme kalan bir rotadan çok bozuk bir DNS sunucusu gibi görünür.

Bir sonraki bağlantı kesmeyi sıkıcı yapın

Başlangıçta ve kapanışta pid dosyasının yolunu aynı tutun, şunu her seferinde --pid-file vererek veya openconnect'i bir unit altında çalıştırın ve onun KillSignal sürümünüzün belgelediği sinyalle eşleşsin. Önce ön planda test etmek, yardımcının yazdırdığı kapatma iletilerini gösterir.

Bağlanın, bağlantıyı kesin ve üç denetimi bir kez çalıştırın. Temiz bir çıkış ne VPN bağlantısı, ne VPN rotası ne de VPN çözümleyici girdisi bırakır. Üçünden biri hayatta kalırsa artık hangi bileşenin temizleyemediğini biliyorsunuz. Sonraki inceleme o zaman asılı kalan bir sorgudan değil, bu yanıttan başlar.

İlgili makaleler