#203 To nie DNS. To był DNS - sieci, o których zapomnieliście po studiach

Szymon Warda: To jest odcinek, w którym Łukasz chciał się pochwalić, jakim bardzo jest dinozaurem. Ping jak działa, to fajnie, niewiele mówi, ale to jak nie działa, to nam tak dużo znowu nie mówi.

Łukasz Kałużny: Tam Quic w większości przypadków wyjściu do internetu jest ubity, ponieważ zaciemnia nam monitoring ruchu.

Szymon Warda: Czemu ten żart wynika z tego, że to nie jest DNS, a to z reguły jest DNS. Z reguły klient trzymający połączenie się często nie dowie, że zostało zerwane.

Łukasz Kałużny: To jest świetne guys, że load balancer nie load balansuje.

Szymon Warda: Cześć, słuchacie Patoarchitektów. Prowadzą Szymon Warda…

Łukasz Kałużny: I Łukasz Kałużny. Dobra, to dziś odcinek, który Szymon bardzo mówi, że AI, AI nas w tym zajebiście zastąpił.

Szymon Warda: Łukasz. Może inaczej, to jest odcinek, w którym Łukasz chciał się pochwalić, jakim bardzo jest dinozaurem.

Łukasz Kałużny: Dobra, to będzie dzisiaj takie czemu to nie działa i czemu to był DNS, czyli sieć dla seniorów. Wszystko co rzekomo powinniście się nauczyć na studiach, a nikt z Was prawdopodobnie nie pamięta w ogóle, że cokolwiek istnieje i potem przeklinacie, że znowu ci niedobrzy sieciowcy zepsuli.

Szymon Warda: Tudzież ja po prostu starałem się wyprzeć i stwierdziłem, że to mi się nigdy nie przyda. Byłem w błędzie. Dobrze Łukaszu, ponieważ chciałeś zacząć od modelu OSI, więc…

Łukasz Kałużny: Słuchaj…

Szymon Warda: Śmigasz.

Łukasz Kałużny: Jedno przypomnieć słuchajcie, że mamy model OSI, który składa się, w wersji akademickiej, z warstw siedmiu.

Szymon Warda: Używa się trzech.

Łukasz Kałużny: Tak, używa się trzech i jest jeszcze warstwa ósma w postaci użytkownika albo tudzież przeglądarki, w zależności jak kto dobija się. Ale to jest taka rzecz, którą przydałoby się pamiętać, że mamy trzy warstwy, z których realnie korzystasz i widzisz tylko dwie na co dzień.

Szymon Warda: 7 warstw, z czego widzisz dwie tak naprawdę.

Łukasz Kałużny: Dwie, czyli widzisz ten koniec i widzisz środek.

Szymon Warda: Czyli widzisz HTTP, HTTP, znaczy widzisz HTTP na najwyższym poziomie. Tam gdzie potrzebujesz, na poziomie aplikacyjnym…

Łukasz Kałużny: Protokół aplikacyjny.

Szymon Warda: Słuszna uwaga. Protokół aplikacyjny, gdzie potrzebujesz mądrze pokierować ruchem. A dla sieciowców widzisz ten poziom TCP/IP, UDP i IP-ki.

Łukasz Kałużny: Tak, czyli warstwa trzecia, to jest IP i CMP i warstwa TCP albo UDP, czyli tego protokołu transportowego.

Szymon Warda: Sobie za chwilę powiemy czemu tego TCP/IP jest coraz mniej.

Łukasz Kałużny: Dobra i zrobiłbym, i tutaj wiesz co, nie ma sensu tutaj przechodzić, teraz nie będziemy przechodzić przez OSI i opowiadać co tam jest. Nie ma sensu.

Szymon Warda: Jest, tyle wygrać.

Łukasz Kałużny: Warto, warto tak naprawdę zapamiętać to, że jest od trzeciej warstwy do góry, czyli że jest IP i one się w sobie zawierają. Jest jak matrioszka.

Szymon Warda: Budują na sobie.

Łukasz Kałużny: Tak, budują na sobie. Czyli IP jest najczęściej tym największym opakowaniem, które znacie i tam w środku coraz bardziej upychamy po kolei elementy. Plus jest dużo zatarć, które się pojawiają.

Szymon Warda: Dobrze, to teraz przejdźmy do sedna, czyli najważniejszego, czyli czemu z reguły to jest DNS?

Łukasz Kałużny: Czy wiesz co, czemu DNS? Może zróbmy jeszcze dwie rzeczy wcześniej, że ping to nie wszystko. Bo zobacz, że taka rzecz i pierwsza rzecz dlaczego mówię, że ping to nie wszystko, bo bardzo dużo osób podchodzi następująco albo sprawdza dostępność w sieciach korporacyjnych czy host żyje pod tytułem zróbmy pinga. I teraz dlaczego o tym mówię? Dużo na przykład usług w chmurze nie odpowie na ping i nic to nie znaczy.

