Yeşil simge, aynı genel IP: VPN hangi yolu atladı

Bağlı, tepsi simgesi yeşil ve adresi gösteren sayfa hâlâ sağlayıcının adresini gösteriyor — bu otomatik olarak arıza demek değildir. İstemci iki ayrı iş yapar: bir tünel kurar ve yönlendirme tablosunu düzenler. Biri diğeri olmadan olabilir ve seçmeli yönlendirme, ikincisinin bilerek atlandığı yapılandırmadır.

İstemci gerçekte ne kurdu

Tünel açık mı diye sormak yerine hangi arayüzün bir paketi gerçek bir hedefe taşıyacağını sorun. O hedef için yolu olmayan bir tünel, kimsenin kullanmadığı özel bir yoldur.

ip route get 9.9.9.9
Find-NetRoute -RemoteIPAddress 9.9.9.9
route print -4

İlk komut Linux ve macOS üzerinde yanıt verir, diğer ikisi Windows için eşdeğeridir ve orada biri yeterlidir. Yanıt fiziksel bağdaştırıcıyı adlandırıyorsa tünel açıktır ve varsayılan yol hiç hareket etmemiştir. Tüneli kullanması gereken bir hedef için kontrolü yineleyin, çünkü iki kontrol, biri uzak biri sıradan, hangi tasarımın dağıtıldığını söyler.

Seçmeli yönlendirmenin üç biçimi

Tam tünel profili genellikle arayüze işaret eden bir varsayılan yol yazar ya da özgün varsayılan tabloda kalırken önek uzunluğunda kazanan yarım aralık öneklerinin çiftini yazar. Seçmeli yönlendirme diğer seçenektir ve birkaç biçimde gelir. Bir profil RDP sunucusu gibi tek bir ana bilgisayarı yönlendirir, bir diğeri belirli bir konumdan erişilmesi gereken genel bir aralığı yönlendirir, üçüncüsü ise bilerek bir uygulamayı dışlar. Üçü de meşrudur ve hiçbiri sıradan bir sitenin gördüğü adresi değiştirmez.

grep -nE "redirect-gateway|route-nopull|route " /etc/openvpn/client/*.conf
ip route show table main | head -20

Karar veren direktif için profili, ardından ürettiği şey için tabloyu okuyun. İtilen bir direktif istemcide de bastırılabilir, bu yüzden sunucuyu suçlamadan önce profil ve tablo uyuşmalıdır.

Karşı taraf kaynak adresi yeniden yazmalıdır

Tarayıcıdan aynı görünen ikinci bir arıza vardır. Yol tünele girer, sunucu paketleri alır ve ardından istemcinin özel adresi bozulmadan iletir. Sonraki atlamanın o adres için dönüş yolu yoktur, bu yüzden yanıtlar kaybolur ve sayfalar takılır. Sunucu her şeye rağmen iletmeli ve kaynağı internetin geri yönlendirebileceği bir şeye çevirmelidir.

sysctl net.ipv4.ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -S | grep MASQUERADE

Gerçekten internete bakan arayüzü adlandırın, bu modern bir dağıtımda her zaman eth0 değildir. Sabit adresli barındırılan bir sunucu, masquerade kullanmak yerine doğrudan o adrese çeviri yapabilir. İki yarı da önemlidir, çünkü çeviri olmadan iletme yönlendirilemeyen kaynakları sızdırır, iletme olmadan çeviri ise paketi hiç görmez.

Ad çözümlemesi kendi yolunu izler

Adı bulan sorgu yerel ağdaki bir çözümleyiciye giderken trafik tünelden çıkabilir. Görünen adres aynı kalır, sorgular kalmaz ve bu boşluk tam olarak bölünmüş DNS tasarımının seçtiği şeydir.

resolvectl status | head -20
resolvectl query example.org

Hangi sunucunun yanıtladığını ve tünel öncesi temelden farklı olup olmadığını not edin. Bölünmüş bir tünelde bu genellikle insanların adres konusunda şikâyet ederken değiştirmek istediği ayardır ve hiç bakmadıkları da odur.

İşi bitiren dört gözlem

Tünel kapalıyken çıkış adresini, sonra açıkken kaydedin. Hedef kontrolünü her iki durumda çalıştırın ve her seferinde arayüzü not edin.

curl -sS https://ifconfig.me/ip
ip route get 9.9.9.9

Kontrol tünelin içine düştüğünde ve yankı hâlâ sağlayıcının adresini bildirdiğinde, çıkışta çeviri yoktur. Kontrol fiziksel bağdaştırıcıya düştüğünde profil seçmelidir ve genel adres hiçbir zaman kapsamda olmamıştır. Yankı hizmetini güvendiğiniz biriyle değiştirin ve dört gözlemi birlikte kaydedin, çünkü ayrı ayrı sadece anekdotturlar. Birlikte, istemcinin iki işten hangisini gerçekte yaptığını gösterirler.