Mac'te VPN utun arabirimi açık ama trafik geçmiyor mu? ifconfig'i kontrol edin

VPN'e bağlandınız, ifconfig çalıştırdınız ve üzerinde adres olan bir utun4 girdisi buldunuz. İhtiyacınız olan site hâlâ zaman aşımına uğruyor. Bu boşluk normaldir: liste bir sanal arabirimin var olduğunu kanıtlar, istemcinizin ona sahip olduğunu, önemsediğiniz rotanın onu seçtiğini veya paketlerin içinden geçtiğini değil. Bir şey kurmadan önce bile üç utun girdisi olan bir dizüstünde yanlış tüneli suçlayarak geçirdiğim bir öğleden sonradan sonra arabirim adına güvenmeyi bıraktım.

Bir utun satırı gerçekte ne içerir

Tam resmi istediğinizde ifconfig -a çalıştırın. Argümansız çağrıldığında, ifconfig yalnızca şu anda açık olan arabirimleri yazdırır, bu yüzden başlayamayan bir tünel insanların biletlere yapıştırdığı çıktıdan eksik olabilir. ifconfig -l yalnızca adları döndürür ve bağlandıktan sonra yeni bir utun görünüp görünmediğini anlamanın en hızlı yolu budur.

Tek bir arabirimi okumak, yararlı ayrıntının yaşadığı yerdir ve bağlı bir tünel genellikle şöyle görünür.

utun4: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
    inet 10.8.0.6 --> 10.8.0.5 netmask 0xffffffff
    inet6 fe80::ce81:b1c:bd2c:69e%utun4 prefixlen 64 scopeid 0x15

Yanıtı üç alan taşır. UP ve RUNNING çekirdeğin arabirimi kullanmaya istekli olduğunu söyler. POINTOPOINT artı --> eş adresi fiziksel bir bağlantının değil, bir tünelin imzasıdır. mtu değeri "bağlanır, sonra takılır" türünden raporların bütün bir sınıfını açıklar, çünkü utun arabirimleri genellikle düşürülmüş bir MTU ile açılır, birkaç macOS sürümünde 1380, ve istemci bunu geçersiz kılabilir. Alan listesi bir kez göz gezdirmek için yeterince kısa, Apple'ın birlikte verdiği ifconfig kılavuzunda.

Arabirimin arkasındaki süreci bulun

ifconfig sahip bir uygulama kavramına sahip değildir. İki VPN istemcisi, bir sistem hizmeti ve geçen haftadan kalan bir tünel bu düzeyde aynı görünen girdiler üretir. Kendi Mac'imde bile, utun0 ile utun3 arasındaki girdiler ben herhangi bir şey yapılandırmadan önce oradaydı; Continuity ve iCloud Private Relay de tünel kullanır ve hiçbiri sizin sorun giderdiğiniz bağlantı değildir.

Sistemde yapılandırma kaydeden tüneller için, scutil --nc list en hızlı ilişkilendirmedir, her yapılandırmayı durumu ve hizmet kimliğiyle yazdırır ve bağlı olan böyle işaretlenir.

scutil --nc list
* (Connected)   5F2A9C10-...   VPN  Work IKEv2

Yapılandırma kaydetmek yerine kendi tünel sürecini çalıştıran istemciler orada asla görünmez. Tunnelblick ve komut satırından bir openvpn örneği bu gruba girer, bu yüzden süreç tablosunu da kontrol edin: ps -Ao pid,comm | grep -i openvpn. Bir süreç tünele sahip olduğunda, utun numarası yalnızca o sürece aittir, başka hiçbir şeye değil.

Rotayı test etmeden önce adresi test edin

Bir arabirim kullanılabilir adresi olmadan açık olabilir. Yalnızca IPv6 profilinde bağlantı yerel fe80:: girdisi görünür ve inet satırında hiçbir şey olmaz, itilen bir adresi uygulayamayan istemci de tam olarak aynı şekli bırakır. Hedefiniz IPv4 ise ve tünelin IPv4 adresi yoksa, yönlendirme sorusu zaten çözülmüştür.