Szymon Warda: Dokładnie. Ale też w sieci lokalnej też coraz więcej jest (…).

Łukasz Kałużny: Tak i druga sprawa, że zgodnie z założeniami bezpieczeństwa ICMP powinno zostać, zawsze być blokowane. I teraz dlaczego powinno być blokowane? Zerknijcie sobie na przykład na GitHuba, który jest wrzucony. Można zrobić VPN over ICMP i w ten sposób wynosić, over ping i w ten sposób wynosić dane. To jest jeden z przypadków.

Szymon Warda: Dorzuciłeś jedną rzecz, czyli ICMP. Żeby było konkretnie, to jest Internet Control Message Protocol, bo to jest ten trzeci protokół koło tych dwóch głównych, można powiedzieć.

Łukasz Kałużny: Tak.

Szymon Warda: Tak rozwiązując skróty.

Łukasz Kałużny: I on odpowiada za bardzo dużo rzeczy związanych z diagnostyką, jak i z wymianą informacji pomiędzy routerami, sprzętem sieciowym, tego co nie oglądacie, tej całej automatyki, która też się dzieje pod spodem. I jak ping nie działa, to zazwyczaj jest wycięty i to trzeba sobie powiedzieć zawsze. Ale mamy potem protokoły TCP i UDP, czyli te warstwy transportowe. I w tym miejscu jak popatrzymy sobie na tooling, to jest to co robimy curlem. Albo mamy Tcping, czyli sprawdzanie czy port jest otwarty TCP czy nasłuchuje. Ewentualnie jak ktoś jest bardziej hardcore’owym dinozaurem, to ma jeszcze Nmapa, który służy do skanowania portów i fingerprintingu.

Szymon Warda: Z takimi określeniami, bo używałem Nmapa, więc to by plasowało mnie jako dinozaura, a nim na pewno nie jestem.

Łukasz Kałużny: Jesteś ode mnie starszy, więc jesteś dinozaurem. Dobra, koniec żartów. Jeżeli teraz popatrzycie na to, to trzeba sobie… Ruch w dzisiejszych sieciach korporacyjnych… Inaczej, bardzo często są próby mikrosegmentacji, czyli otwórzmy tam poola sieci do jakiegoś konkretnego hosta po konkretnym porcie docelowym.

Szymon Warda: Tak, tylko ogólnie upraszczając ping, jak działa, to fajnie, niewiele mówi, ale to jak nie działa, to nam tak dużo znowu nie mówi.

Łukasz Kałużny: Tak, więc w tym miejscu. I rzecz, która się dzieje, to jest nieszczęsny UDP, o którym wspomniałem, czyli kiedyś protokół, który służył do streamingu video, voice’u…

Szymon Warda: Do czatów Łukasz.

Łukasz Kałużny: Do czatów, tak, do wielu rzeczy i on w domyśle nie nasłuchuje.

Szymon Warda: Czy to może uporządkujmy. Różnica między TCP/IP a UDP. TCP nawiązuje stałe połączenie i trzyma ładnie to połączenie między wysyłającym/odbierającym i obydwaj nasłuchują na tą opcję. UDP t o jest: wysyłam wszędzie, może dojdzie.

Łukasz Kałużny: Tak.

Szymon Warda: Że tak powiem tak naprawdę. I tak i dochodzimy do tego, że tak naprawdę kiedyś docelowo było tak, że UDP to była mniejszość mniejszości, można powiedzieć. Główny ruch to był TCP/IP. Czemu? Śmigaliśmy po kabelkach. Potem był taki artykuł, który żeśmy nawet sobie obydwoje przypomnieli, słynny odnośnie Ubera, który mówił, że sorry, oni odchodzą od korzystania z TCP, ponieważ jak idziesz komórką i się przełączasz między wieżami, oczywiście jeżeli chodzi o wieże komórkowe, to po prostu co chwilę tracą połączenie i mają problemy, więc przechodzą na UDP. Potem ruch był właśnie Quic googlowy…

Łukasz Kałużny: Raczej Quic googlowy był wcześniej, to trzeba sobie powiedzieć. Tak Szymon, w 2017, a Uber był 2021, tak.

Szymon Warda: Wcześniej. Możemy się, znajdziemy linki.

