Tailscale neden yavaş çalışır: DERP ve doğrudan bağlantı

Tailscale neden yavaş: doğrudan bağlantı yerine aktarmalı (relayed) bağlantı

Tailscale bağlantısı, paylaşımlı DERP sunucularından biri üzerinden aktarıldığında yavaş çalışır; doğrudan bağlantı kurulduğunda ise hat kapasitesine yakın bir hız sunar. Doğrudan bağlantı, şifrelenmiş WireGuard paketlerini bir makineden diğerine doğrudan iletir; bu nedenle hız, iki internet bağlantısının taşıyabileceği maksimum kapasiteyle sınırlıdır. Aktarmalı bağlantı ise her paketi önce üçüncü bir makineye gönderir; bu durumda bağlantı, o makinenin gecikme süresine ve size ayrılan bant genişliği payına tabi olur. Bunun maliyeti, kullanılan aktarıcıya göre değişir. Tailscale, DERP sunucularının "genellikle doğrudan bağlantılardan daha yavaş" olduğunu belirtirken, kendi çalıştırdığınız bir eş aktarıcının (peer relay) "genellikle DERP'ten daha hızlı" olduğunu ve Tailscale'in ilk testlerinde "doğrudan bağlantı hızına yaklaşan" bir verim sağladığını ifade eder. Tailscale'in kendi performans sayfası, genel kuralı tek bir cümleyle özetler: "Doğrudan bağlantılar neredeyse her zaman daha düşük gecikme ve daha yüksek verim sağlar."

Uygulamanızın içinde bu farkı gösteren bir belirti yoktur. Dosya kopyalama işlemi sadece yavaş gerçekleşir, SSH oturumu ise gecikmeli çalışır. Bu nedenle ilk adım, mevcut bağlantı türünüzü tespit etmektir. İki komutla bir dakikadan kısa sürede bu bilgiye ulaşılabilir ve sonrasındaki tüm işlemler, bağlantı sorununu gidermeye yöneliktir. Başlamadan önce kurulum kısmını bilmek önemlidir; çünkü koordinasyon sunucusu ile WireGuard veri düzlemi ayrı sistemlerdir ve verilerinizi yalnızca veri düzlemi taşır.

Doğrudan ve aktarmalı bağlantıyı ayırt eden iki komut

Herhangi bir ölçüm yapmadan önce eşe (peer) bir miktar trafik gönderin. Tailscale, yolu talep üzerine oluşturur; bu nedenle bugün iletişim kurmadığınız bir eş henüz bir yol belirlememiş olabilir ve eski bir veriyi okuyor olabilirsiniz. Eşin tailnet adresine bir adet ping veya bir adet curl göndermek yeterlidir.

tailscale status

Cevap, her eş satırının sonundadır.

100.113.160.82 device-a  tagged-devices linux   active; offers exit node; direct 203.0.113.9:41641
100.104.93.78  device-b  you@           android active; relay "tor"

Bir adres ve portu takip eden direct, paketlerin doğrudan o adrese gittiği anlamına gelir. relay "tor", Tailscale'in aktarma makinelerinden biri olan bir DERP (designated encrypted relay for packets) sunucusunu belirtir ve o eşe giden her paket bu sunucu üzerinden geçer. Üçüncü bir değer olan peer-relay, bir sonraki bölümde ele alınmıştır.

tailscale ping device-b

Sağlıklı bir bağlantı aktarmalı başlar ve ardından doğrudan bağlantıya geçer. İlk paketler, iki makine müzakere ederken en yakın DERP sunucusundan geçer ve ardından yol sizin bilginiz dışında değişir:

pong from device-b (100.113.160.82) via DERP(tor) in 51ms
pong from device-b (100.113.160.82) via DERP(tor) in 48ms
pong from device-b (100.113.160.82) via 203.0.113.9:41641 in 35ms

Çalıştırma işlemi orada durur çünkü --until-direct varsayılan olarak true değerindedir. Doğrudan bağlantı kurulamayan bir bağlantı ise bunun yerine şu şekilde görünür ve bir pong yerine bir cümle ile biter:

pong from device-b (100.104.93.78) via DERP(tor) in 53ms
pong from device-b (100.104.93.78) via DERP(tor) in 60ms
direct connection not established

