Tinyproxy’de Listen, Bind ve BindSame: hangi adres kazanır

Vekil yanıt verir, istek tamamlanır ve yine de hedef hâlâ LAN adresini kaydeder. Vekil günlüğünde hiçbir şey yanlış görünmüyor ve değiştirdiğiniz satır, belgelerin değiştirmenizi söylediği satırın ta kendisi. Hem LAN adresi hem tünel adresi olan bir ana bilgisayarda hangi adresin nerede görüneceğine üç yönerge karar verir ve bunlardan yalnızca biri giden tarafla ilgilidir. Yanlış sırada okursanız sebepsiz yere yönlendirme tablosuna düşersiniz.

Belirti: hedef LAN adresini görüyor

Bir istemci LAN adresinde vekile bağlanır ve vekil hedefe kendi bağlantısını açar. Bu ikinci bağlantı, çekirdeğin kurallarına göre bir kaynak adres seçer ve varsayılan olarak rota aramasının seçtiği adres olur. Bu nedenle her bayt vekilden geçse de hedef, ana bilgisayarın birincil adresini kaydeder. İletme açısından hiçbir şey bozuk değildir ve vekil günlüğünün bu konuda söyleyecek sözü olmamasının nedeni budur.

Bu hatanın ayna görüntüsünü fark etmek daha kolaydır: giden kaynağı tünel adresine sabitleyin, LAN istemcileri dinleyiciye hiç ulaşamaz. O sürüm kendini duyurur, ilki ise çalışan bir isteğin arkasına saklanır. İkisi de tek bir yönergeyi iki soruyu birden yanıtlıyormuş gibi ele almaktan kaynaklanır.

Üç yönerge, üç farklı adres

Listen, vekil istemcilerini kabul eden yerel adresi adlandırır. Bind, vekilin dışarıya kurduğu bağlantılar için bir kaynak adres sağlar ve BindSame ona az önce kabul ettiği bağlantının yerel adresini yeniden kullanmasını söyler. Bunlar üç ayrı sorudur ve tek bir satır yalnızca birini yanıtlar. Bunları karıştırmak, bir değişikliğin hiçbir şey yapmıyormuş gibi görünmesinin olağan nedenidir.

Kurulu sürümle gelen açıklamalı yapılandırmayı okuyun, çünkü varsayılanlar ve kabul edilen sözdizimi sürümler arasında değişir. Projenin örnek yapılandırması her yönergeyi diğerlerinin yanında belgeler. O dosyayı disktekiyle karşılaştırın, başka bir dağıtım için yazılmış bir kılavuzla değil.

Dinleyiciyi ve giden kaynağı ayrı ayrı ayarlayın

LAN adresi 192.168.50.10, tünel adresi 10.90.0.3 olan bir ana bilgisayar alın. LAN istemcileri vekile ulaşacak ama istekleri tünelden çıkacaksa, bunlar iki bağımsız karardır ve ikisi de yazılmalıdır. Aşağıdaki parça tam olarak bunu ifade eder, başka bir şeyi değil.

Listen 192.168.50.10
Bind 10.90.0.3
BindSame no

Bu tam bir yapılandırma değildir, bu yüzden onaylanmış bağlantı noktasını, kimlik doğrulamayı, istemci erişim denetimlerini ve hedef kısıtlamalarını koruyun. İki adres de Tinyproxy’nin ağ ad alanı içinde bu ana bilgisayara ait olmalıdır, çünkü sürecin sahip olamadığı bir Bind değeri başlangıçta değil, bağlanırken başarısız olur. BindSame yes başka bir politikayı anlatır; kabul edilen bağlantının yerel adresi giden kaynak olur. Güncel sürümlerde bu dal Bind listesinden önce gelir ve yapılandırılmış kaynak tam da böyle, hata vermeden kaybolur.

Kaynağın ima ettiği rotayı denetleyin

Kaynak adres seçmek bir yol oluşturmaz, bu yüzden çekirdeğe o kaynak ve o hedefle ne yapacağını sorun. Tünel arabirimini adlandıran arama asgari kanıttır ve LAN arabirimini adlandıran arama, kaynağın yazıldığı gibi çalışamayacağı anlamına gelir. Arama bağlamsaldır: o ad alanında geçerli politika kurallarını ve tabloyu değerlendirir. Bu bir bağlantı değildir ve akış aşağısındaki bir NAT’ın hizmete ne sunacağı hakkında hiçbir şey söylemez.

ip -4 route get 203.0.113.25 from 10.90.0.3

Örnekte belge amaçlı bir adres kullanın ve test etmeye yetkiniz olan hizmetle değiştirin. Vekil bir konteynerde çalışıyorsa aramayı vekilin ad alanı içinde yürütün, çünkü ana bilgisayarın kuralları sürecin gördüğü kurallar değildir. Amaçlanan tünel rotası yoksa, vekil ana bilgisayarına hedefe özel kurallar eklemek yerine ağ sahibinin bunu düzeltmesini sağlayın. Aramanın başarılı olması için ana bilgisayar rotalarını temizlemeyin ve sunucunun ittiği rotaları devre dışı bırakmayın; eski bir kılavuz bunu yapmış olsa bile, çünkü bu tür değişiklikler tek bir vekil yolunu onarmak için ana bilgisayarın onaylanmış VPN davranışının tamamını kaydırır.

Kaynağı hedefte doğrulayın

Kaynağı isteğin geldiği yerde okuyun, gittiği yerde değil. Hedefin uygulama günlüğü veya önündeki uç aygıt, gerçekte gördüğü adresi kaydeder; vekil ise yalnızca ne amaçladığını söyleyebilir. Değişiklikten sonra amaçlanan dinleyici üzerinden bir yeni istek gönderin, çünkü önbellekteki bir bağlantı yeni bağlama hakkında hiçbir şey kanıtlamaz. Ardından kaydedilen adresi yapılandırdığınız adresle karşılaştırın.

ss -ltnp | grep tinyproxy
curl -x http://192.168.50.10:8888 https://example.com -o /dev/null -sS

curl yalnızca trafik üreticisidir; doğrulanmaya değer adres, uzak tarafın kaydettiği adrestir, curl’ün tesadüfen bağlandığı eş değil. İkisi uyuşmuyorsa farkın kaynak seçiminden mi yoksa daha ilerideki bir dönüşümden mi geldiğine karar verin, çünkü bunlar farklı yerlerde düzeltilir. Adres değişikliklerini ve vekil yeniden başlatmalarını birlikte planlayın, çünkü tünelin artık tutmadığı bir adresi bağlamak yeniden bağlanmadan sonra sessizce başarısız olur. DNS ve IPv6 davranışını da ayrı tanımlayın, çünkü yukarıdaki IPv4 parçası ikisi hakkında da hiçbir şey kanıtlamaz.