Łukasz Kałużny: Znajdziemy, bo mówiliśmy o Uberze w podcaście, więc, a Quic był przed naszym podcastem. Dobra, ale o co chodzi? To, że mamy protokół Quic, jeżeli zobaczycie na HTTP2, HTTP3, to tam była mowa o UDP, że mamy transport over UDP. I teraz Quic ma dwa elementy, które są istotne. Czemu tak się zadziało? Ponieważ to też z researchu między innymi Google i innych rzeczy, że nie ma kontroli nad tym, co dzieje się w internecie i na całej warstwie transportowej, która jest pomiędzy. Nie mamy na to wpływu, ona jest nieaktualizowana, niedostosowywana. I było parę takich elementów. Mamy na przykład protokół od TCP FastConnection, który był w Linuksie na przykład od 2006 roku. Dekadę później wjechał na przykład do Windowsa i w Firefoxie, jak próbowali go włączyć, to go wyłączyli i usunęli, bo okazało się, że większość rzeczy po drodze nie działa.

Szymon Warda: Pamiętajmy, że te czasy, kiedy były, że TCP królował, to były czasy, kiedy mieliśmy kabelki, małą liczbę hopek i tak dalej, i tak dalej. A teraz to też rozmawialiśmy w biurze, ilość hopek, ilość urządzeń, przez które przechodzi nasze połączenie jest naprawdę duża.

Łukasz Kałużny: Tak. I teraz powiedzmy sobie, że… Czyli, i teraz ważne, Quic jest protokołem transportowym, ale on cały czas, jego zaletą pomiędzy TCP, że mamy jeden handshake. Czyli korzysta z UDP i handshake, czyli zestawia i od razu i połączenie z serwerem docelowym oraz szyfrowanie w jednym hopie. Jeżeli popatrzycie na TCP, jak działa TLS, najpierw jest zestawiane połączenie TCP, a potem jest negocjowane on top of, jest negocjowane szyfrowanie i dopiero leci najczęstszy protokół, czyli HTTP po prostu, którego używamy i omijamy. I teraz Szymon, przygotowując się, dwie ciekawostki.

Szymon Warda: Dajesz.

Łukasz Kałużny: Na słabych łączach, na roamingach Quic wygrywa. A jeżeli chodzi o stabilne rzeczy, czyli weźmy Koreę Południową, która ma mega stabilnie rozwiniętą infrastrukturę, to przyspieszyło to o 1,3% na przykład w Google, czyli w Google Chrome, na Androida Googlowi przyśpieszyło to nieznacznie.

Szymon Warda: Bo TCP/IP, jak mamy stałe połączenie i nie mamy przerw i tak dalej, jest szybszy. Tylko że tych połączeń jest coraz mniej, takich sieci domowej.

Łukasz Kałużny: Wiemy, że każdy prosi, więc zostaw nam żebrolajka tutaj gdzie słuchasz, będzie spoko. Dobrze. I teraz przejdźmy sobie do świata korporacyjnego, z którymi najczęściej pracujemy. Tam Quic w większości przypadków w wyjściu do internetu jest ubity, ponieważ zaciemnia nam monitoring ruchu. I jak popatrzymy Palo Alto, Zscaler, Fortinet i wszyscy po kolei checkpoint mówią: UDP na 443 powinien być zablokowany w Twoim ruchu wychodzącym do internetu z hostów, nie powinny mieć w ogóle dostępu.

Szymon Warda: No bo ciężej będzie im te pakiety zebrać w jedną całość i odtworzyć co tam właściwie się stało.

Łukasz Kałużny: W ogóle sprawdzić. Na przykład tracimy SNI, które teraz służy do reguł. Więc to jest jedna z takich istotnych elementów w tym. No i teraz standardowym Haiku Cloudflare’owym to napewno nie jest DNS.

Szymon Warda: To jest DNS.

Łukasz Kałużny: To był DNS.

Szymon Warda: Tak, ale tak patrząc na to jakie problemy my pomagamy rozwiązywać, to często jest DNS i to na bardzo wielu poziomach.

Łukasz Kałużny: Dziwnych. I słuchajcie, i może takie mity i półprawdy. Zacznijmy sobie od jednej najważniejszej - DNS to nie jest tylko UDP na porcie 53, które tak domyślnie. Ponieważ jest TCP na porcie 53 również. I to jest ciekawostka. Jeżeli, bo w dzisiejszych czasach pojawiają się często długie wpisy TXT, jakieś service Discovery w DNS-ie. I DNS, jeżeli pakiet jest za duży na jedną ramkę UDP, to zwraca to poprzez TCP. I to jest taka rzecz dość nieintuicyjna. Druga rzecz pojawia się teraz, jak zobaczycie bardzo dużo rzeczy wokół DNS over HTTPS, DNS over TLS jako dbanie o privacy. Jak sprawdzicie swoje przeglądarki i inne rzeczy to pewnie zobaczycie, że Wasza przeglądarka na przykład nie korzysta z waszego DNS-u providera przykładowo, jeżeli sobie tego nie przekonfigurowaliście. Sprawdźcie telefony, można się zdziwić.