Son satır bulgudur. Bu, Tailscale'in göndermeyi planladığı tüm deneme paketlerini gönderdiği ve hiçbir zaman doğrudan bir yol bulamadığı anlamına gelir. İlk doğrudan bağlantıda durmak yerine aktarmalı bir yolu izlemeye devam etmek için tailscale ping --until-direct=false -c 20 device-b komutunu çalıştırın ve gecikme dağılımını okuyun. Aktarmalı bir yol genellikle hem daha yüksek sayılar hem de daha fazla değişkenlik gösterir; çünkü bu, kontrolünüzde olmayan bir makinede birleştirilmiş iki internet yoludur.

Tailscale status çıktısındaki peer-relay ne anlama gelir?

Peer relay, doğrudan bağlantının imkansız olduğu durumlarda diğer üyeler için trafiği aktaran, kendi tailnet ağınızdaki bir makinedir. Seçtiğiniz bir UDP portunu dinler ve daemon, bu portu DERP yerine tercih eder. tailscale status böyle bir bağlantıyı işaretler, peer-relay ise tailscale ping rölenin uç noktasını yazdırır:

pong from device-b (100.97.143.93) via peer-relay(203.0.113.42:40000:vni:1) in 4ms
direct connection not established

Bunu dikkatle inceleyin. Bu hala doğrudan bir bağlantı değildir, bu nedenle çalışma hala direct connection not established ile biter. Değişen şey, aktarımı kimin yaptığıdır. Genel bir IP adresine ve yüksek bant genişliği kapasitesine sahip bir VPS, kendi trafiğiniz için paylaşımlı bir DERP düğümünden çok daha iyi bir röledir; sunucu kiralayan herkes için bu durumun önemli olmasının nedeni budur. Bunu, temiz bir genel uç noktaya sahip makinede etkinleştirin:

sudo tailscale set --relay-server-port=40000

0 portu rastgele kullanılmayan bir port seçer, boş bir dizge ise röle sunucusunu devre dışı bırakır. Ardından, tailnet politika dosyanızdaki tailscale.com/cap/relay yeteneği ile istemci cihazlara bunu kullanma izni verin:

{
  "grants": [
    {
      "src": ["tag:us-east-vpc"],
      "dst": ["tag:us-east-relays"],
      "app": {
        "tailscale.com/cap/relay": []
      }
    }
  ]
}

Hem röle cihazının hem de istemci cihazların Tailscale 1.86 veya daha yeni bir sürüme sahip olması gerekir, bu nedenle politika dosyasıyla uğraşmadan önce her birinde tailscale version ile sürüm kontrolü yapın. Daemon'ın denediği sırayı ezberlemekte fayda vardır. İlk olarak doğrudan bağlantıyı dener. Eğer bu başarısız olursa, kullanmasına izin verilen bir peer relay arar. Eğer hiçbiri yoksa, DERP'e geri döner. DERP hiçbir zaman tamamen devre dışı kalmaz, çünkü iki makinenin en başta birbirleriyle iletişim kurmasını sağlayan kanal da odur.

Neden 1: UDP trafiğini engelleyen bir çıkış güvenlik duvarı

Tailscale, bir bağlantının neden aktarmalı (relayed) kaldığına dair iki temel neden belirtir; bunlardan ilki engellenen UDP trafiğidir. Makineye doğrudan sorgu gönderin:

tailscale netcheck

Rapor burada kısaltılmıştır; en üstteki alan belirleyici olan kısımdır:

Report:
  * UDP: true
  * IPv4: yes, 203.0.113.9:41641
  * IPv6: no
  * MappingVariesByDestIP: false
  * PortMapping:
  * Nearest DERP: Dallas

UDP: false elde edebileceğiniz en güçlü ipucudur. Bu, makinenin Tailscale'in yoklama sunucularına bir UDP paketi gönderemediği anlamına gelir. Tailscale'in kendi CLI referansına göre, bu durumda "Tailscale'in noktadan noktaya bağlantı kurabilmesi pek olası değildir." Trafik bu durumda TCP 443 portu üzerinden DERP protokolüne aktarılır. Makinenin dışarıdan bakıldığında tamamen sağlıklı görünmesinin nedeni bu yedekleme mekanizmasıdır: makine bağlıdır, erişilebilirdir ve tüm veriler aktarılmaktadır. netcheck herhangi bir bağlantıdan ziyade ağın genel durumunu tanımlar; bu nedenle kuralları değiştirmeye başlamadan önce bir eşin (peer) gerçekten hangi yolu kullandığını tailscale status veya tailscale ping ile doğrulayın.

