Il mio record DNS può puntare solo a un indirizzo IP. Come faccio a raggiungere una porta?


10

Sono abbastanza nuovo nell'amministrazione della rete e quindi sono già entusiasta di aver impostato con successo un record DNS.

Ora sono un po 'confuso, perché vorrei avere questo URL:

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

essere effettivamente raggiunto da questo

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

In questo modo gli utenti possono raggiungere il servizio sulla porta 8080 senza dover impostare esplicitamente la porta.

Come posso fare questo? Ho bisogno di un'applicazione speciale sul mio server? O eventuali elementi di reindirizzamento da applicare alle richieste?


4
Il browser per impostazione predefinita non accede alla porta 8080. È un errore nel digitare la domanda?
Džuris,

idea sbagliata di cosa sia un DNS e cosa fa.
CONvocato

@ Džuris Na è stato un mio errore pensare che 8080 sia il default http invece di 80
xetra11

Risposte:


32

I record DNS non possono puntare alle porte (con alcune eccezioni di casi speciali che non si applicano qui).

Se si dispone di un servizio Web in ascolto sulla porta 8080 e si desidera raggiungerlo senza specificare questa porta, sono disponibili 3 opzioni:

  • Renderlo effettivamente in ascolto sulla porta 80 (o 443 con https).
  • Configura tutto ciò che è già in ascolto sulla porta 80 per inoltrare richieste al tuo servizio sulla porta 8080 (proxy inverso).
  • Se riesci a convivere con un reindirizzamento, usa questo invece di un proxy, ma i tuoi clienti vedranno la :8080parte nelle loro barre degli indirizzi dopo il reindirizzamento.

10
E se potessimo usare i record SRV e specificare le porte per i servizi ... I browser troppo cattivi non lo usano.
Jacob Evans,

4
@JacobEvans: i record SRV per ogni cosa è un mio vecchio sogno. Renderebbe le cose molto più facili (tranne per gli amministratori del firewall che ora possono semplicemente bloccare tutto tranne 80 e 443)
Sven

I record SRV funzionano molto bene per alcuni servizi, come XMPP ... ma purtroppo non molti (e non HTTP di sicuro)
Josh

Opzione 4: port forwarding da un firewall
Joel Coel,

10

I server Web ascoltano la porta TCP 80 per impostazione predefinita. Se non si desidera digitare esplicitamente il numero di porta nell'URL, sono disponibili alcune opzioni:

  • È possibile riconfigurare il server Web per utilizzare la porta 80 anziché la porta 8080. Questo è consigliato per server Web come nginx o Apache ma non per server Web come Gunicorn. Anche questa opzione non è sempre possibile in quanto quella porta potrebbe essere già in uso da un altro server web.

    Inoltre, quando il server si trova dietro un gateway NAT, non possiede l'indirizzo IP pubblico e la combinazione di tale indirizzo NAT pubblico e porta 80 potrebbe già essere inoltrata a un altro server Web.

  • Puoi mettere un server proxy inverso di fronte al tuo server Web che accetta il traffico sulla porta TCP 80 e lo invia al tuo server Web sulla porta TCP 8080. Ciò funzionerà anche se la porta 80 è già in uso. Posiziona semplicemente il server proxy inverso di fronte a entrambi i server Web, facendo in modo che entrambi ascoltino porte diverse da 80.

Al fine di fornire un aiuto migliore e più dettagliato su quale opzione potrebbe essere la migliore e le limitazioni ecc., Dobbiamo sapere di più sulla tua configurazione. Spero che questa spiegazione abbia già chiarito un po 'le cose.


Ho già le informazioni di cui ho bisogno! Ho scambiato la porta web predefinita 80 per 8080
xetra11

7

Risposta semplice, correlata al livello di domanda

Ignorando gli usi esotici del DNS e anche invertendo la ricerca DNS (non pertinente alla domanda), quasi tutto l'uso del DNS è nella forma:

  1. Il client invia un nome di dominio (completo o meno) a un server DNS
  2. Il server DNS restituisce le informazioni sul dominio dai suoi record. Di solito le informazioni chiave richieste sono l'indirizzo IP per comunicare con il web / e-mail su quel dominio o l'indirizzo IP di un altro server DNS in grado di fornire tali informazioni.