Szymon Warda: Telefony domyślnie mają w ogóle włączone ochronę androidowe przed właśnie wstrzykiwaniem serwera DNS-owego, żeby właśnie nie podszywać się (…).

Łukasz Kałużny: Tak, albo z drugiej strony mamy w Google Privacy, iCloudowe Privacy, więc jest parę takich elementów. Więc to jest taka rzecz, którą trzeba mieć świadomość, że jest to zawsze bardzo nieintuicyjny element, o którym trzeba wiedzieć. I chyba największa rzecz oprócz błędnych wpisów, to będą TTL-e, Time To Leave w cache’u.

Szymon Warda: Doprecyzujmy, o którym cache’u mówisz.

Łukasz Kałużny: No właśnie, którym? Więc słuchajcie, jeżeli teraz popatrzymy, to kiedy Wy sprawdzacie sobie z komputera pięknie digiem, bezpośrednio NSLookupem, to na serwerze, gdzie jest hostowana strefa DNS, czyli są te wpisy, wszystko będzie ok. I jeżeli popatrzymy, to takie warstwy cache, to będzie jakiś, przykładowo w firmie, to są serwery DNS albo DNS proxy które wam cache’ują. Następnie macie cache lokalnie w waszej maszynie, na której pracujecie i możecie mieć cache systemowy albo cache w waszej przeglądarce.

Szymon Warda: Oczywiście albo w aplikacji w ogóle.

Łukasz Kałużny: Albo w niektórych przypadkach w bibliotece w aplikacji.

Szymon Warda: I jeszcze możesz mieć w aplikacji i jeszcze możesz mieć w samym kliencie HTTP, który domyślnie jest tak robiony, że on pobiera wpisy na tworzenie.

Łukasz Kałużny: W .Necie. Czyli w .Necie, jak stworzycie, to wpisy DNS są scache’owane w kliencie.

Szymon Warda: Wydaje mi się, że nie tylko w .Necie. Ale to już nie trzeba mieszać.

Łukasz Kałużny: Mniejsza, tak, ale w tym. I teraz jeżeli sobie na to popatrzycie, to przykładowo te windowsowe magiczne ipconfig/flushDNS może nie rozwiązać Waszego problemu, bo okazuje się, że serwer DNS proxy będzie to trzymał. Przykładowo na Kubernetesach bardzo często zaczęto override’ować ustawienia core DNS-a, żeby zmniejszyć ruch DNS-owy.

Szymon Warda: Bo DNS potrafi być niebanalnym ruchem, że tak powiem.

Łukasz Kałużny: Tak, w tym. I w przypadku przy Kubernetesie tego dużo się pojawiło. I teraz jedna rzecz, na co to ma wpływ, jeżeli popatrzycie przypadki? To są Szymon, to teraz tak, wszystkie zmiany w infrastrukturze publicznej, jak planujecie. Dlatego mówi się o bardzo na przykład tej akcji, że przed dużymi zmianami zmniejszmy DNS-a na 5 minut.

Szymon Warda: Tak.

Łukasz Kałużny: To jest pierwsza rzecz.

Szymon Warda: Time To Leave, żeby się wygasił.

Łukasz Kałużny: Żeby się wygasił, żeby mieć pewność, że przełączenie. I na przykład w przypadku failovera w takim miejscu potrzebujemy, wykorzystujemy DNS do failoveru, potrzebujemy minimum 5 minut na przepięcie.

Szymon Warda: Dokładnie tak.

Łukasz Kałużny: Tak. Druga sprawa, zdarzało się, że niektóre infrastruktury sieciowe override’owały TTL, więc trzeba też mieć tego świadomość, na przykład do godziny. Więc to jest jeden z takich elementów, o których trzeba mieć świadomość przy przełączaniu.

Szymon Warda: Jeszcze odnośnie przełączania, bo tak mówisz odnośnie w ogóle świadomości w DNS-ach, to ja teraz coraz częściej w warstwach aplikacyjnych widzę opcję taką, że coraz częściej klient jako taki nie robi resolve’a DNS-owego na pojedynczym wpisie, tylko mówi: daj mi wszystkie IP-ki pod danym DNS-em. Czemu? Żeby właśnie zrobić client routing na przykład…

Łukasz Kałużny: Client lub balancing.

Szymon Warda: Tak, routing albo balancing, dokładnie tak. Na przykład właśnie do alloya takie rzeczy się robi i tak dalej, żeby jednak mimo wszystko to było bardziej inteligentne. I to są też ciekawe wpisy, które wiele ludzi dziwi. W sensie czemu ta (…) wygląda tak, a nie inaczej.

Łukasz Kałużny: Dobra, teraz mój ulubiony temat z DNS-em w Kubernetesie.

Szymon Warda: No dajesz.