Belgelenmiş iki adet giden kuralı mevcuttur. "İç ağdaki cihazlarınızın :41641 ile *:* arasında UDP başlatmasına izin verin" (bu WireGuard trafiğinin kendisidir) ve "İç ağdaki cihazlarınızın *:3478 adresine UDP başlatmasına izin verin" (bu, makinenin kendi genel IP adresini ve portunu öğrenmek için kullandığı STUN protokolüdür). Hedefler için joker karakterler kullanın. Tailscale zaman içinde yeni aktarma sunucuları ekler; elle yazılmış bir adres listesi bir yıl içinde geçersiz kalacaktır.

Kiralanan bir sunucuda genellikle karşılaşılan sorun, ya hazır bir imajda devralınan ya da servis sağlayıcınızın yukarı akışta uyguladığı kısıtlayıcı bir çıkış politikasıdır. Öncelikle varsayılan giden trafiği kontrol edin:

sudo ufw status verbose
sudo nft list ruleset

Default: deny (incoming), allow (outgoing) normaldir ve sorununuz değildir. Varsayılan giden kuralının deny olması ve yalnızca TCP 443 ile DNS'e izin veren kısa bir liste içermesi, sunucunun sürekli aktarma modunda kalmasına neden olan tipik bir yapılandırmadır; çünkü TCP 443 üzerinden giden DERP yolu bu kısıtlamadan geçerken, doğrudan bağlantı yolu engellenir. Bu kuralların nerede bulunduğu, sunucunun arka planda iptables mı yoksa nftables mı çalıştırdığına bağlıdır; yanlış olanı düzenlemek hiçbir değişikliğe yol açmaz.

Gelen trafik tarafı da önemlidir; çünkü bir VPS genel bir IP adresine sahiptir ve bu nedenle eşleşmenin kolay olan tarafı olabilir. Eğer güvenlik duvarınız, tailscaled servisinin dinlediği port üzerinden gelen UDP trafiğini kabul ediyorsa, karmaşık ev yönlendiricilerinin arkasındaki eşler, herhangi bir ek işleme gerek kalmadan sunucuya ulaşabilir. Gerçekte kullanılan portu bulun:

sudo ss -lunp | grep tailscaled
sudo ufw allow 41641/udp

41641 varsayılan statik porttur. randomizeClientPort ayarı açık olan bir tailnet'te istemciler rastgele bir port seçer; bu durumda gerçek port numarasını bu sayfadan değil, ss çıktısından alın. Ardından servis sağlayıcınızın kontrol panelini kontrol edin. Çoğu sağlayıcı, sunucunun içindeki güvenlik duvarından bağımsız bir ağ güvenlik duvarı çalıştırır ve ufw ile eklediğiniz bir kural, bu dış katmanda hiçbir etki yaratmaz.

Neden 2: Her iki uçta veya bir uçta katı NAT

Belgelenen ikinci neden katı NAT'tır. NAT (ağ adresi çevirisi), bir yönlendiricinin özel adresinizi genel adresine dönüştürürken yaptığı işlemdir. Dost canlısı bir yönlendirici, kiminle konuştuğunuzdan bağımsız olarak belirli bir dahili soket için aynı genel portu korur; buna uç noktadan bağımsız eşleme denir. Katı bir NAT ise her hedef için farklı bir genel port atar; bu nedenle makinenin bir STUN sunucusundan öğrendiği adres, bir eşin kullanabileceği adresle aynı olmaz. Tailscale bunu netcheck içinde MappingVariesByDestIP: true olarak raporlar.

Tek bir katı NAT aşılabilir. Eğer karşı tarafın kararlı bir genel uç noktası varsa, katı NAT arkasındaki makine yine de bağlantı kurabilir ve yol oluşur. Aynı anda iki katı NAT olması durumu başarısızlıkla sonuçlanır, çünkü taraflardan hiçbiri diğerinin hangi portta görüneceğini tahmin edemez.

