Show HN: Bilgisayarım sunucuma nasıl ulaştı?
(how-did-i-get-here.net)- Bir ziyaretçi web sitesini açtığında sunucu, genel IP hedef alınarak traceroute çalıştırıyor ve paketlerin yönlendiriciler ile ağlar üzerinden izlediği yolu gerçek zamanlı metin gibi gösteriyor
- Özel araç ktr, ICMP paketlerinin TTL değerini kademeli olarak artırarak her hop’tan gelen hata yanıtlarını topluyor ve aynı anda hop bazında ağ bilgilerini sorguluyor
- Ekran güncellemesi JavaScript ile değil, açık HTTP yanıtı üzerinden HTML ve CSS’in sürekli akıtılmasıyla yapılıyor; böylece sayfa yüklenirken sonuçlar kademeli olarak beliriyor
- Gösterilen rota, sunucudan ziyaretçinin IP’sine gönderilen ters traceroute sonucunun ters çevrilmiş hali olduğundan, iki yönlü yönlendirme farkları nedeniyle gerçek rota ile tamamen aynı olmayabilir
- İnternet rotaları, otonom sistemler (AS) arasındaki BGP peering ve yönlendirme tablosu yayılımıyla oluşur; trafik de birbirine bağlı ağlar üzerinden ilerler
Her bağlantıda oluşturulan kişiselleştirilmiş traceroute
- Sayfanın üst kısmındaki yeşil metin, önceden kaydedilmiş bir örnek değil; web sitesi yüklenirken ziyaretçiye özel olarak anında üretilen bir traceroute
- traceroute, ziyaretçinin bilgisayarının ya da paketlerinin internet üzerinden bu web sitesini barındıran sunucuya ulaşma yolculuğunu gösteriyor
- Örnek rota, ziyaretçinin yönlendiricisinden başlayıp ISP ağından geçiyor, çeşitli ağlar üzerinden Hetzner’in dahili ağına giriyor ve ardından sunucuya ulaşıyor
- İlk yönlendirici ping’e yanıt vermeyebilir; bu, ortak kullanılan yönlendiricilerde veya VPN arkasında yaygın bir durumdur
- Arada
(no response)görünebilir ve her sunucu her zaman yanıt vermez
core3.sto.hetzner.comgibi adlar, traceroute’tan çıkan213.239.252.74IP’sine ters DNS sorgusu uygulanarak elde edilen, insanların okuyabileceği adlardır- Ters DNS adları çoğunlukla hata ayıklamayı kolaylaştırmak içindir ve çoğu zaman yeniden özgün IP’ye eşlenmez
ktr ve ICMP tabanlı traceroute
- Web sitesinin uygulanmasında özel traceroute programı ktr kullanılıyor
- Sitenin kaynak kodu da GitHub üzerinde açık
- ktr, sonuçları gerçek zamanlı olarak akıtırken her hop bilgisini eşzamanlı sorguluyor
- İnternet yönlendirmesinde paketleri işleyen bilgisayar ya da yönlendirici, bir sonraki iletim cihazını seçer; bu süreç, doğrudan hedefe gönderebilen bir yönlendiriciye ulaşılana kadar sürer
- ktr uygulaması ICMP kullanıyor
- ICMP, internette tanılama bilgisi göndermek için tasarlanmış bir protokoldür
- İnternete bağlı cihazların neredeyse tamamı ICMP’yi destekler
- ICMP paketlerindeki TTL (time to live) alanı gerçek zaman değil, geri sayım değeridir
- Bir yönlendirici ICMP paketini her ilettiğinde TTL’yi 1 azaltmalıdır
- TTL 0 olduğunda yönlendirici paketi iletmeyi bırakır ve azami hop sayısına ulaşıldığını belirten bir hata mesajını özgün kaynak IP’ye gönderir
- traceroute, TTL değeri 1, 2, 3 şeklinde giderek artan ICMP paketleri göndererek her hop’tan dönen hata yanıtlarını toplar
- Hata paketleri, hatayı gönderen cihazın IP adresi gibi tanılama bilgileri içerir
- Bu sayede internet üzerinden geçen yaklaşık paket rotası izlenebilir
JavaScript olmadan gerçek zamanlı görünen ekran
- Sayfa, JavaScript devre dışıyken de çalışıyor
- Tarayıcı açısından bakıldığında web sitesi yavaş yükleniyormuş gibi görünür
- Kullanıcı açısından ise traceroute gerçek zamanlı olarak beliriyormuş gibi görünür
- Bağlantı kurulduğunda sunucu, ziyaretçinin IP adresinden gelen HTTP isteğini alır ve hemen bu IP’ye doğru traceroute çalıştırır
- Sunucu önce HTTP yanıtının ilk kısmını gönderir, sonra bağlantıyı açık tutar
- ktr, traceroute güncellemelerini sunucuya iletir
- Sunucu ilgili HTML’i render eder ve ziyaretçinin bilgisayarına gönderir
- traceroute bittiğinde kalan metin ve web sitesi içeriği gönderilir, ardından bağlantı kapatılır
- traceroute satırlarının aşağıdan değil de yukarıdan kademeli güncelleniyormuş gibi görünmesinin nedeni CSS blok ekleme tekniğidir
- Web sayfaları temelde yalnızca ileri doğru yüklenebilir
- Her traceroute görünümü güncellemesinde önceki görünümü gizleyen CSS de birlikte eklenir
- Tarayıcı yükleme sırasında CSS’i render ettiği için ekran zaman içinde düzenleniyormuş gibi görünür
Ters traceroute’un sınırlamaları
- Sayfanın gösterdiği rota, “ziyaretçinin paketlerinin sunucuya ulaştığı rota” ile tamamen aynı değildir
- Gerçek rotayı hesaplamak için ziyaretçinin bilgisayarından sunucuya traceroute çalıştırabilmek gerekir
- Uygulama, sunucudan ziyaretçinin bilgisayarına traceroute çalıştırıp ardından sonucu ters çevirerek gösterir
- Bu yüzden üstteki traceroute ters sırada yükleniyormuş gibi görünür
- Ters traceroute, doğruluğun bir kısmından fedakârlık eder
- Paketler ters yönde ilerlediğinde her cihaz farklı yönlendirme kararları verebilir
- Tek bir cihazın farklı karar vermesi bile sonraki rotayı değiştirebilir
- Yine de rota kabaca benzerdir; fark çoğunlukla belirli bir yönlendiricinin paketi görüp görmediği düzeyindedir
Otonom sistemler ve WHOIS sorguları
- traceroute’ta görünen “ağlar”, otonom sistemleri (AS) ifade eder
- AS, özel olarak birbirine bağlı yönlendirici ve sunucuların kümesidir
- Genellikle aynı şirkete aittir
- AS sahipleri, hangi diğer AS’lerle bağlantı kuracaklarını seçerek internetin şeklini belirler
- İnternet trafiği, aralarında peering anlaşması bulunan AS’ler üzerinden ilerler
- İnternet açık bir ağ gibi görünse de gerçekte şirketlerin sahip olduğu ağların ağıdır; erişim ve kontrol finansal işlemler ile bürokratik süreçlere bağlıdır
- Kendi otonom sisteminizi istiyorsanız beş bölgesel internet kayıt kuruluşu (RIR) kurumundan birine ASN başvurusu yapabilirsiniz
- Bir şirket desteğiniz yoksa veya yeterli internet bağlantı noktanız bulunmuyorsa kabul edilmeniz zordur
- traceroute’taki
AS4766gibi sayılar ASN’dir
- ktr, her hop IP’sinin ait olduğu AS bilgisini almak için WHOIS protokolünü kullanır
- Çeşitli kuruluşlar, hangi AS’nin hangi IP adreslerini kapsadığını takip eder
- Birçok kuruluş WHOIS üzerinden ASN sorgusu sunar
- Şirket bilgisini anlamak için PeeringDB de kullanılır
- PeeringDB, tüm otonom sistemlerin yaklaşık üçte biri hakkında bilgi içerir
- Sorgu sonuçları ve yüzlerce satırlık if ifadesi birlikte kullanılarak ağ geçişi açıklamaları üretilir
- WHOIS protokolü belirtimi yapıyı neredeyse hiç tanımlamaz
- Temelde bir TCP bağlantısı açıp sorguyu göndermeniz, sunucunun bilgiyi döndürmesi ve ardından bağlantıyı kapatması tarif edilir
- Gerçek WHOIS yanıt yapısı, daha çok sunucu yöneticilerinin oluşturduğu bir geleneğe benzer; gerekli alan adları da
origin,originasgibi değişebilir - ktr’nin ayrıştırıcısı, katı bir parser’dan çok, bir insanın WHOIS çıktısını okuyup gerekli ASN’yi bulma biçimine yakındır
BGP’nin internet rotalarını oluşturma biçimi
- Ağ sınırındaki yönlendiriciler, paketin sıradaki hangi ağa gönderileceğine karar verir ve bu süreç hedef cihazın bulunduğu ağa ulaşılana kadar devam eder
- Bu sınır yönlendiricileri, Border Gateway Protocol (BGP) üzerinden birbirlerine ulaşılabilir ağ bilgisi aktarır
- BGP, internetin şeklini oluşturan protokoldür
- Son kullanıcılar doğrudan BGP konuşamaz
- BGP’nin ilk sürümü, 1989’da Cisco ve IBM mühendislerinin yayımladığı RFC 1105 belgesinde tanımlandı
- 1969’daki ARPANET prototipinde bir mesaj kısmen iletildikten sonra, çeşitli üniversiteler, devlet kurumları ve şirketler kendi ağlarını kurup birbirine bağlamaya başladı
- 1990’da BGP v2 yayımlandı
- 1994’te BGP v4, RFC 1654 olarak belirlendi
- BGP v4, 1995 ve 2006’da revizyonlar ve yamalar aldı; modern internette birbirine bağlı ağların rota seçiminde hâlâ kullanılıyor
BGP rotaları, peering ve yönlendirme tabloları
- Otonom sistem sınırlarındaki yönlendiriciler olan border gateway’ler, bildikleri tüm BGP rotalarının listesi olan bir yönlendirme tablosu tutar
- Her BGP rotası, belirli bir IP adresi kümesini yöneten AS’ye ulaşmak için izlenebilecek bir ASN yolu belirtir
- BGP rotaları, AS’ler arasındaki peering ilişkileri üzerinden oluşur
- İki AS’nin border gateway’leri peer olduğunda, iki yönlendirici arasında trafik geçebilir
- Ayrıca bildikleri BGP rota bilgilerini güncel biçimde paylaşırlar
- Örnek olarak AS0001’deki Router A ile AS0002’deki Router B fiziksel olarak bağlanıp peering kurmak istiyorsa, BGP oturumu oluşturmak için BGP mesajları alışverişi yapar
- Router A, AS0002 ile başlayan BGP rotalarına Router B üzerinden gitmesi gerektiğini öğrenir
- Router B de ters yöndeki bilgiyi öğrenir
- Peer’ler, route advertisement süreciyle bildikleri rotaları paylaşır
- Router A, Router B’ye bildiği tüm rotaları duyurursa, Router B yönlendirme tablosuna AS0001 ile başlayan rotaları ekler
- Router A’nın başka bir peer’i yeni rota duyurursa, Router A bunu Router B’ye de iletir
- Bu duyurular tüm AS ağına yayıldıkça her border gateway, internetteki herhangi bir IP’ye ulaşmak için bir veya daha fazla AS path bilir
- Bir yönlendirici belirli bir IP’ye paket göndereceğinde, yönlendirme tablosunda o IP’yi yöneten AS’ye giden rotayı arar
- Ardından çeşitli sezgisel kurallarla “en iyi” rotayı seçer
- Bu sezgiseller arasında en kısa rotayı arama ve belirli AS’lere yönelik sabit tercih ya da kaçınmalar bulunur
- Yönlendirici, paketi seçilen rotadaki ilk AS ile peering yapan gateway router’a gönderir
traceroute sonuçlarını BGP açısından okumak
- Örnek traceroute’taki AS path şu şekildedir: AS4766 → AS201011 → AS24940
- Bir noktada paket, AS4766’daki yönlendiricilerden birine ulaşmış ve bu yönlendirici AS201011’deki bir yönlendiriciyle peering kurmuş durumdadır
- Yönlendirici, yönlendirme tablosuna bakarak hedef IP’ye AS201011 ile başlayan rota üzerinden ulaşılabildiğine karar verir
- Sonrasında paketi bağlı olduğu AS201011 yönlendiricisine gönderir
- Aynı ASN içinde birden fazla hop görünebilir
- Hetzner Online içinden geçen altı hop örneğinde olduğu gibi traceroute, yalnızca AS sınır yönlendiricilerini değil, paketin geçtiği tüm yönlendiricileri gösterir
- Bir AS içindeki yönlendiriciler, verimli bir iç rota biliyorlarsa dış BGP rotaları yerine bunu tercih edebilir
- İç rotalar, internal BGP, başka iç yönlendirme protokolleri veya sabit tanımlarla öğrenilmiş olabilir
- İnternette erişilebilirliği belirleyen asıl unsur, iç hop’lar değil; farklı AS’ler arasındaki peering anlaşmalarıdır
1 yorum
Hacker News görüşleri
Merhaba, ben Lexi. 17 yaşındayım ve son zamanlardaki ilgi alanım bilgisayarların nasıl çalıştığını daha derinlemesine anlamak ve bunu yeni yollarla göstermek.
Birkaç ay önce https://cpu.land sitesini yayımladım; ilgili tartışma da https://news.ycombinator.com/item?id=37062422 adresinde.
cpu.land’den sonra bir başka devasa iş çıkarmam gerektiğine dair üzerimde büyük bir baskı vardı ama beni özellikle çeken bir fikir yoktu. Bu yüzden çeşitli kişisel projelerle uğraşırken, internetin nasıl çalıştığını tesadüfen öğrenme sürecinde, sonuçları bir web sitesine gerçek zamanlı olarak akıtan bir traceroute programını sıfırdan yaptım.
Web’de bu biçimde bir şey görmemiştim; internet yapısını görselleştirmenin oldukça yeni ve havalı bir yolu olduğunu düşündüm, bu yüzden onu cilalayıp güzel bir siteye dönüştürdüm.
Bu süreçte BGP ve internet yapısı hakkında birçok ilginç şey öğrendim; bu yüzden traceroute aracını ve bu bilgileri paylaşan yazıyı birleştirdim.
Hâlâ üzerinde çalışıyorum ve kodun bir yerlerde mutlaka kırılacağı kesin; önerileriniz varsa duymak isterim.
Ek olarak, neden Rust derseniz: programlama dili seçiminin çok kritik olduğunu düşünmüyorum ama güvenilir, düşük seviyeli bir programı hızlıca yazmak istedim ve Rust’ın hata işleme temel bileşenlerini sevdim.
Neredeyse 30 yıl önce yaptığım ilk CGI programlarından biri, traceroute’u Perl ile sarmalayıp sonuçları server push ile akıtan bir betikti.
Eski şeyler yeniden yeni olur; yine de sitenin sunumu çok iyi.
Bu arada IPv4 TTL hukuken saniye cinsindendir ama hiçbir yönlendirici 1 saniyeden fazlasını tüketmez ve en küçük azaltma değeri 1 olduğu için pratikte hop sayısı olarak kullanılır. Gizli kalmak isteyen middlebox’lar ise hiç azaltmayabilir.
Ayrıca Linux/Unix traceroute, keşif paketleri için varsayılan olarak ICMP yerine yüksek numaralı, genelde kapalı bir porta giden UDP kullanır; çünkü tarihsel olarak UDP’nin ICMP’ye kıyasla düşürülme veya filtrelenme olasılığı daha düşüktü.
traceroute’un nasıl çalıştığını sormak mülakat sorularımdan biri; çoğu kişi bilmiyor, bilseler bile soru değerini biraz kaybediyor. TCP/IP hakkında ne kadar soru sorulursa sorulsun çoğu kişi ilk ilkelerden akıl yürütemiyor; yine de bunu çözebiliyor mu diye bakmak makul bir problem çözme sorusu bence.
Ör: https://www.bgplookingglass.com/
https://www.oreilly.com/openbook/cgi/ch06_06.html
ICMP yerine TCP veya UDP kullanırsan daha doğru sonuçlar alıp alamayacağını merak ediyorum. Geleneksel traceroute’un da UDP seçeneği var; mtr [1] TCP veya UDP kullanabiliyor, tcptraceroute [2] ise TCP kullanabiliyor.
Ayrıca Talking Heads alıntısı koymak için biçilmiş kaftan: “And you may ask yourself, well, how did I get here?” [3]
[1] https://github.com/traviscross/mtr
[2] https://linux.die.net/man/1/tcptraceroute
[3] https://en.wikipedia.org/wiki/Once_in_a_Lifetime_(Talking_He...
Şimdi tek yapmam gereken, belirli bir iş istasyonundan şirketin Cisco erişim switch’ine, core switch’e, AWS transit gateway’e giden BGP tüneline ve oradan da EC2 instance’ının VPC yönlendirme tablosuna ulaşana kadar her hop’ta traceroute’u nasıl çalıştıracağımı çözmek; o zaman kendime ağcı diyebilirim sanırım.
Ne yazık ki çok fazla node traceroute paketlerini yok saydığı için yalnızca çıkış node’um Linode’a bağlanmış, Linode da senin bilgisayarına bağlanmış gibi göründü.
İleri yöndeki traceroute’ta da benzer şekilde yönlendirici yanıt veriyor, sunucu yanıt veriyor; şanslıysan ISP ağından bir node kadarını görüyorsun. Geri kalanı sıkı sıkıya kapalı.
“BGP internetin biçimini veren protokoldür ve onunla doğrudan konuşamazsınız” demişsin ama aslında bireylerin ASN alıp BGP konuşması şaşırtıcı derecede kolay.
Böyle araçlar yapmak ilgini çekiyorsa denemeye değer. İlgilenirsen daha önce yazdığım bir başlangıç yazısı da var: https://qt.ax/asn
Bu, “benim bilgisayarımın senin sunucuna nasıl ulaştığı”ndan çok, senin sunucunun benim bilgisayarıma nasıl ulaştığının ters yönüne daha yakın. İki yönlü yönlendirme çoğu zaman epey farklı olabilir.
Özetle, benim deneyimime göre geçilen ağlar genellikle çok benzerdi ve hangi yönden bakılırsa bakılsın içerik ilgili ve ilginç.
traceroute’un nasıl çalıştığıyla ilgili ilginç olabilecek bir makale var. Ağ alanından gelmeyenlerin sıkça gözden kaçırdığı nokta, traceroute’un mutlaka simetrik olmadığı. Dönüş yolu farklı olabilir
https://archive.nanog.org/sites/default/files/traceroute-201...
Bu, şimdiye kadar internette gördüğüm ECMP sayısının iki katı sayılabilir
Ayrıca Kahire ofisinden Birleşik Krallık çekirdeğine giden trafik ile ters yöndeki trafik de farklı rotalar izliyor. London→Cairo doğrudan ve hâlâ çok fazla kayıp var, ama Cairo→London artık ntt üzerinden gidiyor ve iyi görünüyor. Yarına kadar düzelmezse local preference’ı değiştirmek zorunda kalabiliriz
“WHOIS, parser yazmak için ilginç bir protokol” denmiş ama pratikte imkânsıza yakın
Yanıtlar doğası gereği serbest biçimli ve sunucu yanıt vermeyebilir bile. Ben de denedim; 10 yıl önceki duruma göre adreslerin ya da domain’lerin %90’ında çalışan geçici bir parser yazabilmiştim ama geri kalanını işlemek mümkün değildi
Bugün durum daha da kötüleşti; neredeyse her şey gizlilik korumasının arkasına saklanmış durumda. PII’yi koruduklarını iddia ediyorlar ama WHOIS kayıtları aslında kişisel bilgi değil, ağ operatörü iletişim bilgisi içermek üzere tasarlanmıştı
Bence bu ICANN’in suçu. ICANN’in ağların herkese açık WHOIS sunucuları sağlamasını gerektiren bir kuralı vardı ama bunu uygulamadı; şimdi de o kuralı kaldırdı
Yine de her yer RDAP sunucusu işletmiyor. ICANN/IANA ya da biri bunu zorunlu kılsa iyi olurdu
Ağ operatörü bilgisi de PII olabilir. Benim bilgilerim PII ve bir domain adına sahip olduğum için bilgilerimi WHOIS’e koymak, PII’yi WHOIS’e koymak demek
Gizlilik hizmeti, spam hariç her şeyi bana iletmekten ibaret
Şirketler için gizlilik hizmetine izin vermek adına iyi bir neden görmüyorum, ama tüm domain’ler henüz büyük şirketlere ait değil
Ayrı bir ICMP ECHO izleme yerine, istemci tarayıcısı ile web sunucusu arasındaki mevcut HTTP TCP bağlantısından yararlanılırsa bir adım daha ileri gidilebilir
Böylece istemci tarafındaki NAT’ı veya stateful güvenlik duvarını aşabilir
reverse traceroute hakkında daha önce yapılmış çalışmalar var
https://research.cs.washington.edu/networking/astronomy/reve...
Makale: http://www.cs.washington.edu/homes/ethan/papers/reverse_trac...
Video: http://www.usenix.org/multimedia/nsdi10katz-bassett
Bir TCP oturumunun paketlerinin internetten geçerken çoğu zaman asimetrik rotalar izlediğini de bilmekte fayda var. Benim deneyimime göre en yaygın nedenler maliyetle ilgili iş kuralları ve insan hatalarıydı
IP’nin nasıl çalıştığını düşününce bu kendi başına özellikle sorun değil, ama yönlendirmeyi anlamayı zorlaştırabiliyor
Boise State University ile University of Idaho, Idaho eyaletinin iki ucundaki okullar. Kuzeydeki UIdaho, Spokane’e yakın ve bağlantılarının çoğu Seattle’dan geliyor; Boise ise Salt Lake tarafına yakın olduğu için çoğu zaman Portland veya Salt Lake City üzerinden bağlanıyor
İki okul arasındaki eyaletin orta kısmı dağlık olduğundan büyük ölçekli bağlantı neredeyse yoktu; ama eskiden UofIdaho’nun güney bölgede uzaktan eğitim sınıfları olduğu için küçük bir hat vardı
90’ların sonlarında bir noktada BSU ağ mühendisi ile UofI mühendisi, aynı binada switch ve yönlendirme ekipmanı bulundurduklarını fark edip aralarına bir Ethernet kablosu çekti
Sonuç felaketti. İki ağ birbirine BGP duyurmaya başladı ve bu bağlantı tüm internete ilan edildi. Bir anda Seattle tarafındaki ağlar ile Salt Lake City tarafındaki ağlar arasında çok kısa bir sıçrama oluştu ve o zavallı küçük T1 hattı tamamen doldu
İlginç şekilde bu yalnızca tek yönde oldu. Boise rotayı duyuruyordu ama Idaho duyurmuyordu; bu yüzden trafik fiilen sadece tek yönde bozuldu
Doğal olarak kablo çekildi ve yıllar sonra UofIdaho’da çalışırken bile iki ağın asla tekrar bağlanmaması gerektiği herkesçe biliniyordu. İronik olarak o dönemde ben iki üniversiteye I2 kurmaya yönelik bir program yürütüyordum
Benim cihazımda cihazımla sunucu arasındaki ara adımlar hiç görünmüyor. Bilgi olarak
Şu anda üzerinde çalışıyorum ve yakında daha iyi çalışmasını umuyorum. Bu arada timeout’u artırdım; yükleme daha uzun sürecek ama daha iyi çalışacak
mtr de anılmaya değer. Ben traceroute’tan çok daha sık kullanıyorum
Aralıklı paket kaybını teşhis etmeye yardımcı olur ve akışı ortalama olarak kavramanızı sağlar
APNIC’in bu yazısı mtr’yi ve sonuçlarının nasıl okunacağını daha ayrıntılı açıklıyor; ayrıca MPLS’in gerçek yolu nasıl bulanıklaştırabileceğini de ele alıyor
https://blog.apnic.net/2022/03/28/how-to-properly-interpret-...
UDP ile izleme yapmak da bazen işe yarar; birçok yönlendiricinin yük altındayken ICMP’yi seçici olarak düşürdüğünü bilmekte de fayda var
İyi bir yazı, anlatımı da harika