psz

O ile brak backupu w usłudze FTP jestem w stanie zrozumieć, uważam, że codzienny backup dla dysku online jest anachronizmem i powinien być zastąpiony przez replikację między Waszymi lokalizacjami. Reklamujecie dysk jako usługę do bieżącej pracy i pliki powinny być chronione nieważne od tego, ile godzin minęło od ostatniej kopii.

Niby usługa wygląda ciekawie, ale zapisy regulaminu każą się mocno zastanowić przed zamówieniem: Na przykład przy zamówieniu najniższej oferty 100 GB, po przesłaniu 5 GB w miesiącu (wysyłanie i odbieranie liczone łącznie) jest dopłata 5 zł netto! Nie ma replikacji danych, jest (opcjonalny) dodatkowo płatny backup wykonywany co 24 godziny. Biada, jeśli się serwerownia spali kilka godzin po edycji plików. Trudno to uznać za bezpieczne miejsce przechowywania bieżących plików, co najwyżej backup. W dodatku regulamin może się zmienić w ciągu 24 godzin, trzeba ciągle obserwować stronę, bo w przeciwnym razie po upływie tych 24 godzin się go automatycznie zaakceptowało!

https://www.icann.org/resources/pages/name-holder-faqs-2017-10-10-en Punkty 8 i 10 wydają się mieć zastosowanie do Twojej sytuacji.

Nie, nie używałem tego. Głównie ze względu, że używam Turris Omnia (oparte o OpenWrt 15.x; jest nowsza wersja oparta o 19.x, ale nie mam czasu na ewentualne naprawianie, gdy się coś przy migracji popsuje; bo proces migracji dalej beta). Nie jest jednak tak źle, wszystko dało się wyklikać z LuCI, z wyjątkiem policy-based routing (które trzeba było wpisać do configa).

Faktycznie, WireGuard jest fajny. Miałem mnóstwo frajdy, gdy na swoim domowym OpenWrt konfigurowałem dwie dodatkowe sieci Wi-Fi (SSID), żeby każda z nich routowała 0.0.0.0/0 poprzez WireGuard do dwóch VPS'ów: w US i PL, podczas gdy mój normalny SSID routował wybrane zakresy IP do innej lokalizacji w stylu site-to-site. Po połączeniu z wybranym Wi-Fi cały ruch (tylko IPv4, bo Netflix nie lubi IPv6, więc specjalnie pominąłem) idzie do wybranego VPS'a, który robi zwykły linuksowy NAT i wypuszcza ruch w Internet. Wygodny sposób na Netflix'a czy inne VoD z różnicami w zawartości katalogów między krajami, kupowaniu na Steam itp. Zgoła większy problem sprawiał mi iproute2 niż WireGuard (jeśli się pamięta, że używa crypto-routingu, tzn. nie można na jednym interfejsie ustawić dwóch tras 0.0.0.0/0, ale można stworzyć dwa interfejsy). Trzeba było się pobawić policy-based routing. Nie używałem vlan'ów, bo nie planuję używania kabla dla tych tuneli, z kolei podsieci założone na SSID już załatwiają segmentację. Zmień jednak SSID na vlan i będzie działać równie dobrze. PS: Rozpisałem się Możemy pogadać więcej na priv.

Porównujesz jabłka do pomarańczy. OpenVPN to kombajn wszystko w jednym, WireGuard to wyłącznie szyfrowany interfejs sieciowy. W założeniu WireGuard ma być zarządzany dodatkowym oprogramowaniem, np. https://tailscale.com/ - mesh network zarządzany w chmurze https://github.com/costela/wesher - to samo, ale open source https://one.one.one.one - konsumencki "VPN". etc. ... ale może też być używany "goły" (w połączeniu ze standardowymi narzędziami linuksowymi jak iproute2+iptables, NetworkManager, etc.) jako prosty i skuteczny VPN. Sam go w ten sposób używam do tunelowania site-to-site oraz żeby wirtualnie pojawić się w innym kraju z Netflix'em. OpenVPN jest spoko, jeśli się go dobrze skonfiguruje (o czym wspomniałeś). Jednak, jeśli miałbym możliwość wyboru, brałbym WireGuard. OpenVPN ideowo i technologicznie tkwi jednak w przysłowiowym dwudziestym wieku

PPTP jest protokołem kompletnie złamanym pod względem bezpieczeństwa i nie powinno się go w ogóle używać. Apple posunął się nawet dalej i usunął jego obsługę z MacOS i iOS. Natomiast L2TP/IPsec cierpi na podobne problemy (ale już nie w tak poważnym stopniu), jak OpenVPN: - duży rozmiar kodu (13 tys. w jądrze i kolejne 400 tys. w userspace) - trudny w konfiguracji (na serwerze lub site-to-site) ale są też plusy: - bardzo dobra wydajność - bardzo popularny w profesjonalnym sprzęcie sieciowym SSTP, IKEv2 nie miałem okazji używać, więc nie zdołam ocenić. Trochę więcej o WireGuard: https://www.theregister.com/2018/08/02/linux_kernel_wireguard/