Genel bir IPv4 adresine sahip bir VPS üzerinde bu alan normalde false değerini göstermelidir. Genel bir adres, hiçbir şeyin onu çevirmediği anlamına gelmez: Örneğin AWS, internet ağ geçidinin bir örneğin genel IPv4 adresi ile özel adresi arasında bire bir NAT gerçekleştirdiğini belgeler. Bunun gibi statik bir bire bir eşleme, kiminle konuşursanız konuşun aynı portu korur; bu nedenle katı NAT değildir ve alan hala false değerini gösterir. Kiraladığınız bir sunucuda true değerini görüyorsanız, sağlayıcının ağındaki bir mekanizma her hedef için farklı bir port atıyordur ve makine içindeki hiçbir güvenlik duvarı kuralı bunu değiştiremez. Seçenekleriniz, temiz bir genel uç noktaya sahip bir makineye bir eş aktarıcı (peer relay) yerleştirmek veya iş yükünü taşımaktır. Bu durum, özel aralıklarınızı bir subnet router üzerinden duyurmanın avantaj sağladığı durumdur; çünkü bu sayede ağdaki her cihaza iyi bir yol bulmak yerine, ağa giren tek bir iyi yola ihtiyaç duyarsınız.

Neden bir exit node, Tailscale'in olduğundan daha yavaş görünmesine neden olur

Bir exit node ikinci bir atlama noktasıdır ve kullanıcılar bu durum için tüneli suçlar. Bir exit node seçildiğinde, istek dizüstü bilgisayarınızdan çıkar, tünel üzerinden VPS'e ulaşır, VPS'ten genel internete çıkar ve yanıt aynı yolu izleyerek geri döner. VPS'e yapılan kusursuz bir doğrudan bağlantı bile toplam hızı, VPS'in kendi uplink kapasitesinden daha yüksek yapamaz; eklenen mesafe ise her sayfa yüklemesinde kendini belli eder.

İki yarısı ayrı ayrı ölçün. Exit node özelliğini kapatın ve ardından tüneli, VPS'in tailnet adresi üzerinden kendi başına test edin:

sudo tailscale set --exit-node=
sudo apt install -y iperf3
iperf3 -s

İstemci üzerinden o tailnet adresine karşı iperf3 -c 100.113.160.82 komutunu çalıştırın. Elde ettiğiniz sayı tünelinizin hızıdır. Şimdi sudo tailscale set --exit-node=100.113.160.82 ile exit node özelliğini tekrar açın ve genel internete yönelik normal bir hız testi yapın. Bu sayı, tüneliniz ile VPS'in uplink hızının toplamıdır. İlk sayı iyi, ikincisi kötüyse sorun Tailscale değildir; bakılması gereken yer exit node'un kendi ağı ve kapasitesidir. Hangi düğümü seçtiğinizden emin değilseniz, tailscale exit-node list komutu size nelerin sunulduğunu gösterir.

CPU, bir exit node'un performans sınırını belirleyen diğer unsurdur. Tailscale'in önerisi, daha fazla çekirdek sayısı yerine yüksek saat hızına sahip güncel bir CPU neslini tercih etmektir; dolayısıyla daha fazla vCPU içeren bir plan burada otomatik olarak daha hızlı sonuç vermez. Yoğun kullanılan paylaşımlı bir sunucuda size vadedilen CPU ile gerçekte aldığınız CPU aynı olmayabilir ve gürültülü komşudan kaynaklanan steal time, sizin tarafınızda hiçbir değişiklik olmamasına rağmen saatlik olarak değişen bir veri aktarım hızı şeklinde kendini gösterir.

Tek ayar düğmesi: rx-udp-gro-forwarding

Tailscale, trafiği yönlendiren makineler, yani çıkış düğümleri (exit nodes) ve alt ağ yönlendiricileri (subnet routers) için geçerli olan tek bir Linux ayarı sunar. Standart bir istemcinin bu ayardan bir kazancı olmaz. Bu ayar için Tailscale 1.54 veya üzeri bir sürüm ile Linux çekirdeği 6.2 veya üzeri bir sürüm gerekir; bu nedenle herhangi bir değişiklik yapmadan önce her ikisini de doğrulayın:

tailscale version
uname -r

