Perché non più organizzazioni utilizzano NAT interno-interno o soluzioni simili per consentire forcine NAT?

Il NAT back-to-inside alias noto anche come NAT loopback risolve i problemi NAT della forcina quando si accede a un server Web sull'interfaccia esterna di un ASA o un dispositivo simile dai computer sull'interfaccia interna. Ciò impedisce agli amministratori DNS di mantenere una zona DNS interna duplicata con gli indirizzi RFC1918 corrispondenti per i loro server che sono NATted verso indirizzi pubblici. Non sono un ingegnere di rete, quindi potrei mancare qualcosa, ma questo sembra un gioco da ragazzi da configurare e implementare. Il routing asimmetrico può essere un problema ma è facilmente mitigabile.

Nella mia esperienza, gli amministratori / ingegneri di rete preferiscono che le persone dei sistemi eseguano split-dns piuttosto che configurare i firewall per gestire correttamente le forcine NAT. Perchè è questo?

Ci sono alcuni motivi per cui non lo farei:

• Perché mettere a dura prova i router e il firewall DMZ se non è necessario? La maggior parte dei nostri servizi interni non si trova nella DMZ ma nell'area aziendale generale, con servizi di proxy nella DMZ per l'accesso remoto occasionale. Fare nat da dentro a dentro aggiunge più carico alla DMZ, che nel nostro caso sarebbe significativo.
• Se non si esegue DNAT + SNAT, si otterrà il routing asimmettrico, che è notoriamente difficile da ottenere. Quindi SNAT e perdi informazioni IP di origine. Tuttavia, è dannatamente utile collegare gli IP di origine alle persone per la risoluzione dei problemi. O di tanto in tanto a scoccare scopi in caso di stupidità. "Ehi, questo IP sta facendo qualcosa di strano sul servizio non autenticato X" "Oh, guardiamo nei registri del server imap chi è".

Ovviamente, non ci può essere la risposta definitiva per questo, ma potrei pensare a una serie di motivi:

1. Eleganza: NAT non è molto elegante all'inizio, ma una necessità con lo spazio di indirizzi limitato di IPv4. Se posso evitare il NAT, lo farò. Con IPv6 il problema si risolve in ogni caso.
2. Complessità: specialmente nel caso in cui non si disponga di un solo router "core" che crei tutti i limiti di sicurezza, le configurazioni dei filtri possono diventare piuttosto complicate. O quello o dovresti diffondere e mantenere le regole NAT su quasi tutti i tuoi dispositivi router.
3. Riferimento: ovunque gli amministratori del firewall siano persone diverse rispetto al resto del team di amministrazione del server, potrebbero essere difficili da raggiungere. Al fine di garantire che le modifiche non vengano ritardate dal backlog (o dalle ferie) dell'amministratore del firewall, viene scelta l'opzione per mantenere la responsabilità nello stesso team
4. Portabilità e pratica comune: l'uso delle viste DNS è "la cosa che tutti sanno è fatto" per risolvere questo problema. Non tutti i router di confine supportano il NAT di loopback in modo semplice, meno persone probabilmente sapranno come configurarlo correttamente nel proprio ambiente specifico. Durante la risoluzione dei problemi di rete, l'equipaggio dovrebbe essere consapevole della configurazione NAT della forcina e di tutte le sue implicazioni, anche quando inseguono un problema apparentemente non correlato

Disclaimer - questa è una risposta esca di fiamma.

Un motivo comune per cui penso che soluzioni come questa siano evitate è una paura / odio irrazionale per il NAT da parte degli ingegneri di rete . Se vuoi vedere alcuni esempi di discussione su questo, dai un'occhiata a questi:

• http://packetpushers.net/show-86-connect-to-the-ipv6-internet-for-free-using-tunnelbroker-net/
• http://networkingnerd.net/2012/04/02/ipv6-nat-and-the-sme-a-response/ (il blog di Tom sembra continuare ad attirare una discussione piuttosto fervida su NAT / IPv6)
• http://libertysys.com.au/blog/nat-is-evil-but-not-bad (il mio blog)