OpenVPN: - stary i przerośnięty kod z historią dziur bezpieczeństwa (ok. 400-600 tys. linii kodu) - trudna i żmudna konfiguracja (w pliku konfiguracyjnym dostępnych kilkaset opcji, w bezpiecznej konfiguracji wymóg generowania i dystrybucji certyfikatów) - potencjał do skonfigurowania w niepoprawny sposób, np. słabe zabezpieczenia lub wydajność - słaba obsługa IPv6 - słaba wydajność: typowo poniżej 300 Mbps nawet na sprzęcie serwerowym W zamian polecam WireGuard: - mały i nowoczesny kod (ok. 4000 linii kodu, słownie: cztery tysiące) - przeprowadzone audyty bezpieczeństwa - łatwa konfiguracja: wystarczy 7 linii w pliku konfiguracyjnym na kliencie, podobna ilość na serwerze - nie da się źle skonfigurować: tylko silne szyfrowanie, tylko jeden wydajny tryb pracy - pełna obsługa IPv6 - wbudowana obsługa roamingu, bez problemu radzi sobie ze zmiennymi IP - wydajność powyżej 1 Gbps nawet na domowym komputerze - kod oficjalnie dodany do jądra Linuksa, ale też dostępny na Windows, MacOS, iOS, Android, wiele rodzajów routerów - coraz częściej spotykany u dostawców VPN

Nikt nie powinien instalować OpenVPN w 2021 roku.

Ciekawy wątek na Facebooku dziś znalazłem: https://www.facebook.com/groups/sysopspolskapogodzinach/permalink/1388146701559784/

Nie wiem, o jaki serwer głosowy chodzi, ale załóżmy, że Teamspeak. 192.0.2.1 - serwer www z panelem 192.0.2.2 - serwer teamspeak example.com - domena example.com. A 192.0.2.1 _ts3._udp.example.com. SRV 0 0 9987 serwer2.example.com. serwer2.example.com. A 192.0.2.2 Więcej o obsłudze rekordu SRV przez Teamspeak'a: https://support.teamspeak.com/hc/en-us/articles/360002713138-Server-address-resolution-and-TSDNS-changes-with-Client-3-1-x Przeglądarki WWW nie obsługują SRV, stąd rekord A dla panelu.

https://www.backblaze.com/b2/cloud-storage.html - $0.005/GB/miesiąc + VAT - dostęp do plików natychmiast https://www.scaleway.com/en/c14-cold-storage/ - €0.002/GB/miesiąc + VAT - dostęp do plików kilka minut Oba są kompatybilne z protokołem S3 (B2 to odpowiednik zwykłego AWS S3, Scaleway C14 to odpowiednik AWS Glacier), więc będziesz mieć dużo narzędzi do dyspozycji, np. zamiast ftp: Cyberduck, zamiast rsync: rclone. Praktycznie każde narzędzie do backupu obsługuje protokół S3. B2 używam, C14 zamierzam niedługo wypróbować.

Przeszło bez echa, ale właśnie zauważyłem na ich blogu, że 1 lutego ogłosili domyślne włączenie DNSSEC dla wszystkich domen utrzymywanych u nich: https://blog.aftermarket.pl/zabezpiecz-swoja-domene-przez-dnssec-w-aftermarket-pl-to-domyslne-rozwiazanie/ Patrząc na dns.pl jest tam jakiś skok, ale miałem nadzieję na większy. Może nie skończyli aktywowania dla wszystkich domen?

Jeśli już wspominamy PayPal, to można doładować konto przelewem.