Bunlar hazır olduğunda, internete bakan arayüz üzerinde UDP GRO (generic receive offload) yönlendirmesini etkinleştirin:

NETDEV=$(ip -o route get 8.8.8.8 | cut -f 5 -d " ")
sudo ethtool -K $NETDEV rx-udp-gro-forwarding on rx-gro-list off

Ayarların uygulandığını kontrol edin:

ethtool -k $NETDEV | grep -E 'rx-udp-gro-forwarding|rx-gro-list'

rx-udp-gro-forwarding: on ve rx-gro-list: off değerlerini görmelisiniz. Bunun faydalı olmasının nedeni, Tailscale trafiğinin UDP tabanlı olmasıdır; çekirdeğin küçük UDP paketlerini yönlendirme yolu boyunca birleştirilmiş (coalesced) halde tutmasına izin vermek, daemon sürecinin aynı bayt miktarı için daha az sayıda ve daha büyük segment işlemesini sağlar. ethtool -K yeniden başlatma sonrasında kalıcı olmaz, bu yüzden kalıcı hale getirilmelidir. networkd-dispatcher kullanan bir sistemde:

printf '#!/bin/sh\n\nethtool -K %s rx-udp-gro-forwarding on rx-gro-list off \n' "$(ip -o route get 8.8.8.8 | cut -f 5 -d " ")" | sudo tee /etc/networkd-dispatcher/routable.d/50-tailscale
sudo chmod 755 /etc/networkd-dispatcher/routable.d/50-tailscale

Betiği manuel olarak bir kez çalıştırın ve çıkış durumunun 0 olduğunu doğrulayın. Bir yönlendirme düğümünün ayrıca IP yönlendirmesinin etkinleştirilmiş olması gerekir; bu ayrı bir ayardır ve ayrı bir hata kaynağıdır:

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf

tailscale0 arayüzünüz hangi MTU değerini kullanıyor?

Bu sayıyı tahmin etmeyi bırakın ve doğrudan makine üzerinden okuyun:

ip link show tailscale0

Bu çıktıda gördüğünüz mtu değeri, tünelinizin fiilen kullandığı değerdir ve ethernet arayüzünüzün bildirdiği 1500 değerinden daha düşüktür. Bu bir hata değil, bilinçli bir tercihtir. Tünel içinden gönderdiğiniz her paket paketlenir: IPv4 için 20 bayt veya IPv6 için 40 baytlık bir dış IP başlığı, 8 baytlık bir UDP başlığı ve 32 baytlık WireGuard çerçeveleme ve kimlik doğrulama etiketi eklenir. Tüm bunların, gerçek yolun taşıyabileceği boyuta sığması gerekir. Tailscale, PPPoE bağlantıları, bazı mobil ağlar ve IPv6 tünelleri dahil olmak üzere, tam 1500 baytlık paketi taşıyamayan bağlantılarda sorun yaşanmaması için yeterince düşük bir değer seçer.

MTU sorununun belirtisi spesifiktir; bu nedenle sadece yavaşlığa bakarak teşhis koymayın. SSH yanıt veriyorsa, ping çalışıyorsa ancak büyük dosya aktarımları veya kapsamlı HTTPS sayfaları yavaş çalışmak yerine tamamen donuyorsa bir sorun var demektir. Bu durum, aşırı büyük paketlerin bir noktada düşürüldüğü ve göndericiye durumu bildiren herhangi bir ICMP mesajının geri dönmediği anlamına gelir. tailscale0 MTU değerini 1500'e doğru yükseltmek durumu daha da kötüleştirir, çünkü zaten sığmayan paketler daha da büyür. Asıl çözüm, çalışan yol MTU değerini ikiye bölme yöntemiyle bulmak ve trafiği yönlendiren yönlendirici üzerinde TCP MSS değerini sabitlemektir. Bağlantı türü bu durumu değiştirmez: aktarmalı (relayed) bir yol ile doğrudan bir yol aynı arayüz MTU değerini kullanır.

FAQ

Tailscale bağlantımın doğrudan mı yoksa aktarmalı mı olduğunu nasıl anlarım?

