Jestem całkiem nowy w administrowaniu siecią i dlatego już cieszę się, że udało mi się ustanowić rekord DNS.

Teraz jestem trochę zdezorientowany, ponieważ chciałbym mieć ten adres URL:

http://www.example.org:8080/fetch/characters/

być osiągniętym przez to

http://www.example.org/fetch/characters/

Użytkownicy mogą więc uzyskać dostęp do usługi na porcie 8080 bez konieczności jawnego ustawiania portu.

W jaki sposób mogę to zrobić? Czy potrzebuję specjalnej aplikacji na moim serwerze? Lub jakieś przekierowania , które należy zastosować do żądań?

Rekordy DNS nie mogą wskazywać portów (z kilkoma wyjątkami wyjątków, które nie mają tutaj zastosowania).

Jeśli masz usługę sieci Web nasłuchującą na porcie 8080 i chcesz się z nią połączyć bez określania tego portu, masz 3 opcje:

• Spraw, aby faktycznie nasłuchiwał na porcie 80 (lub 443 z https).
• Skonfiguruj wszystko, co już nasłuchuje na porcie 80, aby przekazywać żądania do usługi na porcie 8080 (odwrotne proxy).
• Jeśli możesz żyć z przekierowaniem, użyj tego zamiast proxy, ale wtedy Twoi klienci zobaczą tę :8080część na swoich pasku adresu po przekierowaniu.

Serwery WWW domyślnie nasłuchują na porcie TCP 80. Jeśli nie chcesz jawnie wpisywać numeru portu w adresie URL, masz kilka opcji:

• Możesz ponownie skonfigurować serwer WWW, aby używał portu 80 zamiast portu 8080. Jest to zalecane w przypadku serwerów internetowych takich jak Nginx lub Apache, ale nie w przypadku serwerów internetowych takich jak Gunicorn. Ta opcja również nie zawsze jest możliwa, ponieważ ten port może być już używany przez inny serwer WWW.

  Ponadto, gdy serwer znajduje się za bramą NAT, nie jest właścicielem publicznego adresu IP, a kombinacja tego publicznego adresu NAT i portu 80 może już zostać przekazana na inny serwer WWW.

• Możesz umieścić odwrotny serwer proxy przed serwerem WWW, który akceptuje ruch na porcie TCP 80 i wysyła go do serwera WWW na porcie TCP 8080. Działa to również, jeśli port 80 jest już w użyciu. Po prostu umieść odwrotny serwer proxy przed obydwoma serwerami WWW, aby oba nasłuchały na portach innych niż 80.

Aby zapewnić lepszą i bardziej szczegółową pomoc dotyczącą wyboru najlepszej opcji oraz ograniczeń itp., Musimy dowiedzieć się więcej o konfiguracji. Mam nadzieję, że to wyjaśnienie już trochę wyjaśniło.

Prosta odpowiedź związana z poziomem pytania

Ignorując egzotyczne zastosowania DNS, a także odwrotne wyszukiwanie DNS (nie dotyczy pytania), prawie całe użycie DNS ma postać:

1. Klient wysyła nazwę domeny (w pełni kwalifikowaną lub inną) do serwera DNS
2. Serwer DNS zwraca informacje o domenie ze swoich rekordów. Zwykle kluczowymi żądanymi informacjami są adres IP do komunikacji z Internetem / pocztą e-mail w tej domenie lub adres IP innego serwera DNS, który jest w stanie lepiej dostarczyć te informacje.

Gdy klient skontaktuje się z serwerem, sam serwer przejmie kontrolę, a system DNS zniknie z obrazu.

Oznacza to, że system DNS nie musi dostarczać informacji o porcie i prawie nigdy tego nie robi. Więc chociaż cel pytania jest prawidłowy i często wykonywany, tak naprawdę nie jest to system DNS, który to robi. Dlatego nie możesz tego wypracować :)

