Pytanie w sprawie amazon-route53, forwarding, dns – Skonfiguruj przesyłanie adresów URL na podstawie DNS w Amazon Route53 [zamknięte]

125

Próbuję skonfigurować przekazywanie w Amazon Route53. Moja ostatnia usługa DNS (Nettica) umożliwiła mi kierowanie żądań do „aws.example.com” do „https://myaccount.signin.aws.amazon.com/console/”.

Czy ta funkcja jest obsługiwana przez Route53?

Jak osiąga to Nettica? Czy wstawia specjalny rekord A, CNAME, PTR lub TXT?

Tworzenie dystrybucji Cloudfront z adresem URL, ponieważ działa również źródło. Wystarczy skierować domenę do dystrybucji Cloudfront z Route53 i upewnić się, że poprawnie skonfigurowano certyfikaty TLS. Deiwin

Twoja odpowiedź

5   odpowiedzi
0

Jeśli nadal masz problemy z prostym podejściem, utwórz wtedy puste wiadroRedirect all requests to another host name w obszarze Statyczny hosting witryn we właściwościach za pośrednictwem konsoli. Upewnij się, że ustawiłeś 2 rekordy A na trasie53, jeden dlafinal-destination.com i jeden zaredirect-to.final-destination.com. Ustawienia dla każdego z nich będą identyczne, ale nazwa będzie inna, więc pasuje do nazw ustawionych dla segmentów / adresów URL.

121

Obsługa AWS wskazała prostsze rozwiązanie. Jest to zasadniczo ten sam pomysł zaproponowany przez @Vivek M. Chawla, z prostszą implementacją.

AWS S3:

Utwórz wiadro o nazwie z pełną domenąaws.example.comNa właściwościach wiadra wybierzRedirect all requests to another host name i wprowadź swój adres URL:https://myaccount.signin.aws.amazon.com/console/

AWS Route53:

Utwórz typ zestawu rekordów A. Zmień alias naYes. KliknijAlias Target pole i wybierz wiadro S3 utworzone w poprzednim kroku.

Odniesienie:Jak przekierować domeny za pomocą Amazon Web Services

Oficjalna dokumentacja AWS:Czy istnieje sposób przekierowania domeny do innej domeny za pomocą Amazon Route 53?