MTU ayrı bir kontrolü hak eder, çünkü bu arıza bir boyut sorunu gibi görünmez. Kimlik doğrulaması yapan ve büyük bir aktarım başlar başlamaz sessizleşen bir bağlantı gibi görünür. Parçalanmaması gereken bir sonda gönderin, paket arabirimin MTU'suna uyacak boyutta olsun; MTU 1400 ise yük 1372 bayttır:

ping -D -s 1372 10.8.0.5

Bir yanıt, o boyuttaki paketlerin tünelden geçtiği anlamına gelir. Küçük pingler başarılıyken sessizlik MTU'ya ya da yolda ICMP'yi düşüren bir şeye işaret eder, kimlik doğrulamaya değil, o siz bir arabirim elde etmeden önce tamamlanmıştı.

Hedefin tüneli seçtiğini kanıtlayın

Önemli soru utun4 var mı değil, belirli bir adrese giden trafiğin oradan çıkıp çıkmadığıdır. route -n get bunu tek bir hedef için yanıtlar ve kullanacağı ağ geçidini ve arabirimi yazdırır:

route -n get 203.0.113.20
  gateway: 10.8.0.5
  interface: utun4

Aynı komut en0 bildirirse, split tunneling yapılandırmanız kendisine söyleneni yapıyor ve ne kadar arabirim incelemesi yaparsanız yapın bu değişmez. netstat -rn -f inet kullanın varsayılan rotaya ve tüm tabloya tek bir bakışta ihtiyaç duyduğunuzda.

Paketlerin gerçekten hareket edip etmediğine sayaçlar karar verir. netstat -ib utun girdileri dahil arabirim başına paket ve bayt toplamlarını bildirir; sayılar birikimlidir, bu yüzden aralık bırakarak iki kez okuyun ve karşılaştırın:

netstat -ib | grep utun4

Uygulama yeniden denemeye devam ederken donmuş sayaçlar çekirdeğin arabirime hiç paket vermediği anlamına gelir. Uygulama hâlâ başarısızken sayaçlar iki yönde de artıyorsa, soruşturma tünelin öteki ucuna taşınır.

Hiç utun görünmediğinde

Başarılı görünen bir oturum açmadan sonra arabirim listesi boşsa, bu genellikle tünelin hiç başlamadığı anlamına gelir, ifconfig onu gizlediği değil. İstemcinin kendi durumunu, sonra sisteminkini kontrol edin: hiç onaylanmamış veya macOS'un bir güncellemeden sonra devre dışı bıraktığı bir Network Extension arkasında arabirim bırakmaz. Onay System Settings içinde Login Items & Extensions altındadır ve oradaki eski bir girdi, bir şeyi yeniden kurmadan önce yeniden açılıp kapatılmaya değer.

utun numaralandırması yeniden bağlanmalar arasında kararlı değildir. On dakika önce utun5 olan yerde utun4 alabilirsiniz, çünkü eski arabirim sökülür ve çekirdek sıradaki boş dizini verir. Adı sabit kodlayan betikler o anda sessizce bozulur; bunun yerine adrese veya rotaya eşleştirin.

Okuma tarafını salt okunur tutun. sudo ifconfig utun4 down tüneli keser ve tam tünel profilinde uzak oturumunuzu da götürür, bu da yalnızca kanıt toplamaya çalışırken kötü bir takastır. Burada ihtiyacınız olan hiçbir şey root gerektirmez: bayrakları, adresleri ve sayaçları okumak normal kullanıcınızla çalışır.

Bir Mac tüneli bir dahaki sefere kötü davrandığında kontrolleri sırayla yapın: ifconfig -l ile bir utun göründüğünü doğrulayın, bayraklarını, adreslerini ve MTU'sunu okuyun, onu bir sürece atfedin, route -n get ile hedefin hangi arabirimi kullandığını sorun, sonra netstat -ib'ın hareketini izleyin. Her adım farklı bir katmanı eler ve yanlış dönen ilk adım düzeltmenin yeri.