Da quello che posso dire, gran parte di questa paura deriva dalle cattive implementazioni di Cisco del NAT (quindi in questo senso potrebbe non essere irrazionale), ma a mio avviso il "classico" ingegnere di rete è così ben educato nel "NAT è cattiva "visione del mondo, che non può vedere esempi ovvi come questo in cui ha perfettamente senso e semplifica effettivamente la soluzione.

Ecco fatto: riduci il voto al tuo cuore! :-)

La mia ipotesi è:

1. Il DNS diviso è più facilmente comprensibile.
2. NAT Hairpin utilizza risorse sul router mentre split-dns no.
3. I router potrebbero avere limiti di larghezza di banda che non è possibile ottenere attraverso un'installazione split-dns.
4. Split-dns avrà sempre prestazioni migliori quando si evita un routing / passi NAT.

Tra i lati positivi per NAT tornante,

• Una volta installato, funziona.
• Nessun problema con le cache DNS per laptop spostate tra la rete di lavoro e Internet pubblico.
• Il DNS per un server è gestito in un solo posto.

Per una piccola rete con bassi requisiti di traffico verso un server interno andrei con NAT tornante. Per una rete più ampia con molte connessioni al server e in cui larghezza di banda e latenza sono importanti, utilizzare split-dns.

Dal mio punto di vista, questo è cambiato un po 'tra la transizione da Cisco Pix ad ASA. Ho perso il aliascomando. E in generale, l'accesso all'indirizzo esterno dall'interfaccia interna su un firewall Cisco richiede una sorta di trucco. Vedi: Come posso raggiungere il mio server interno sull'IP esterno?

Tuttavia, non è sempre necessario mantenere una zona DNS interna duplicata. Cisco ASA può reindirizzare le query DNS per indirizzi esterni a indirizzi interni se configurato sull'istruzione NAT. Ma preferisco mantenere una zona interna per la zona DNS pubblica per avere quella granularità ed essere in grado di gestirla in un posto piuttosto che passare al firewall.

In genere, ci sono solo pochi server che possono richiedere questo all'interno di un ambiente (posta, web, alcuni servizi pubblici), quindi non è stato un problema tremendo.

Mi vengono in mente alcuni motivi:

1. Molte organizzazioni hanno già diviso il DNS per non voler pubblicare tutte le loro informazioni DNS interne nel mondo, quindi non è un ulteriore sforzo per gestire i pochi server esposti anche tramite un IP pubblico.
2. Man mano che l'organizzazione e la sua rete diventano più grandi, spesso separano i sistemi che servono le persone interne dai server che servono gli esterni, quindi il routing a quelli esterni per l'uso interno può essere un percorso di rete molto più lungo.
3. Meno modifiche apportano ai pacchetti i dispositivi intermedi, migliore è quando si tratta di latenza, tempo di risposta, carico del dispositivo e risoluzione dei problemi.
4. (molto minore, è vero) Esistono protocolli che NAT continuerà a rompersi se il dispositivo NATing non va oltre le intestazioni del pacchetto e modifica i dati in esso con i nuovi indirizzi IP. Anche se è solo un caso di memoria istituzionale, è ancora un motivo valido per evitarlo, specialmente se si tratta di un protocollo di cui non sono sicuri al 100%.

Se avessi intenzione di utilizzare il loopback NAT sarei un po 'preoccupato di come il dispositivo NAT gestirà gli indirizzi sorgente falsificati. Se non controlla quale interfaccia ha ricevuto il pacchetto, allora potrei falsificare gli indirizzi interni dalla WAN e inviare pacchetti al server con indirizzi interni. Non sono riuscito a ottenere risposte, ma potrei essere in grado di compromettere il server utilizzando un indirizzo interno.

Vorrei impostare il loopback NAT, collegarlo allo switch DMZ e inviare i pacchetti con indirizzi sorgente interni falsificati. Controllare il registro del server per vedere se sono stati ricevuti. Poi andrei al bar a vedere se il mio ISP sta bloccando gli indirizzi contraffatti. Se trovassi che il mio router NAT non stava controllando l'interfaccia di origine, probabilmente non avrei usato il loopback NAT anche se il mio ISP stava controllando.