Una volta che il client ha contattato il server, il server stesso subentra e il sistema DNS esce dall'immagine.

Ciò significa che il sistema DNS non ha bisogno di fornire informazioni sulla porta e quasi mai lo fa. Quindi, sebbene lo scopo della domanda sia valido e spesso fatto, in realtà non è il sistema DNS a farlo. Ecco perché non puoi risolverlo :)

L'idea è che una volta che il client è in grado di individuare la macchina o il server specifici che sta cercando, spetta a quella macchina ascoltare su tutte le porte che sceglie e accettare / rifiutare / rispondere a qualsiasi protocollo su qualsiasi porta configurata.

Ad esempio, i servizi Web HTTP sono generalmente forniti sulla porta 80. Ciò significa che una volta che il client conosce un IP macchina, si può presumere che l'invio di un messaggio alla porta 80 comporterà la lettura / risposta di quel messaggio dal servizio Web di quella macchina. Ma non deve essere così. Se il server è configurato per l'ascolto di richieste Web in entrata sulla porta 9000, qualsiasi client in grado di raggiungere la porta 9000 sarà in grado di raggiungere il suo servizio Web. Se il server si trova dietro un proxy / NAT / router che reindirizza la porta 10000 alla porta 9000 e il client invia una richiesta Web sulla porta 10000, il server la riceverà sulla porta 9000 e risponderà.

Reindirizzamento / mapping all'interno del server Web

Hai chiesto informazioni sul mapping di reindirizzamento o riscrivi in ​​un commento. Queste sono funzioni che un web server può svolgere. Fondamentalmente, è possibile configurare il server Web (o la maggior parte / molti server Web) per gestire il modo in cui gestisce l'URL che riceve in una richiesta. Quindi può modificare internamente l'URL alla ricezione per far gestire URL diversi allo stesso modo o correggere errori di battitura comuni (mapping), oppure può effettivamente rispondere per dire al client stesso di chiedere una seconda volta, usando alcuni URL di sostituzione diversi (reindirizzare).

Questi hanno i loro usi e in linea di principio potrebbero gestire il tuo caso d'uso, ma non sembrano la soluzione "giusta" per te, per questi motivi:

  1. Non penso che la mappatura possa essere d'aiuto . La mappatura è quasi totalmente interno al server web, si dice "trattare questo URL, se si tratta di quel URL". Ad esempio, è possibile utilizzare la mappatura URL del server Web per consentire a un utente di interrogare un forum utilizzando URL molto vecchi, vecchi e attuali (per comodità dell'utente) utilizzando " https://example.com/index.php?area-=forum&topic = 2 ", anche" https://example.com/forum.php?topic=2 "e anche" https://forum.example.com?topic=2"e gestirlo solo una volta, mappando internamente i primi due sul terzo URL, come primo passo nella gestione della query. Poiché questi target influiscono sul percorso della query non sull'IP / porta, il mapping non è molto utile per gestione delle porte e, nel tuo caso, il client non interroga mai 8080.
  2. Il reindirizzamento avrebbe funzionato, ma potrebbe non essere quello che desideri . Il reindirizzamento nel server Web si basa sul server Web che riceve effettivamente la query (poiché si tratta di funzioni interne del server Web). Quindi il web server dovrebbe comunque ascoltare sulla porta 80 per ottenere la query originale, per rispondere con il reindirizzamento / mappa. Dovrebbe anche ascoltare sulla porta 8080. Funzionalmente, avrebbe bisogno di una regola di reindirizzamento per dire a qualsiasi client che interroga la porta 80, di interrogarla di nuovo usando l'URL ": 8080", che non suona come quello che vuoi fare. L'utente vedrebbe anche il nuovo URL con ": 8080", mentre sembra che tu voglia che sia "trasparente" e non mostrato.
  3. Anche il reindirizzamento funzionerebbe solo per reindirizzare una porta standard (80 o 443) - non si potrebbe reindirizzare la porta da 2000 a 8080, perché il client non eseguirà query su 2000 per impostazione predefinita, in primo luogo, quindi non lo farebbe mai accedere al server Web, anche se era in ascolto nel 2000. Questo potrebbe non essere un problema per te.