Łukasz Kałużny: Czyli czemu mi nic tam nie działa? I rzecz, o której musicie wiedzieć, Kubernetes ma takie cholerstwo nazwane i w DNS-ie mamy tak zwane ndots notation, czyli ile kropek ma być we wpisie DNS-owym. I ważne, wpisy DNS-owe mają też, mimo, że my w FQDN nie wpisujemy w przeglądarce kropki na końcu, to kropka jest również, tak. I teraz o co chodzi? On sobie po kolei przeszukuje Wasze domeny. Czyli jak robicie wpis w Kubernetesie, to on przykładowo, w zależności od klienta DNS, jaki macie w aplikacji, bądź klienta DNS w Waszym kontenerze, który jest używany systemowo, to on po kolei na przykład sprawdza sobie wszystkie wpisy i dopiero tam gdzie trafi…

Szymon Warda: Szuka tego najdokładniejszego.

Łukasz Kałużny: Szuka najdokładniejszego wpisu, żeby trafić. I teraz o co chodzi? Że rozwiązujecie ileś razy tą rzecz. I była taka ciekawostka, że w Alpine miał inną implementację klienta w kontenerach.

Szymon Warda: Napierdzielanka z tym była.

Łukasz Kałużny: Tak, versus na przykład Debiany czy inne dystrybucje. I to było bodajże przed Alpine 3.1.8, jak mam zanotowane, nie miał też DNS-a pod TCP. Ja miałem sytuację u klientów, że nagle aplikacje nie mogły zresolve’ować jakichś dużych rzeczy, innych elementów. I druga sprawa, że równolegle szły połączenia i szukanie wpisów jako IPv4 i IPv6.

Szymon Warda: Tak, z tym się spotkałem nie raz.

Łukasz Kałużny: Tak, więc trzeba tutaj, więc trzeba tutaj uważać w jaki sposób Wasze aplikacje rozwiązują i co się dzieje jak nie rozwiążą. I dwie ciekawe rzeczy odnośnie chmury Szymon. Bo mamy też limity na wbudowanych DNS-ach w chmurę. Jak się coś zfuckapi, to też było ciekawe. Bo mamy limit, zapytałem, on się wydaje wielki, bo to jest ok, w zależności jak popatrzymy, w Azurze czy w AWS-ie to jest około 1000 requestów na sekundę do DNS-u.

Szymon Warda: To nie jest wcale dużo, jeżeli mamy duży klaster. DNS-y, czemu ten żart wynika z tego, że to nie jest DNS, a to z reguły jest DNS? Z tego powodu, że DNS bardzo łatwo źle skonfigurować i przepięcie z reguły, ten błąd konfiguracyjny widzimy po kilku minutach, co jak powiedziałeś właśnie odnośnie Time To Leave. A czasami nawet w ogóle po dniu, bo coś się scache’owało. Ta liczba zapytań, która się dzieje, jest naprawdę sporawa. I też generalnie ile było sposobów na optymalizację zapytań odnośnie DNS-ów i w ogóle routingu w Kubernetesie? To były ten najczęstszy element zmian, to było chyba z 3,4.

Łukasz Kałużny: I rzecz, którą mi teraz ten piekło przypomniał na przykład teraz przy researchu, było single request reopen. Czyli żeby szybko ten, szybciej się otwierało ponownie.

Szymon Warda: Dobrze, to już zejdźmy może z DNS-u.

Łukasz Kałużny: Nie, jest jeszcze jedna rzecz, którą warto. I to jest dla ludzi od Azure’a… Bo w ogóle inaczej, jedna rzecz, Time To Leave fuckupy to jest to, że poprawicie i dlaczego nadal nie działa? No bo gdzieś jest to scache’owane w większości przypadków. Czyli walnęliśmy błąd. Naprawiliśmy? Nie, nie naprawiliśmy, bo był gdzieś tam. Pamiętam, że u klienta na wdrożeniu 4 godziny czekaliśmy aż się zacznie, zacznie żyć.

Szymon Warda: Znaczy ustalmy, że jak takie rzeczy ruszamy, to jeszcze ruszmy ten temat, że fajnie, że macie load balancing, ale przetestujcie to, bo DNS może Wam to wszystko rozwalić.

Łukasz Kałużny: Dobra. I rzecz dla ludzi azurowych, czyli private endpoint nie działa, a mimo wszystko jest ok. W większości przypadków, a to zaraz sobie powiemy, to pewnie ruch jest albo routing jest skopany. To jest pierwsza rzecz. Drugi element, który trzeba poruszyć to jest to, że Azure DNS i cała infrastruktura private linków działa. Jest oparta na sinamach na common name, czyli skrótach, odniesieniach, referencjach. Jeżeli popatrzymy, czyli jak popatrzycie pod jakąś nazwą, mamy odniesienie do innego DNS, który już celuje w końcu w całej końcówce, kiedyś na IP.

