Desavil

Najlepiej sprawa wygląda w przypadku domen EU, gdzie każdy może wejść na stronę rejestratora - https://eurid.eu/pl/moje-konto-abonenta-domeny-eu/ podać nazwę domeny i adres e-mail z nią powiązany i w każdej chwili pobrać sobie kod Authinfo. Moim zdaniem tak to powinno wyglądać u większości rejestratorów.

Ja, tak jak wspominałem wcześniej wszedłem na tradycyjną drogę sądową, współpracuję w tym zakresie z kancelarią adwokacką. Otrzymałem już nakaz zapłaty, który za kilka dni powinien być prawomocny, ponieważ najprawdopodobniej żaden sprzeciw nie został złożony przez pozwanego. Będę informował nadal jak coś ruszy w sprawie, tak aby inni wiedzieli jak to w praktyce wygląda.

W taki sposób zupełnie się tego nie robi, a przynajmniej nie powinno. Nie ma to też związku z firewallem. Zmieniłem zawartość pliku: /etc/network/interfaces.d/ipfailover_1.cfg na: auto ens3:0 iface ens3:0 inet static address ip-failover/32 post-up ip route change default via 145.239.80.1 dev ens3 src ip-failover post-down ip route change default via 145.239.80.1 dev ens3 I wygląda na to, że wszystko działa poprawnie, ale... Po restarcie serwer odpowiada na ping na obydwa adresy IP po kilkunastu sekundach (jak wcześniej), ale np. do SSH nie można się zalogować. KVM zatrzymuje się na ok. 2 minuty na tym: Po tych ok. 2 minutach (zawsze tyle samo to trwa), już można się na serwer zalogować przez SSH. Tak jakby pełne uruchamianie interfejsu sieciowego trwało wtedy ok. 2 minuty. Więc nadal coś jest nie tak. Wcześniej, od razu jak serwer zaczął odpowiadać na ping, można się było zalogować przez SSH.

Cześć, posiadam serwer VPS SSD 1 z oferty OVH. Zainstalowany system to Debian 9. Zakupiłem do niego dodatkowy adres IP Failover i skonfigurowałem w następujący sposób. Utworzenie pliku: /etc/network/interfaces.d/ipfailover_1.cfg, zawartość: auto ens3:0 iface ens3:0 inet static address ip-failover/32 post-up ip addr add ip-failover/32 dev ens3:0 post-down ip link set ens3:0 down post-up ip route change default via 145.239.80.1 dev ens3 src ip-failover post-down ip route change default via 145.239.80.1 dev ens3 Problem polega na tym, że ostatni "post-up" tak jakby nie wykonywał się po restarcie serwera. Oczywiście jak wpiszę ręcznie z poziomu konsoli to wszystko działa dobrze i default gateway zmienia się. Chcę w ten sposób zmienić default gateway, chodzi o to, aby cały ruch wychodzący z serwera domyślnie wychodził przez dodany IP Failover, a nie główny adres IP serwera VPS. Wynik polecenia "ip route" bez modyfikacji: default via 145.239.80.1 dev ens3 145.239.80.1 dev ens3 scope link W jaki sposób dodać to prawidłowo?

Tylko w obrębie wszystkich DC w danym kraju. Wynika to z ograniczeń routerów (prawdopodobnie chodziło o rozmiar pamięci w nich, aby przechowywać wszystkie kombinacje bloków adresów IP) co Oles sam wyjaśniał na początku uruchomienia DC w Warszawie i innych krajach. Pisał wtedy też, że jeżeli kiedyś to ograniczenie sprzętowe nie będzie już problemem, to być może pojawi się możliwość przenoszenia IP pomiędzy wszystkimi DC OVH.

Cześć, mam pytanie do usługodawców oferujących usługi hostingu (głównie współdzielonego www). Jak postępujecie, gdy wykryjecie, że ktoś zamówił hosting (najczęściej na okres próbny, który większość oferuje, ale zdarzają się i opłacone zamówienia) i używa go ewidentnie do phishingu (np. fałszywe strony logowania, zbieranie loginów i haseł) lub scamu (np. fałszywe konkursy SMS, fałszywe treści po wysłaniu SMS - zazwyczaj erotyczne)? Zazwyczaj wystarczy wejść na domenę/y danego konta hostingowego użytkownika i od razu widać co pod nimi się kryje, nie trzeba przeglądać w tym celu plików (co nawet może być niezgodne z prawem), ale sama domena nie stanowi problemu. Blokujecie od razu celem wyjaśnienia i jak brak odpowiedzi lub sensownego wytłumaczenia to usunięcie hostingu, czy w ogóle tego nie sprawdzacie i dopiero jak otrzymacie jakieś wezwanie z organów ścigania to reagujecie, a może wręcz przeciwnie sami zgłaszacie takiego klienta do organów ścigania? Jestem ciekaw jak radzicie sobie z tym problemem i jakie rozwiązanie byłoby w tym przypadku najlepsze (szczególnie dla usługodawcy), ale i ewentualnych poszkodowanych.

Tak jak pisze @sylver74 tylko w jedną stronę z SYS do OVH. Przypuszczam, że nie jest to kwestia techniczna, a jest to podyktowane kwestiami biznesowymi, aby klienci nie przechodzili z droższej oferty OVH na tańszą w SYS.

Już nie ma w innych lokalizacjach.

Serwer z tej oferty ma łącze 500 Mbps i limit 256 adresów IP. Jedyne czego nie ma to vRack, o którym wcześniej pisano (wkradł się tutaj błąd).

@OVH oferta mega! Czy opcja z dyskami SSD też się pojawi? Na razie napis: soon. :)

Domeny.tv nie należy do grupy H88 (do H88 należy serwis Domeny.pl) i bardzo ich polecam w kwestii oferty reseller dla domen. Ceny mają dużo lepsze, niż w HRD, przy niższej i realnej ilości wymaganych domen do uzyskania danego cennika. API też fajne i proste. Przede wszystkim cały panel itd. wygląda dużo lepiej i profesjonalnej, niż w HRD.

NASK mógłby pomyśleć nad zrobieniem czegoś takiego jak EURid dla domen .EU, gdzie bezpośrednio od registry można pobrać sobie kod Authinfo (weryfikacja m.in. na podstawie adresu e-mail podanego w kontakcie domeny).

Warto dodać, że w przypadku zmowy konkurencji (szczególnie w kwestii cen) może się sprawą zainteresować UOKiK. Jednak jestem przekonany, że nie o to tutaj chodzi.

Nikt się jeszcze nie kontaktował.

Jasne, zapytam o to podczas przesłuchania, czy i gdzie więcej osób poszkodowanych może się zgłaszać. Jeżeli chodzi o korespondencję e-mail to chcieli wyłącznie, aby przesłać swoje dane (na razie nie odpowiedzieli) i zapewne reszta będzie już się odbywała na komendzie.