Tuttavia, se si desidera il reindirizzamento "intelligente", in cui solo alcune query vengono reindirizzate a 8080, questa potrebbe essere la strada da percorrere, poiché il reindirizzamento può includere la logica per decidere quali URL devono essere reindirizzati, mentre il mapping delle porte (sotto) mapperebbe tutto .

Come farlo correttamente

La risposta alla tua domanda è che vuoi che il server web risponda alle richieste web che il client invia alla porta predefinita (80/443), ma che il server riceve effettivamente sulla porta 8080.

Ciò significa che, come puoi vedere, hai bisogno di qualcosa tra quella che mappa le porte tra client e server . In questo modo, il client invia sulla porta 80 (porta predefinita utilizzata dai browser Web), ma viene effettivamente ricevuto sulla porta 8080 dal server Web. Ovviamente dovrai configurare il server web per l'ascolto sulla porta 8080, poiché questo non è standard, ma è facile e qualsiasi server web dovrebbe essere in grado di avere le sue porte di ascolto specificate.

Il modo più comune per farlo sarebbe all'interno del router / firewall, tramite il mapping delle porte.

In parole povere, per fare ciò, al router viene data una regola, che qualsiasi cosa ricevuta che abbia un IP di destinazione e una porta di destinazione = 80, dovrebbe essere passata nella LAN con la porta di destinazione modificata in 8080. Né il server web né il client saranno a conoscenza della modifica (è gestita al 100% dal router), quindi sarà trasparente al 100% per entrambi. Il client non avrà ": 8080" nel suo URL e non dovrà reindirizzare nulla, poiché richiede la porta 80 e il server Web può ignorare la porta 80 e ascoltare solo su 8080, poiché non riceve mai query sulla porta 80 .

Se vuoi un modo semplice e diretto, simile a quello che farebbe un "DNS per porte", questo è probabilmente l'equivalente più vicino a quello che stai chiedendo nella tua domanda.


Ho spesso sentito parlare del mapping di reindirizzamento o riscrivere? sono anche queste soluzioni?
xetra11,

Quelli sono i modificatori che nel calcio all'interno del web server, nella lavorazione di comando del cliente. Pertanto, se il server Web lo supporta, è possibile rispondere automaticamente a qualsiasi richiesta sulla porta 80, con un reindirizzamento HTTP allo stesso URL sulla porta 8080 - dopo tutto, il reindirizzamento HTTP / 80 -> HTTPS / 443 è praticamente la stessa cosa. Ma deve prima essere in grado di ricevere la query, quindi non funzionerebbe su porte per le quali non era configurato per l'ascolto, e probabilmente il client vede l'URL modificato: 8080. Farlo tramite il mapping delle porte lo rende invisibile al 100% al client, poiché usano sempre solo la porta 80 (8080 è solo interno al 100%)
Stilez

Ho aggiunto una sezione "Reindirizzamento / mapping all'interno del server Web" e ho ampliato l'ultima sezione, per coprire la tua domanda in modo più dettagliato. Spero che aiutino!
Stilez,

3

Non puoi.

Voglio dire, tecnicamente questo potrebbe essere fatto. DNS è famoso per essere in grado di inviare un nome di dominio e ottenere un indirizzo IP. Tuttavia, ho studiato un po 'il protocollo DNS e in realtà il DNS è tecnicamente in grado di agire come meccanismo di query / risposta per molto più che semplici nomi di dominio e indirizzi IP. Un possibile approccio sarebbe quello di utilizzare un record di risorse DNS che non è il tipico tipo A o AAAA, come un record TXT (che è tecnicamente solo testo e potrebbe essere utilizzato per qualsiasi cosa) o forse un record SRV o qualsiasi altro tipo di record di risorsa più recente selezionato.

Se stai inventando il tuo software (sia client che server), potrebbe non esserci alcun motivo tecnico per non fare una cosa del genere, ad eccezione del fatto che alcune persone utilizzano società di hosting DNS e le limitano a utilizzare solo determinati tipi di record. È un peccato, dato che le persone che gestiscono i propri server DNS hanno certamente abbastanza flessibilità per queste cose.