Szymon Warda: No to prywatna IP.

Łukasz Kałużny: I teraz Microsoft, żeby zrobić scenariusz hybrydowy, czyli że łączymy się prywatnie i publicznie, to jeżeli odpytać się publiczny adres DNS owy, to zawsze będzie próbował zwrócić publiczny adres IP tego ich reverse proxy, żeby wejść do tej usługi.

Szymon Warda: Dokładnie tak.

Łukasz Kałużny: I teraz może się okazać, że w korporacyjnej sieci została gdzieś skopana. Na przykład przy nowej usłudze została skopana konfiguracja, bo dołożyliście na przykład teraz, powiedzmy Postgres, a po prywatnych adresach IP przykładowo to jest nowa usługa u was postgres, czy wchodzi jakieś ujmuje dzikie węże, nowy agent AI i znowu też będzie miał jakąś swoją nową strefę i Microsoft. Dopóki nie jest dostępny u Was wpis, który gdzieś kieruje na ten prywatny adres IP, to będzie zawsze Was kierował do publicznego zanim się pojawi. I to jest zmora całości.

Szymon Warda: Raczej niezbędne albo albo do waszej sieci zostało podpięte, żeby tam był resolving.

Łukasz Kałużny: Tak więc to jest rzecz, którą zawsze się pojawia, że odpytujemy się.

Szymon Warda: Ale to jest łatwo sprawdzić. Ogólnie rzecz biorąc, to się zgadza, że czasami, mimo że postawimy właśnie linka, myślimy, że wszystko działa i okazuje się, że dalej śmigamy publicznym i.

Łukasz Kałużny: W 95% przypadków wasz pilot Kodeks. Jak mu powiecie, że nie działa, zdiagnozuje to prawidłowo. Dlaczego nie przechodzi ruch?

Szymon Warda: Doświadczenie jest takie, że radzi sobie naprawdę nieźle.

Łukasz Kałużny: Dobrze.

Szymon Warda: To też powiedziałem. Dobrze. Co jeszcze chciałbyś z innych?

Łukasz Kałużny: Zastanawiam się w tych rzeczach. Chyba routing w chmurze to jest. Trzeba sobie coś powiedzieć. Czego nie oglądacie na co dzień. Ja jestem niestety spaczony tym Szymon, że pomagam przy fakapach.

Szymon Warda: Przy fakapach na poziomie sieciowym. Mam dwie perspektywy sieciowe bardziej i bardziej aplikacyjną.

Łukasz Kałużny: Przy fakapach na produkcji. Ja to tak nazwę.

Szymon Warda: Tak dla kontekstu. Mieliśmy ankietę szybką w firmie kto korzystał właśnie z wielkości modyfikacji wielkości ramki i Łukasz stwierdził, że każdy. W ciągu ostatniego roku wyszło, że ostatnie użycie było albo 4 albo 20 lat temu.

Łukasz Kałużny: Reszta nie słyszała kto w tym Dobra, ale routing w chmurze to trzeba sobie powiedzieć. One są poukrywane i routing w chmurze. Nawet jak mówicie odpalacie sobie vinet nawet w trybie cebula, to macie tam routery, których nie widzicie, które siedzą pod jednym adresem sieci.

Szymon Warda: Tam jest sporo routerów, Tak.

Łukasz Kałużny: Tak. I jeżeli nie macie wielki, to nie można ich Travel rzutować. Azure tak szybko.

Szymon Warda: Dostaje się tam przez przez. Nieważne. Już teraz Nie da się.

Łukasz Kałużny: Nie da się, bo tylko na interfejsie odbijemy. Możesz jak masz. Wiem. Możesz sprawdzić jakie są tablice routingu.

Szymon Warda: Niech będzie.

Łukasz Kałużny: Aktualnie to jest to drugi mit, który się pokazuje to firewalle i ludzie zapominają, że jest coś takiego jak port źródłowy.

Szymon Warda: Była było słynne wdrożenie w organizacji jednej dużej, nie powiem której, w której postawili sobie na jeszcze na WCF ie.

Łukasz Kałużny: Boże, co teraz ty Antyki bardzo.

Szymon Warda: Tak, ale czemu to jest ważne? Postawili i nagle mieli takie cykliczne połączenia. I co im się stało? Skończyły im się porty? Tak, tak. W ciągu około 5 minut od uruchomienia aplikacji.

Łukasz Kałużny: Teraz trzeba sobie powiedzieć to co się dzieje przy. Przy całości. Bo jeżeli macie w korporacji nie połączenia TCP i dlaczego powiedziałem o tym porcie źródłowym i otwieraniu. To jeżeli połączenia nie są zamykane automatycznie, to wysyczacie pulę dostępnych portów źródłowych. Macie coś jak port port na.