tailscale status komutunu çalıştırın ve eşin (peer) satırının sonunu okuyun. direct 203.0.113.9:41641 doğrudan bir bağlantıyı, relay "tor" her paketin ilgili DERP sunucusu üzerinden geçtiğini, peer-relay ise paketlerin kendi tailnet ağınızdaki bir makine üzerinden iletildiğini gösterir. İkinci bir doğrulama için tailscale ping <peer> komutunu çalıştırın: sağlıklı bir yol DERP ile başlar ve ardından düz bir adres ile port içeren bir pong çıktısı verir; aktarmalı bir yolda ise çalışma bitene kadar DERP pong çıktıları alınır ve süreç direct connection not established ile sonlanır. Tailscale yolları yalnızca talep edildiğinde oluşturduğundan, önce eşe bir miktar trafik gönderin.

VPS sunucum neden hiçbir zaman doğrudan bağlantı kuramıyor?

VPS üzerinde tailscale netcheck komutunu çalıştırın. Eğer UDP: false çıktısını alıyorsanız, giden UDP trafiği engelleniyordur; bu durum genellikle bir çıkış güvenlik duvarından kaynaklanır ve Tailscale bu durumda noktadan noktaya bağlantının olası olmadığını belirtir. tailscale status veya tailscale ping komutları ile eşin DERP üzerinde olduğunu doğrulayın; DERP, TCP 443 üzerinden çalıştığı için makine hala bağlı görünür. 41641 numaralı porttan herhangi bir hedefe giden UDP trafiğine ve herhangi bir hedefe 3478 numaralı port üzerinden giden UDP trafiğine izin verin. Sunucu içindeki güvenlik duvarının yanı sıra sağlayıcınızın ağ güvenlik duvarını da kontrol edin; bunlar birbirinden bağımsız kontrollerdir ve bir ufw kuralı, sağlayıcının ayarlarını etkilemez.

Aktarmalı Tailscale bağlantısı, doğrudan bağlantıdan daha mı az güvenlidir?

Hayır. Bir DERP sunucusu, şifresini çözemediği WireGuard paketlerini iletir; çünkü şifreleme anahtarları cihazlarınızda oluşturulur ve cihazlarınızdan asla dışarı çıkmaz. Aktarmanın (relay) maliyeti gizlilik değil, gecikme ve bant genişliğidir. Koordinasyon sunucusunun kontrol ettiği şey, hangi cihazların birbirini göreceğidir; bu nedenle anahtar materyali ile bağlantı meta verileri arasındaki ayrımı, ne kadarını kendi sunucunuzda barındıracağınıza karar vermeden önce anlamanızda fayda vardır.

rx-udp-gro-forwarding ayarı her makineye yardımcı olur mu?

Hayır. Bu ayar, başkaları için trafik yönlendiren Linux makineleri (çıkış düğümleri ve alt ağ yönlendiricileri) için belgelenmiştir. Yalnızca kendi eşleriyle konuşan bir dizüstü bilgisayar veya sunucu bu ayardan bir kazanç sağlamaz. Ayrıca bu ayar Tailscale 1.54 veya üzerini ve Linux kernel 6.2 veya üzerini gerektirir; bu yüzden önce tailscale version ve uname -r ile sürümleri kontrol edin. ethtool -K ayarının, kalıcı hale getirilmediği sürece yeniden başlatma sonrasında sıfırlandığını unutmayın.

Tailscale, standart WireGuard'dan daha mı yavaştır?

Her ikisi de trafiğinizi şifrelemek için WireGuard kullanır. Tailscale, standart WireGuard'da elle yapmanız gereken bağlantı kurulumunu otomatikleştirir; bazen bir aktarıcıya düşmenize neden olan şey de bu kurulum sürecidir. Standart WireGuard'da düşebileceğiniz bir aktarıcı yoktur: ya doğrudan bağlanır ya da hiç bağlanamaz. Bu nedenle benzer yapıları karşılaştırın ve Tailscale performansını yalnızca tailscale status komutu direct çıktısını verdiğinde kıyaslayın. Karşılaştırma için elle yapılandırılmış bir sürüm isterseniz, kendi kuracağınız bir WireGuard sunucusu yaklaşık kırk satırlık bir yapılandırma gerektirir; bu süreçte yaptığınız ödünleşimi iki yaklaşımın karşılaştırması bölümünde bulabilirsiniz.