Chodzi o to, że gdy klient może zlokalizować konkretną maszynę lub serwer, którego szuka, zadaniem tego komputera jest nasłuchiwanie na wybranych portach i akceptowanie / odrzucanie / odpowiadanie na dowolne protokoły na dowolnych skonfigurowanych portach.

Na przykład usługi sieciowe HTTP są zwykle świadczone na porcie 80. Oznacza to, że gdy klient zna adres IP komputera, można założyć, że wysłanie wiadomości do portu 80 spowoduje odczytanie / odpowiedź tej wiadomości przez usługę internetową tego komputera. Ale nie musi tak być. Jeśli serwer jest skonfigurowany do nasłuchiwania przychodzących żądań internetowych na porcie 9000, każdy klient, który może uzyskać dostęp do portu 9000, będzie mógł uzyskać dostęp do swojej usługi internetowej. Jeśli serwer znajduje się za serwerem proxy / NAT / routerem, który przekierowuje port 10000 na port 9000, a klient wysyła żądanie sieciowe na port 10000, serwer odbierze je na porcie 9000 i również odpowie.

Przekierowanie / mapowanie na serwerze WWW

Zapytałeś o mapowanie przekierowania lub przepisanie w komentarzu. Są to funkcje, które może wykonywać serwer WWW. Zasadniczo możesz skonfigurować serwer WWW (lub większość / wiele serwerów WWW) do zarządzania sposobem, w jaki obsługuje on adres URL otrzymany w żądaniu. Może więc wewnętrznie modyfikować adres URL po otrzymaniu, aby różne adresy URL były obsługiwane w ten sam sposób, lub naprawiać typowe literówki (mapowanie), lub może faktycznie odpowiedzieć, aby sam klient zapytał po raz drugi, używając innego, zastępczego adresu URL (przeadresować).

Mają one swoje zastosowania i mogą w zasadzie obsłużyć twój przypadek użycia, ale nie brzmią jak „właściwe” rozwiązanie z następujących powodów:

1. Nie sądzę, żeby mapowanie w ogóle pomogło . Mapowanie jest prawie całkowicie wewnętrzne dla serwera WWW, mówi „traktuj ten adres URL tak, jakby to był ten adres URL”. Na przykład możesz użyć mapowania adresów URL serwera WWW, aby umożliwić użytkownikowi zapytanie o forum przy użyciu bardzo starych, starych i aktualnych adresów URL (dla wygody użytkownika) przy użyciu „ https://example.com/index.php?area-=forum&topic = 2 ”, także„ https://example.com/forum.php?topic=2 ”, a także„ https://forum.example.com?topic=2”i poradzić sobie z tym tylko raz, mapując pierwsze dwa z nich wewnętrznie na trzeci adres URL, jako pierwszy krok w obsłudze zapytania. Ponieważ cele te wpływają na ścieżkę zapytania, a nie na adres IP / port, mapowanie nie jest zbyt przydatne zarządzanie portem, a w twoim przypadku klient nigdy tak naprawdę nie pyta 8080.
2. Przekierowanie działałoby, ale może nie być tym, czego chcesz . Przekierowanie na serwerze internetowym polega na tym, że serwer internetowy faktycznie odbiera zapytanie (ponieważ są to wewnętrzne funkcje serwera WWW). Serwer sieci i tak musiałby nasłuchiwać na porcie 80, aby otrzymać oryginalne zapytanie, aby odpowiedzieć przekierowaniem / mapą. Musiałby także nasłuchiwać na porcie 8080. Funkcjonalnie potrzebowałby reguły przekierowania, aby kazać każdemu klientowi pytającemu o port 80, aby zapytał go ponownie za pomocą adresu URL „: 8080”, co nie brzmi jak to, co chcesz zrobić. Użytkownik zobaczy także nowy adres URL z „: 8080”, podczas gdy wygląda na to, że chcesz, aby był „przezroczysty” i nie był wyświetlany.
3. Również przekierowanie działałoby tylko w celu przekierowania standardowego portu (80 lub 443) - nie można było przekierować portu 2000 do 8080, ponieważ, po pierwsze, klient domyślnie nie sprawdzałby 2000, więc nigdy dostać się do serwera WWW, nawet jeśli nasłuchiwał w 2000 roku. Może to jednak nie stanowić problemu.