Szymon Warda: Tym kto pyta.

Łukasz Kałużny: Kto pyta oraz co jest ważne. Macie ten budżet portów również na przykład w AkSie na. Jeżeli macie macie firewalle w Azurze, w innych cloudach macie też ten limit portów otwartych połączeń na wszystkich tych elementach Load balancer firewall. A więc trzeba mieć świadomość, że jeżeli coś jest otwarte i wisi na Windowsie była ta piękna komenda netstat minusn, żeby zobaczyć wszystkie wiszące połączenia, jeżeli dobrze pamiętam tak, które trzeba tam było. Chyba jeszcze dodatkowy przełącznik.

Szymon Warda: Tak, tak z przełącznikiem, ale to zobaczyć.

Łukasz Kałużny: Teraz o co chodzi? Wasze długo żyjące. Takie połączenia zapychają wasze firewalle, wasze load balancer cloudowe czy On-Premowe. I to jest taki jeden z największych bólów, o których trzeba pamiętać. I on jest dziwny do troubleshootingu.

Szymon Warda: Znaczy one zapychają dowolny element, który jest na tym ruchu sieciowym. Tak jest to przechodzimy powoli na UDP praktycznie wszędzie, tylko tam.

Łukasz Kałużny: Tam jest połączenie, ale trzymane w UDP. Teraz ważne, czyli w Quicku. Połączenie jest na poziomie implementacji w waszej aplikacji w user space, czyli on jest na ślepo, nawala retransmisje, sesja i inne takie rzeczy. To są metadane trzymane w pamięci Twojej aplikacji, a nie w systemie operacyjnym w stosie sieciowym.

Szymon Warda: Dobrze Łukaszu, chciałeś jeszcze powiedzieć o okresie.

Łukasz Kałużny: Raczej o regresie. To jest właśnie ten ruch wychodzący. Czyli jeżeli trzymamy połączenia, na przykład gdzieś przechodzą przez te hopki, to możemy je w pewnym momencie Wyłączyć. Najczęściej mi się to Szymon zdarzało na spapranych wdrożeniach.

Szymon Warda: A tak jeszcze jeśli miałeś tą ciekawostkę, znaczy ciekawostkę, ciekawostkę, bardziej ostrzeżenie odnośnie skalowania i wysycenia ilości właśnie połączeń.

Łukasz Kałużny: Tak było, że mamy właśnie 1020 na przykład. Fakt jest taki, że macie 1024 porty zarezerwowane per węzeł wychodzące do internetu. Przykładowo jeżeli macie wszystkie te scenariusze startupowe, to nazwijmy bez własnego firewalla.

Szymon Warda: Mhm, Dobrze.

Łukasz Kałużny: To co? Fuck up? Chyba ten znany Szymon, czyli ubijanie połączeń. Po cichu.

Szymon Warda: To dajesz.

Łukasz Kałużny: Dobra, to macie też taką sytuację, że połączenie jest nawiązane i nagle widzicie w nim wy. Aplikacja zaczyna sypać na przykład błędami jak było długo żyjące, bo po drodze komponenty sieciowe potrafią zabić Wam połączenie, które wysoko żyje. Mamy tak zwane all time out, jeżeli nie przechodzą po nich pakiety kipliwe przypominające, że hej, mam żyć? To bardzo często dzieje się przy połączeniach właśnie do SQL i do HTTP. Nagle nam zabijało połączenie.

Szymon Warda: Niby tak, chociaż już na poziomie aplikacyjnym to jest często to już jest obsłużone, że tak powiem.

Łukasz Kałużny: Tak powinno być, ale powoduje przerwy, błędy, inne tego typu elementy. Takie dziwne czkawki i bardzo często te połączenia są w okolicach. Domyślnie to są timeouty, są ustawione na 5 minut. To są w okolicach od 300 do 600 sekund. To są zwykle domyślne i jedna zmora tego w tym. One są drukowane po cichu, w większości przypadków.

Szymon Warda: Tak, Z reguły klient trzymający połączenie się często nie dowie, że zostało zerwane. Dobrze Łukaszu, coś jeszcze? Czy już przechodzimy do checklisty, do load balanserów? A jeszcze load balansery i to powiedziałeś.

Łukasz Kałużny: I to jest świetne. Gites, że load balancer nie load. Balansuję.

Szymon Warda: Load balansuję, balansuję trochę inaczej niż założyłem. Większość ludzi.