@Pawel powinieneś natychmiast zobaczyć wiadro. Upewnij się, że nazwa wiadra jest dokładnie taka sama jak pełna domena route53. Na przykład, jeśli tworzysz rekord Alias ​​A o nazwie „mysubdomain”, twoja nazwa wiadra powinna być „mysubdomain.domain.com”. Roberto Schneiders
@mythofechelon Co masz na myśli? Jak dotąd nie miałem żadnych problemów z https. Jeśli chcesz używać https w swojej domenie (np. Https: // aws.example.com), jest to zupełnie inny problem, ponieważ aby to zrobić, będziesz potrzebować serwera z certyfikatem ssl. Roberto Schneiders
Nie polecam tego w ten sposób, ponieważ wyniki są buforowane, a czas aktualizacji zajmuje trochę czasu, ponadto obsługiwane będą tylko domeny. Lorenz Lo Sauer
Działa to doskonale dla HTTP, ale nie dla HTTPS. mythofechelon
11

Udało mi się użyć nginx do obsługi przekierowania 301 na stronę logowania aws.

Przejdź do swojego folderu nginx conf (w moim przypadku jest to/etc/nginx/sites-available w którym tworzę dowiązanie symboliczne do/etc/nginx/sites-enabled dla włączonych plików conf).

Następnie dodaj ścieżkę przekierowania

<code>server {
  listen 80;
  server_name aws.example.com;
  return 301 https://myaccount.signin.aws.amazon.com/console;
}
</code>

Jeśli używasz nginx, najprawdopodobniej będziesz mieć dodatkowe bloki serwerów (virtualhosts w terminologii apache) do obsługi strefy apex (example.com) lub jakkolwiek ją skonfigurujesz. Upewnij się, że jeden z nich został ustawiony jako serwer domyślny.

<code>server {
  listen 80 default_server;
  server_name example.com;
  # rest of config ...
}
</code>

W Route 53 dodajA record dlaaws.example.com i ustaw wartość na ten sam adres IP, który jest używany dla wierzchołka strefy.

Jeszcze lepiej byłoby użyć rekordu Alias, aby wskazać elastyczną stabilizator obciążenia przed tą maszyną. maletor
301

Wpadłem na ten sam problem, który opisał Saurav, ale naprawdę musiałem znaleźć rozwiązanie, które nie wymagało niczego poza trasą 53 i S3. Stworzyłem przewodnik po moim blogu, w którym szczegółowo opisałem, co zrobiłem.

Oto, co wymyśliłem.

Cel

Używając tylko narzędzi dostępnych w Amazon S3 i Amazon Route 53, utwórz przekierowanie URL, które automatycznie przekierowujehttp://url-redirect-example.vivekmchawla.com do strony logowania do konsoli AWS aliasowanej do „Moje konto”, znajdującej się pod adresemhttps://myaccount.signin.aws.amazon.com/console/ .

Ten przewodnik nauczy Cię konfigurowania przekazywania adresów URL na dowolny adres URL, a nie tylko z Amazon. Dowiesz się, jak skonfigurować przekazywanie do określonych folderów (np. „/ Console” w moim przykładzie) i jak zmienić protokół przekierowania z HTTP na HTTPS (lub odwrotnie).

Krok pierwszy: Stwórz swoje wiadro S3

Otwórz konsolę zarządzania S3 i kliknij „Utwórz wiadro”.

Krok drugi: Nazwij swoje wiadro S3

Wybierz nazwę wiadra. Ten krok jest naprawdę ważny! Musisz nazwać wiadro DOKŁADNIE tym samym, co adres URL, który chcesz skonfigurować do przekazywania. W tym przewodniku użyję nazwy „url-redirect-example.vivekmchawla.com”.

Wybierz region, który najlepiej Ci odpowiada. Jeśli nie wiesz, zachowaj domyślne.

Nie martw się konfigurowaniem logowania. Po prostu kliknij przycisk „Utwórz”, gdy będziesz gotowy.

Krok 3: Włącz statyczne hosting witryn internetowych i określ reguły routingu

W oknie właściwości otwórz ustawienia „Static Hosting Website”.Wybierz opcję „Włącz hosting”.Wprowadź wartość „Dokumentu indeksowego”. Ten obiekt (dokument) nigdy nie będzie obsługiwany przez S3 i nigdy nie musisz go przesyłać. Po prostu użyj dowolnej nazwy, którą chcesz.Otwórz ustawienia „Edytuj reguły przekierowania”.

Wklej następujący fragment kodu XML w całości.

<code><RoutingRules>
  <RoutingRule>
    <Redirect>
      <Protocol>https</Protocol>
      <HostName>myaccount.signin.aws.amazon.com</HostName>
      <ReplaceKeyPrefixWith>console/</ReplaceKeyPrefixWith>
      <HttpRedirectCode>301</HttpRedirectCode>
    </Redirect>
  </RoutingRule>
</RoutingRules>
</code>

Jeśli jesteś ciekawy, co robi powyższy XML, odwiedźDokumentacja AWM „Składnia do określania reguł routingu”. Dodatkową techniką (nie omówioną tutaj) jest na przykład przekazywanie do określonych stron hosta docelowegohttp://redirect-destination.com/console/special-page.html. Przeczytaj o<ReplaceKeyWith> element, jeśli potrzebujesz tej funkcjonalności.

Krok 4: Zanotuj „Punkt końcowy” swojego wiadra przekierowania

Zanotuj „punkt końcowy” statycznego hostingu witryny, który Amazon automatycznie utworzył dla tego wiadra. Będziesz potrzebował tego później, więc zaznacz cały adres URL, a następnie skopiuj go i wklej do notatnika.

UWAGA! W tym momencie możesz kliknąć ten link, aby sprawdzić, czy reguły przekierowania zostały wprowadzone poprawnie, ale uważaj! Dlatego...

Powiedzmy, że wprowadziłeś niewłaściwą wartość wewnątrz<Hostname> znaczniki w regułach przekierowania. Może przypadkowo wpisałeśmyaccount.amazon.com, zamiastmyaccount.signin.aws.amazon.com. Jeśli klikniesz łącze w celu przetestowania adresu URL punktu końcowego, AWS z radością przekieruje przeglądarkę na niewłaściwy adres!

Po zauważeniu błędu prawdopodobnie edytujesz<Hostname> w regułach przekierowania, aby naprawić błąd. Niestety, gdy spróbujesz ponownie kliknąć link, najprawdopodobniej zostaniesz przekierowany z powrotem na niewłaściwy adres! Nawet jeśli naprawiłeś<Hostname> wpis, Twoja przeglądarka buforuje poprzedni (niepoprawny!) wpis. Dzieje się tak, ponieważ używamy przekierowania HTTP 301 (stałe), które przeglądarki, takie jak Chrome i Firefox, będą domyślnie buforować.

Jeśli skopiujesz i wkleisz adres URL punktu końcowego do innej przeglądarki (lub wyczyścisz pamięć podręczną w bieżącej przeglądarce), otrzymasz kolejną szansę sprawdzenia, czy zaktualizowałeś<Hostname> wpis jest w końcu poprawny.

Aby być bezpiecznym, jeśli chcesz przetestować adres URL punktu końcowego i reguły przekierowania, powinieneś otworzyć prywatną sesję przeglądania, taką jak „Tryb incognito” w Chrome. Skopiuj, wklej i przetestuj adres URL punktu końcowego w trybie incognito, a cache zostanie usunięty po zamknięciu sesji.

Krok 5: Otwórz konsolę zarządzania Route53 i przejdź do zestawów rekordów dla hostowanej strefy (nazwa domeny)

Wybierz Strefę hostowaną (nazwę domeny), której użyłeś podczas tworzenia wiadra. Ponieważ nazwałem moje wiadro „url-redirect-example.vivekmchawla.com”, wybiorę Strefę hostowaną vivekmchawla.com.Kliknij przycisk „Przejdź do zestawów rekordów”.Krok 6: Kliknij przycisk „Utwórz zestaw rekordów”

Kliknięcie „Utwórz zestaw rekordów” otworzy okno Utwórz zestaw rekordów po prawej stronie konsoli zarządzania Route53.

Krok 7: Utwórz zestaw rekordów CNAME

W polu Nazwa wprowadź część nazwy hosta adresu URL, który został użyty podczas nazywania wiadra S3. „Część nazwy hosta” adresu URL to wszystko po lewej stronie nazwy hostowanej strefy. Nazwę moje wiadro S3 „url-redirect-example.vivekmchawla.com”, a moja Hosted Zone to „vivekmchawla.com”, więc część nazwy hosta, którą muszę wprowadzić, to „url-redirect-example”.

Wybierz „CNAME - nazwa kanoniczna” dla typu tego zestawu rekordów.

W polu Wartość wklej adres URL punktu końcowego wiadra S3, który utworzyliśmy w kroku 3.

Kliknij przycisk „Utwórz zestaw rekordów”. Zakładając, że nie ma błędów, będziesz mógł zobaczyć nowy rekord CNAME na liście zestawów rekordów w Strefie Hostowanej.

Krok 8: Przetestuj nowe przekierowanie adresu URL

Otwórz nową kartę przeglądarki i wpisz adres URL, który właśnie ustawiliśmy. Dla mnie to jesthttp://url-redirect-example.vivekmchawla.com. Jeśli wszystko działało poprawnie, powinieneś zostać wysłany bezpośrednio na stronę logowania AWS.

Ponieważ użyliśmymyaccount.signin.aws.amazon.com alias jako docelowy adres URL naszego przekierowania, Amazon wie dokładnie, które konto próbujemy uzyskać dostęp, i przenosi nas bezpośrednio tam. Może to być bardzo przydatne, jeśli chcesz dać pracownikom lub kontrahentom krótki, czysty, opatrzony znakiem firmowym link do logowania AWS.

Wnioski

Osobiście uwielbiam różne usługi AWS, ale jeśli zdecydowałeś się przenieść zarządzanie DNS na Amazon Route 53, brak łatwego przekazywania adresów URL może być frustrujący. Mam nadzieję, że ten przewodnik pomógł nieco skonfigurować konfigurację przekazywania adresów URL dla Stref hostowanych.

Jeśli chcesz dowiedzieć się więcej, zapoznaj się z następującymi stronami na stronie Dokumentacja AWS.

Przykład: konfigurowanie statycznej witryny internetowej przy użyciu domeny niestandardowejSkonfiguruj wiadro do hostingu witrynyTworzenie domeny używającej trasy 53Tworzenie, zmiana i usuwanie rekordów zasobów

Twoje zdrowie!

Ahh, jasność! Dzięki! Will
Świetne rozwiązanie. Wystąpił jednak problem z użyciem https dla oryginalnego adresu URL. Jeśli kubełkiem, który przekierowuję, jest dev.example.com, re-direct działa świetnie w http: // dev.example.com, ale nie działa w https: // dev.example.com. Nie znalazłem rozwiązania tego problemu. Greg
Dlaczego „nazwij wiadro DOKŁADNIE tym samym, co adres URL, który chcesz skonfigurować do przesyłania dalej”? lu yuan
Jakiś pomysł, dlaczego dostajęBłąd NoSuchBucket? fredley
9
Aktualizacja

Chociaż moja oryginalna odpowiedź poniżej jest nadal aktualna i może być pomocna w zrozumieniu przyczyny, dla której przekazywanie adresów URL na podstawie DNS nie jest dostępne za pośrednictwemAmazon Route 53 po wyjęciu z pudełka, zdecydowanie polecam sprawdzenie Vivek M. Chawlacałkowicie inteligentne rozwiązanie pośrednie w międzyczasie wprowadzonoObsługa Amazon S3 dla przekierowań witryny i osiągnięcie samodzielnego, mniejszego, a więc bezpłatnego rozwiązania serwerowego w AWS tylko tak.

Wdrożenie zautomatyzowanego rozwiązania do generowania takich przekierowań jest pozostawione jako ćwiczenie dla czytelnika, ale proszę oddać hołd epickiej odpowiedzi Vivek, publikując swoje rozwiązanie;)Oryginalna odpowiedź