Ja także nie słyszałem, żeby były jakieś problemy z kartami debetowymi. To, że na stronie pisze "karta kredytowa", to neologizm (jak np. google'ować). Po prostu większość dorosłych Amerykanów posługuje się kartami kredytowymi do takiego stopnia, że stało się to normą. Dzięki faktowi, że dużo startupów jest amerykańskich, określenie rozpowszechniło się po świecie anglojęzycznym. W 99% przypadków, gdzie pytają o kartę kredytową, można użyć karty debetowej, i zadziała bez problemów. Na liście VPS'ów "na godziny" zabrakło Google Compute Engine, gdzie jest naliczanie sekundowe.

Nie powinno być możliwości atakowania TeamSpeak'a via Cloudflare. Chyba że mówimy o ruchu HTTP(S) (ale wtedy to ma niewiele wspólnego z TeamSpeak). Przyślij proszę szczegóły na priva.

Taki ułomny ten ich damage control. Nie dość, że "Developer subscription" źle rezonansuje z "production systems", to jeszcze limit 16 instalacji jest jak kropla w morzu potrzeb w dobie kontenerów i wirtualek. Czuć już zimny oddech IBM na plecach.

ISP i to jaki adres IP widzi, nie ma kompletnie nic wspólnego z użytkownikiem końcowym. Nawet Cloudflare i jego IP się tu nie liczy. Ważny jest IP użytkownika końcowego, który wykonuje jakąś czynność. Nie możesz nikogo zmusić, żeby uznał zawartość nagłówka, ale wyobraź sobie, że niektórzy już uznają. I chcą go w logach. Skończ już z tym IP, bo się zapętlasz i robi się to nudne. Tak, przyjąłem do wiadomości, że nie masz pewności co do zawartości nagłówka. Zostawmy temat.

Dokładnie nic, ale zarzucasz Cloudflare'owi brak uczciwości. Niech klienci to ocenią. Jeśli ufają i chcą korzystać, po co im w tym przeszkadzać? CDN i hosting to usługi komplementarne, a nie konkurencja. Porada dla klientów (dowolnej firmy): Jeśli nie ufacie firmie, z którą współpracujecie, a na rynku są inne świadczące podobne usługi, zmieńcie firmę. W takim razie jak nazwiesz CloudHosting WordPress? Albo Cloud Backup z klientem tylko dla Windows? Logi są dla klienta, a nie dla Was. Nie każdy potrzebuje logów o jakości dowodowej, a jeśli naprawdę takich potrzebujecie, nazwa.pl może trzymać osobne. Porada dla klientów: Jeśli firma hostingowa nie umożliwia, czego potrzebujecie, a inne firmy tak, zmieńcie firmę. PS: Ja także wypowiadam się na tym forum prywatnie. PS2: Cloudflare oferuje dużo więcej niż tylko CDN, który zresztą jest mało istotnym i nudnym produktem w naszej ofercie. CDN'ów na rynku są setki a marże bliskie zeru. PS3: Jakość dyskusji w tym wątku uległa wyraźnemu pogorszeniu. Klient zapytał o coś, udzieliłeś odpowiedzi, ale później dyskusja zeszła na kwestie ideologiczne. Chyba nie ma sensu jej dłużej ciągnąć.

To mnie rozbawiło. Serio, Cloudflare nie ma żadnego interesu w "kłamaniu" w jednym, zgoła mało istotnym miejscu swojego software stacka. Nie musicie wierzyć na słowo, można spojrzeć na certyfikaty, oraz zgodność z GDPR (oczywiste) i HIPAA (mało ważne w polskich warunkach). O zaufaniu możemy pogadać, gdy nazwa.pl wróci z certyfikatem SOC 2, albo chociaż PCI DSS, bo patrzę na stronę i widzę tylko ISO 27001.

Słuszna uwaga, choć pominąłem, żeby nie zaciemniać wypowiedzi.

FYI @psz Zostałem wywołany do tablicy, więc spróbuję odpowiedzieć. Cloudflare przesyła "IP swoich CDN'ów" w ... polu "źródłowy adres IP" każdego pakietu IP Dodawanie nowego nagłówka HTTP, żeby zdublować tę informację, nie ma sensu. Cloudflare natomiast przesyła IP użytkownika w nagłówkach HTTP: - CF-Connecting-IP - autorski pomysł - X-Forwarded-For - standard de facto - True-Client-IP - opcjonalne w planie Enterprise - dla kompatybilności z różnymi rozwiązaniami enterprise lub starym oprogramowaniem, które myśli, że jedynym CDN'em wartym kupowania jest Akamai. Dla Apache dostępny jest moduł mod_remoteip, dla nginx: ngx_http_realip. W konfiguracji podaje się nazwę nagłówka HTTP, z którego pobiera się IP do logów/PHP/etc. Nie chcecie wprowadzać supportu dla Cloudflare i rozumiem Twoją argumentację. Jednakże nie powinno stanowić dużego wyzwania umożliwić klientowi (w panelu lub .htaccess) wybranie sobie nagłówka HTTP, z którego chce mieć pobierany adres IP. W ten sposób wprowadzacie obsługę wszystkich możliwych CDN'ów, klastrów Kubernetes, etc. CDN'a można używać również do cache'owania stron dynamicznych. W innym wątku przytoczono przykład WordPress'a generującego stronę w 1 sekundę. Nawet jeśli hosting nie ma nic przeciwko obciążeniu zasobów, z pewnością właściciel strony chciałby oszczędzić użytkownikowi tej sekundy i żeby jego strona wczytywała się błyskawicznie.

A jakbyś chciał, żebyśmy przesyłali swoje nagłówki? Chętnie przekażę do odpowiedniego teamu.

Nawet jeśli nie ma composera, ale jest ssh z php-cli, to można go sobie doinstalować bez problemów. Hosting nie musi go udostępniać, szczególnie że często takie pakiety będą nieaktualne.

Można też użyć https://1.1.1.1/ Wersja darmowa tuneluje ruch do najbliższego PoP'u Cloudflare, wersja płatna (20 zł/miesiąc) dodatkowo przyspiesza dostęp do stron na całym świecie. Jeden abonament można dzielić między smartfonem a komputerem.