Łukasz Kałużny: Myśli tak. Więc większość load balancing w szczególności jak pójdziemy do serwisu w Kubernetes ie to była zawsze moja zmora. To serwis w Kubernetes. Ale też czuli, że mamy load balancer load. Balansuję wam otwarte połączenia, a nie requesty. To jest chyba rzecz, którą trzeba zapamiętać. Czyli zazwyczaj sesja jest otwarta CCP więc load balansuję, a czemu?

Szymon Warda: Bo tak działa sesja TCP IP.

Łukasz Kałużny: Tak, dokładnie. I to jest pierwsza rzecz. Druga rzecz, która się pojawia sticky sessions, czyli żeby klient końcowy utrzymywał sesję do jednego serwera.

Szymon Warda: Co jest optymalne, prędkościowe, jeżeli chodzi o bardzo wiele rzeczy.

Łukasz Kałużny: Tak i ułatwia też kodowanie pewnych założeń cache i inne elementy.

Szymon Warda: Ale utrudnia wdrożenia.

Łukasz Kałużny: I zdarzało się tak na przykład, że w korporacjach wyłączano sticky sessions i wszyscy łączyli się do jednego serwera, jednego poda, bo ten ruch był gdzieś na przykład proxowany, przechodził przez jakieś proxy albo przychodził z internetu i nagłówki nie były przepisywane tak, jak trzeba. Więc to jest taka rzecz, którą trzeba mieć świadomość, że te sticky sessions czy elementy czasami ten load balancing z tego powodu nam nie działa, bo połączenia nie są, są otwarte. I tak samo będzie na przykład przy PC, które trzyma otwarte połączenie.

Szymon Warda: Znaczy ogólnie rzecz biorąc, mając jakikolwiek brownfield trzeba założyć, że jest włączony sticky session.

Łukasz Kałużny: Tak przy tym przy Brumfield, ale inaczej przy legacy z brodą.

Szymon Warda: Ja bym nie powiedział, że z brodą. Lekki wysyp wąsika i już będzie.

Łukasz Kałużny: Nie, Koper to długi, bo w tym momencie. Ale to jest taka rzecz, którą trzeba być świadomym, czy ten load balancing faktycznie działa I to w szczególności zaczyna się. Zabawnie jest przy dodawaniu automatycznie na przykład potów czy instancji. W zależności jaką macie usługę.

Szymon Warda: Skalowanie może Wam nie działać i będzie działało, ale nie będzie zmieniało.

Łukasz Kałużny: Nie tak, nie tak pięknie jak byście chcieli.

Szymon Warda: Dokładnie tak. Kierowniku, daj lajka, będzie lepiej. Dobrze.

Łukasz Kałużny: To jeszcze nie można powiedzieć, że to są rzeczy. Zobaczcie jak działa tak naprawdę po tym odcinku. Jakbym miał powiedzieć dwie rzeczy to przypomnienie sobie, zerknięcie na ten schemat jeszcze raz. A ja.

Szymon Warda: Bym powiedział.

Łukasz Kałużny: Tak nadal uważam, że to jest wiedza fundamentalna, W tym drugi element zerknąć sobie na to, czym jest tak naprawdę DNS i zobaczyć, gdzie na przykład w stosie twojej aplikacji, którą za którą odpowiadasz, gdzie ten DNS mógł Cię kopnąć. I jeżeli obsługujesz większy ruch, to dowiedzieć się jak u Ciebie działa load balancing.

Szymon Warda: Znaczy ja bym powiedział.

Łukasz Kałużny: Faktycznie.

Szymon Warda: Co innego. Nie koniecznie dowiedzieć się tylko sprawdzić dokładnie, bo teoria kartka wszystko przyjmie, ale sprawdzenie czy skalowanie działa, ale skalujemy się i wyłączamy starego poda i czy nam to zadziała I kiedyś klienci przełączam. Łącznie z tym, żeby sprawdzić jak wygląda przełączenie na tym pierwszym węźle, który wchodzi nie tylko na tym, co siedzi w Kubernetes.

Łukasz Kałużny: Scenariusze failover migracji. I to jest zajebiste ćwiczenie przed migracją.

Szymon Warda: Jeszcze jedna rzecz sprawdzić, gdzie powinniście robić resolve na wszystkie API w DNS ie, a gdzie po prostu resolve.

Łukasz Kałużny: W detale programistyczne. To zrozum jak działa HttpClient w Twojej, w Twoim języku programowania i frameworkach, których używasz w bibliotekach, bo one zachowują się różnie. Wiesz o tym?

Szymon Warda: To może dać Cloudowi. On to ogarnie. Sprawdzone. Naprawdę sprawdzone.

Łukasz Kałużny: Nie To wiesz. To, że ogarnie to Tak. Ale zrozumieć co się dzieje?

Szymon Warda: Dobrze. Dobra. Tyle. Kończymy.

Łukasz Kałużny: Trzymajcie się. Hej.

Szymon Warda: Na razie.