W tym celu Nettica musi obsługiwać niestandardowe rozwiązanie przekierowania. Oto problem:

Możesz utworzyć alias CNAME, taki jakaws.example.com dlamyaccount.signin.aws.amazon.comjednak DNS nie zapewnia oficjalnego wsparcia dla aliasingu podkatalogu, takiego jakconsole w tym przykładzie.

Szkoda, że ​​AWS nie wydaje się po prostu robić tego domyślnie, gdy uderzahttps://myaccount.signin.aws.amazon.com/ (Właśnie próbowałem), ponieważ od razu rozwiązałoby to problem i na początku miałoby sens; poza tym powinno być całkiem łatwe do skonfigurowania po ich zakończeniu.

Z tego powodu kilku dostawców DNS najwyraźniej zaimplementowało niestandardowe rozwiązanie umożliwiające przekierowanie do podkatalogów; Ośmielam się przypuszczać, że w zasadzie ułatwiają alias CNAME dla własnej domeny i przekierowują stamtąd do miejsca docelowego za pośrednictwem natychmiastowegoPrzekierowanie HTTP 3xx.

Aby osiągnąć ten sam rezultat, musisz mieć uruchomioną usługę HTTP wykonującą te przekierowania, co oczywiście nie jest prostym rozwiązaniem. Może / Hopefully jeszcze ktoś może wymyślić mądrzejsze podejście.

@ejain - oczywiście masz rację, poprawiłem to odpowiednio (wtedy musiałem przegapić powiadomienie); dzięki za wskazanie tego potencjalnie mylącego sformułowania! Steffen Opel
Jesteś na miejscu. To właśnie się działo. Saurav
CNAME są aliasami i nie przekierowują. ejain

Powiązane pytania