Tuttavia, se non si sta creando il proprio protocollo di rete (ad esempio, se si desidera utilizzare HTTP), è probabile che si verifichi un problema grave, ovvero che il software esistente non utilizzerà la soluzione personalizzata, a meno che non si utilizzi soluzioni già stabilite. Questa sarà la barriera. Non un'impossibilità tecnica. Una barriera sociale: riesci a convincere tutti a fare le cose a modo tuo?

Ora che ho spiegato perché non puoi farlo, potrei avere una soluzione per quello che stai cercando. Innanzitutto, diamo un'occhiata al perché abbiamo persino indirizzi IP e porte.

Gli indirizzi IP e le porte fanno cose diverse. Lo scopo dell'indirizzo IP è soddisfare gli obiettivi dei livelli 2 e 3 del modello OSI delle comunicazioni di rete. Lo scopo dell'indirizzo IP è identificare a quale computer dovrebbe andare il traffico. Il fatto che potremmo utilizzare un numero di porta a tale scopo, facendo in modo che i firewall / router indaghino i numeri di porta per eseguire NAPT (Network-based Translation Port-based Translation, talvolta chiamato anche PNAT o solo NAT), è una tecnica più recente che utilizza un risorsa (informazioni), ma non faceva parte del progetto originale. Se ci allontaniamo da questo "abuso" dei numeri di porta per un minuto e consideriamo il design originale, potremmo essere in grado di trovare una soluzione più semplice. Con la progettazione di Internet, le macchine dovevano essere trovate usando indirizzi IP.

Il punto di un "numero di porta", utilizzato da TCP e UDP e alcune alternative, è quello di essere in grado di tenere traccia delle singole conversazioni. Questo aiuta ad allineare la comunicazione con i programmi in esecuzione. Pertanto, se una macchina riceve traffico sulla porta TCP 80, la macchina saprà che il traffico di rete deve essere utilizzato dal programma che è il server web. Se un browser Web scarica contemporaneamente più elementi grafici, le combinazioni di numeri "porta di origine" e numeri "porta di destinazione" possono tenere traccia di quali dati sono destinati a quale elemento grafico, pertanto tali conversazioni simultanee possono avvenire senza confondere i dati.

Ora, suppongo che tu abbia accesso a un server DNS e ti sembra che pensi che l'amministrazione DNS sarebbe conveniente per essere in grado di gestire un po 'di più il routing del traffico. Ma il DNS non sembra essere in grado di aiutarti a ottenere un numero di porta. Cosa sai fare?

Prendi in considerazione IPv6. IPv6 ti consente di avere molti più indirizzi IP. Inoltre, a differenza di alcune implementazioni di IPv4, i dispositivi che utilizzano IPv6 possono in genere supportare contemporaneamente più indirizzi IPv6 attivi contemporaneamente. Pertanto, se si desidera avere tre diversi protocolli di rete su un computer, è possibile assegnare almeno tre diversi indirizzi IPv6 allo stesso computer. E poi puoi fare qualunque shenanigan di routing che ti piace con quegli indirizzi IPv6.

Quindi, è possibile utilizzare il tipo di record di risorse AAAA per assegnare un nome a quell'indirizzo IPv6, che la progettazione della rete può considerare efficacemente dedicata al servizio specifico sul computer specifico desiderato.

Wallah, ora hai DNS che punta efficacemente al pezzo di software e hai raggiunto quell'obiettivo senza dover provare a fare affidamento sul fatto che il DNS indichi un numero di porta, il che non funziona bene semplicemente perché quella funzionalità non è comune supportato.

Possibile obiezione:
e se ti senti bloccato con IPv4 e pensi che IPv6 non sia in qualche modo supportato, ti incoraggio a provare ad affrontare questo problema. Questo problema sarà probabilmente più facile da risolvere (forse usando una sorta di tunneling) e probabilmente finirà per essere una soluzione più gratificante una volta implementato.


IPv6 è sempre buono da supportare, ma non aiuta se per qualche motivo ora ti è permesso usare la porta 80 (o 443).
Paŭlo Ebermann,

Questo è vero, ma se il DNS fosse riuscito a trasmettere un numero di porta, anche questo non avrebbe funzionato attorno a un firewall che bloccasse il traffico su un numero di porta specifico. Oltre a ciò, la mia spiegazione su come usare IPv6 era davvero solo una parte della risposta, e credo che le parti precedenti della mia risposta rispondano alla domanda.
TOOGAM,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.