Jeśli jednak chcesz przekierować „inteligentne”, gdzie tylko niektóre zapytania są przekierowywane do 8080, może to być dobry sposób, ponieważ przekierowanie może zawierać logikę decydującą, które adresy URL powinny zostać przekierowane, podczas gdy mapowanie portów (poniżej) zmapowałoby wszystko .

Jak poprawnie to zrobić

Odpowiedź na twoje pytanie brzmi: chcesz, aby serwer WWW odpowiadał na żądania sieciowe, które klient wysyła na domyślny port (80/443), ale które serwer faktycznie odbiera na porcie 8080.

Oznacza to, jak widać, że potrzebujesz czegoś pomiędzy, co mapuje porty między klientem a serwerem . W ten sposób klient wysyła port 80 (domyślny port używany przez przeglądarki internetowe), ale tak naprawdę jest odbierany na porcie 8080 przez serwer WWW. Oczywiście będziesz musiał skonfigurować serwer WWW, aby nasłuchiwał na porcie 8080, ponieważ nie jest to standardem, ale jest to łatwe i każdy serwer sieciowy powinien mieć określone porty nasłuchiwania.

Najbardziej typowym sposobem na to jest router / firewall, poprzez mapowanie portów.

Mówiąc prościej, aby to zrobić, router otrzymuje regułę, że wszystko, co ma docelowy adres IP i docelowy port = 80, powinno być przekazywane do sieci LAN, a docelowy port należy zmienić na 8080. Ani serwer WWW, ani klient nie będą świadomi zmiany (jest w 100% obsługiwany przez router), więc będzie w 100% przezroczysty dla obu z nich. Klient nie ma w adresie URL „: 8080” i nie musi niczego przekierowywać, ponieważ wysyła zapytanie do portu 80, a serwer WWW może zignorować port 80 i nasłuchiwać tylko na 8080, ponieważ nigdy nie otrzymuje zapytań na porcie 80 .

Jeśli chcesz prosty, bezpośredni sposób, podobny do tego, co zrobiłby „DNS dla portów”, jest to prawdopodobnie najbliższy odpowiednik tego, o co pytasz w swoim pytaniu.

Nie możesz

To znaczy technicznie można to zrobić. DNS słynie z możliwości przesłania nazwy domeny i uzyskania adresu IP. Jednak trochę przestudiowałem protokół DNS i naprawdę DNS jest technicznie zdolny do działania jako mechanizm zapytań / odpowiedzi dla znacznie więcej niż tylko nazw domen i adresów IP. Jednym z możliwych podejść byłoby użycie rekordu zasobu DNS, który nie jest typowym typem A lub AAAA, takiego jak rekord TXT (który jest technicznie tylko tekstem i może być użyty do czegokolwiek) lub rekord SRV lub jakikolwiek inny nowszy wybrany typ rekordu zasobu.

Jeśli tworzysz własne oprogramowanie (zarówno klient, jak i serwer), może nie istnieć żaden techniczny powód, aby tego nie robić, z wyjątkiem tego, że wiesz, że niektóre osoby korzystają z firm hostingowych DNS i ograniczają je do korzystania tylko z niektórych typów rekordów. To niefortunne, ponieważ ludzie, którzy prowadzą własne serwery DNS, z pewnością mają wystarczającą elastyczność na takie rzeczy.

Jeśli jednak nie tworzysz własnego protokołu sieciowego (na przykład, jeśli chcesz korzystać z protokołu HTTP), prawdopodobnie napotkasz poważny problem, polegający na tym, że istniejące oprogramowanie nie będzie korzystało z niestandardowego rozwiązania, chyba że użyjesz rozwiązania, które są już ustalone. To będzie bariera. Nie jest to technicznie niemożliwe. Bariera społeczna: czy możesz przekonać wszystkich do robienia rzeczy po swojemu?

Teraz, gdy wyjaśniłem, dlaczego nie możesz tego zrobić, mogę znaleźć rozwiązanie tego, czego szukasz. Najpierw przyjrzyjmy się, dlaczego mamy nawet adresy IP i porty.

Adresy IP i porty robią różne rzeczy. Celem adresu IP jest spełnienie celów Warstwy 2 i 3 Modelu komunikacji sieciowej OSI. Adres IP ma na celu identyfikację, do którego komputera ma dotrzeć ruch. Fakt, że możemy użyć numeru portu do tego celu, poprzez zapory ogniowe / routery sprawdzające numery portów w celu wykonania NAPT (translacja oparta na portach sieciowych, zwana także PNAT lub po prostu NAT), jest nowszą techniką, która wykorzystuje zasób (informacje), ale nie był częścią oryginalnego projektu. Jeśli odejdziemy na chwilę od tego „nadużycia” numerów portów i rozważymy oryginalny projekt, możemy znaleźć łatwiejsze rozwiązanie. Konstrukcja Internetu polegała na wyszukiwaniu maszyn przy użyciu adresów IP.

Istotą „numeru portu” używanego przez TCP i UDP oraz niektóre alternatywy jest możliwość śledzenia poszczególnych rozmów. Pomaga to w wyrównaniu komunikacji z uruchomionymi programami. Tak więc, jeśli komputer odbiera ruch na porcie TCP 80, będzie wiedział, że ruch sieciowy powinien być wykorzystywany przez program, którym jest serwer WWW. Jeśli przeglądarka internetowa pobierze jednocześnie wiele grafik, kombinacje numerów „portu źródłowego” i „portu docelowego” mogą śledzić, które dane są przeznaczone dla jakiej grafiki, więc te jednoczesne rozmowy mogą wystąpić bez pomieszania danych.

Teraz przypuszczam, że masz dostęp do serwera DNS i wydaje ci się, że uważasz, że administracja DNS byłaby wygodna, aby móc trochę bardziej poradzić sobie z routingiem. Ale DNS nie wydaje się być w stanie pomóc ci uzyskać numeru portu. Co możesz zrobić?

Rozważ IPv6. IPv6 pozwala uzyskać znacznie więcej adresów IP. Ponadto, w przeciwieństwie do niektórych implementacji protokołu IPv4, urządzenia korzystające z protokołu IPv6 zazwyczaj mogą z łatwością obsługiwać wiele aktywnych adresów IPv6 jednocześnie. Jeśli więc chcesz mieć trzy różne protokoły sieciowe na jednym komputerze, możesz przypisać co najmniej trzy różne adresy IPv6 do tego samego komputera. A potem możesz robić dowolne shenanigany routingu, korzystając z tych adresów IPv6.

Następnie możesz użyć typu rekordu zasobu AAAA, aby przypisać nazwę do tego adresu IPv6, który twój projekt sieci może potraktować jako skutecznie dedykowany konkretnej usłudze na określonym komputerze.

Wallah, teraz masz DNS skutecznie wskazujący na oprogramowanie i osiągnąłeś ten cel bez konieczności polegania na tym, aby DNS wskazywał numer portu, co nie działa dobrze po prostu dlatego, że ta funkcja tak się składa, że ​​nie jest często utrzymany.

Możliwy sprzeciw:
a jeśli czujesz, że utknąłeś w IPv4 i myślisz, że IPv6 jakoś nie jest obsługiwany, zachęcam do podjęcia próby rozwiązania tego problemu. Ten problem prawdopodobnie będzie łatwiejszy do naprawienia (być może przy użyciu tunelowania) i prawdopodobnie będzie on bardziej satysfakcjonujący, gdy go zaimplementujesz.