Vraag Loopback naar doorgestuurd openbaar IP-adres van lokaal netwerk - haarspeld NAT


Dit is een Canonical Question over haarspeld NAT (loopback NAT).

De generieke vorm van deze vraag is:

We hebben een netwerk met clients, een server en een NAT-router. Er is port forwarding op de router naar de server, dus sommige services zijn extern beschikbaar. We hebben DNS naar het externe IP-adres. Lokale netwerkclients slagen er niet in verbinding te maken, maar extern werk.

  • Waarom faalt dit?
  • Hoe kan ik een uniform naamgevingsschema maken (DNS-namen die zowel lokaal als extern werken)?

Deze vraag heeft antwoorden samengevoegd uit meerdere andere vragen. Ze verwezen oorspronkelijk naar FreeBSD, D-Link, Microtik en andere apparatuur. Ze proberen allemaal hetzelfde probleem echter op te lossen.


43
2017-08-18 15:16


oorsprong


Als het uw bedoeling is om de toegang vanaf internet te testen, heeft het geen zin om op zijn best de routes en / of DNS-instellingen van de router te schaden, van binnenuit controleert u of het interne gedeelte van de router werkt. Ik stel voor dat je ergens aan de buitenkant een proxyserver gebruikt.


antwoorden:


Wat u zoekt, wordt "hairpin NAT" genoemd. Aanvragen van de interne interface voor een IP-adres toegewezen aan de externe interface moeten NAT'ted zijn alsof ze afkomstig zijn van de externe interface.

Ik ken helemaal geen FreeBSD vertrouwdheid, maar lees de "pf" handleiding voor OpenBSD (http://www.openbsd.org/faq/pf/rdr.html) de voorgestelde oplossingen van split-horizon DNS, met behulp van een DMZ-netwerk, of TCP-proxying leiden me tot de overtuiging dat "pf" hairpin NAT niet ondersteunt.

Ik zou kijken naar de route van DNS met gesplitste horizon gaan en intern geen IP-adressen in URL's gebruiken, maar in plaats daarvan namen gebruiken.


14
2017-08-18 15:30



Ik heb deze thread doorgenomen terwijl ik probeerde hetzelfde probleem op te lossen, en hoewel het waar is dat FreeBSD hairpin nat out of the box niet ondersteunt, zijn er manieren om het interne -> externe -> interne verkeer om te leiden en NAT. - eggo
Bijvoorbeeld: no nat on $int_if proto tcp from $int_if to $int_net  , nat on $int_if proto tcp from $int_net to $hairpin_int port $hairpin_ports -> $int_if , rdr on $int_if proto tcp from $int_net to $ext_if port $hairpin_ports -> $hairpin_int - eggo


Omdat dit is verheven tot de canonieke vraag over haarspeld NAT, Ik dacht dat het waarschijnlijk een antwoord moest hebben dat meer algemeen geldig was dan het momenteel geaccepteerde antwoord, dat (hoewel uitstekend) specifiek betrekking heeft op FreeBSD.

Deze vraag is van toepassing op diensten die worden geleverd door servers op RFC1918-geadresseerde IPv4-netwerken, die beschikbaar worden gesteld aan externe gebruikers door bestemmings-NAT (DNAT) aan de gateway te introduceren. Interne gebruikers proberen vervolgens via het externe adres toegang te krijgen tot die services. Hun pakket gaat van de client naar het gateway-apparaat, dat het bestemmingsadres herschrijft en het onmiddellijk terug injecteert in het interne netwerk. Het is deze scherpe omweg die het pakket maakt bij de gateway die de naam doet ontstaan haarspeld NAT, naar analogie met de haarspeldbocht.

Het probleem ontstaat wanneer het gatewayapparaat het bestemmingsadres opnieuw schrijft, maar niet het bronadres. De server ontvangt dan een pakket met een intern bestemmingsadres (zijn eigen adres) en een intern bronadres (van de klant); het weet dat het rechtstreeks op zo'n adres kan antwoorden, dus het doet het. Aangezien dit antwoord direct is, gaat het niet via de gateway, die daarom nooit de kans krijgt om het effect van inkomende bestemming NAT op het initiële pakket in evenwicht te brengen door het bronadres van het retourpakket te herschrijven.

De client verzendt dus een pakket naar een extern IP-adres, maar krijgt antwoord van een intern IP adres. Het heeft geen idee dat de twee pakketten deel uitmaken van hetzelfde gesprek, dus er gebeurt geen gesprek.

De oplossing is dat voor pakketten die een dergelijke NAT-bestemming vereisen en die de gateway bereiken vanuit het interne netwerk, om ook bron-NAT (SNAT) op het inkomende pakket uit te voeren, meestal door het bronadres te herschrijven als dat van de gateway. De server denkt dan dat de client de gateway zelf is en antwoordt er direct op. Dat op zijn beurt geeft de gateway een kans om de effecten van zowel DNAT als SNAT op het inkomende pakket in evenwicht te brengen door zowel bron- als bestemmingsadressen op het retourpakket te herschrijven.

De klant denkt dat hij met een externe server praat. De server denkt dat hij met het gateway-apparaat praat. Alle partijen zijn blij. Een diagram kan op dit moment van pas komen:

enter image description here

Sommige gateway-apparaten voor consumenten zijn helder genoeg om die pakketten te herkennen waarvoor de tweede NAT-stap nodig is, en die zullen waarschijnlijk out-of-the-box werken in een hairpin-NAT-scenario. Anderen zijn dat niet en zullen dat ook niet doen, en het is onwaarschijnlijk dat ze kunnen werken. Een bespreking van apparaten van consumentenklasse die buiten het onderwerp vallen voor Serverfout.

Goede netwerkapparaten kunnen over het algemeen wel worden verteld om te werken, maar - omdat ze hun beheerders niet ten tweeden male hoeven te raden - moeten ze dat wel doen. Linux gebruikt iptables om de DNAT te doen als volgt:

iptables -t nat -A PREROUTING  -p tcp --dport 80 -j DNAT --to-destination 192.168.3.11

waarmee een eenvoudige DNAT voor de HTTP-poort, een interne server kan worden ingeschakeld 192.168.3.11. Maar om hairpin NAT in te schakelen, zou er ook een regel nodig zijn zoals:

iptables -t nat -A POSTROUTING -d 192.168.3.11 -p tcp --dport 80 -j MASQUERADE

Merk op dat dergelijke regels op de juiste plaats in de relevante ketens moeten zitten om goed te kunnen werken, en afhankelijk van de instellingen in de filter keten, aanvullende regels kunnen nodig zijn om het NATted-verkeer te laten stromen. Al dergelijke discussies vallen buiten het bestek van dit antwoord.

Maar zoals anderen al hebben gezegd, is de juiste manier om haarspeld NAT te gebruiken niet de beste manier om het probleem aan te pakken. Het beste is split-horizon DNS, waar uw organisatie verschillende antwoorden biedt voor de oorspronkelijke lookup, afhankelijk van waar de aanvragende client zich bevindt, door verschillende fysieke servers te hebben voor interne of externe gebruikers, of door de DNS-server te configureren om anders te reageren op basis van het adres van de verzoekende klant.


46
2017-11-27 12:20



Ik vraag me een beetje af over de adressen op pakketten die worden uitgewisseld tussen gateway en server. Zou het niet consistenter zijn als de server het openbare IP-adres van de router zag als het client-IP? Technisch kunnen beide werken, maar om consistent te blijven met hoe andere servers de clients zien, zou het openbare IP moeten gebruiken. - kasperd
Ik ga ervan uit dat je verwijst naar het laatste geval, "juiste haarspeld NAT". Het belangrijkste is om het bronadres van het inkomende pakket zodanig te herschrijven dat het teruggaat naar de router, die vervolgens zowel de DNAT als de SNAT kan omkeren en zo het probleem kan vermijden. Welke van de vele adressen die de router gebruikt om dit te doen, is meer een punt van smaak, en als je hiermee bezig bent iptables, is zeker iets dat u kunt configureren als u dat wilt. - MadHatter
Veel beheerders, waaronder ikzelf, beschouwen DNS met split-horizon als een genezing die erger is dan ziekte. Als een extra SNAT helemaal een ziekte kan worden genoemd. Een split-view DNS verwart mensen, terwijl het het leven van routers eenvoudiger maakt. Dit onderwerp zou beter kunnen worden afgehandeld door een afzonderlijke vraag / antwoord van ServerFault. - kubanczyk
Mijn antwoord gaat heel erg over hairpin NAT. Ik zie de voor- en nadelen van het openen van een canonieke "split-horizon DNS" -vraag: pro's zijn onder meer een vraag hebben over het gebruik en de problemen van SHDNS, maar de nadelen zijn dat deze vraag al veel andere vragen heeft gehad die te maken hebben met het is erin samengevoegd, dus dat kan ook met je vraag gebeuren. Als ik het was, zou ik de kwestie meta aan de orde stellen en consensus zoeken. Als zo'n vraag wel wordt geschreven, kijk ik er naar uit om je antwoord erop te lezen! - MadHatter
@MadHatter Waar moet ik het commando iptables schrijven? op client of gateway of server? - Rock Balbao


Het probleem hier is dat uw router het adres van uw interne klant niet NAT. De TCP-handshake mislukt dus.

Laten we aannemen dat volgende IP's

  • Client: 192.168.1.3
  • Server: 192.168.1.2
  • Interne router: 192.168.1
  • Externe router: 123.123.123.1

Dit is wat er gebeurt:

  1. Client (192.168.1.3) verzendt TCP-SYN naar uw externe IP, poort 80 (123.123.123.1:80)
  2. Router ziet regel voor poortdoorschakeling en stuurt het pakket door naar de server (192.168.1.2:80) zonder de bron-IP te wijzigen (192.168.1.3)
  3. Client wacht op een SYN-ACK vanaf het externe IP
  4. Server stuurt zijn antwoord rechtstreeks terug naar de klant, omdat het op hetzelfde subnet staat. Het verzendt het pakket niet naar de router, waardoor de NAT zou worden teruggedraaid.
  5. Klant krijgt een SYN-ACK van 192.168.1.2 in plaats van 123.123.123.1. En gooit het weg.
  6. Client wacht nog steeds op een SYN-ACK vanaf 123.123.123.1 en time-out.

8
2017-10-10 11:32





Waarom zou u niet overal gesplitste horizon dns gebruiken in plaats van IP-adressen te coderen? Je zou ext.ydomain hebben dat naar buiten wijst naar 217.x.x.x en vervolgens naar 192.x.x.x aan de binnenkant.


4
2017-08-20 08:42



Als je een moment hebt, zou je kunnen uitleggen wat Split-Horizon DNS is, hoe het werkt en wat de belangrijkste nadelen zijn. Dit is nu een canonieke vraag en het zou leuk zijn om een ​​completer antwoord te krijgen. - Chris S


Onlangs antwoordde een vergelijkbare vraag: Statische NAT van Cisco werkt niet op LAN-zijde en besefte net dat dit een kanunnikvraag is. Dus sta me toe de oplossing hier samen te vatten.

Allereerst: vergeet NAT (als je kunt) - de vraag gaat helemaal niet over het configureren van NAT. Het gaat over het benaderen van een server achter NAT geplaatst van zowel internet als LAN. Het gebruik van twee DNS-zones is een haalbaar alternatief, maar niet altijd de oplossing. Maar de oplossing bestaat en is ongelooflijk eenvoudig (hoewel niet perfect, waarschijnlijk):

(1) op de server: voeg het openbare IP-adres toe als een secundair IP-adres op de netwerkinterface van de server met het masker 255.255.255.255 (webservice of wat u maar wilt op de server zou ook op dit IP-adres moeten luisteren); met alle moderne besturingssystemen kunt u dit doen (of een loopback-interface met het openbare IP-adres dat eraan is toegewezen, kan worden gebruikt in plaats van een secundair IP-adres aan de primaire interface toe te voegen).

(2) op de LAN-hosts: voeg een hostroute toe voor het openbare IP-adres, bijvoorbeeld, voor Windows-hosts gebruikt u de volgende opdracht: route -p voeg 203.0.113.130 masker 255.255.255.255 192.168.1.11 toe (je kunt ook de DHCP "statische route" optie gebruiken om de route te verspreiden). Of, als er (een) L3-switch (s) / router (s) is tussen de clients en de internetgerichte router, configureer die hostroute dan op deze (deze) tussenliggende switch (es) / router (s), niet op de klanten.

Voor degenen die te maken hebben met de TCP drieweg-handshake: deze werkt in de voorgestelde configuratie goed.

Geef feedback (tenminste, stem).


2
2017-11-03 11:14



Vereiste nr. 2 zorgt ervoor dat dit niet goed werkt op BYOD-netwerken ... - Michael


Ik beantwoord mijn vragen alleen maar om de horizon te verbreden voor mensen met soortgelijke problemen.

Ik neem contact op met mijn ISP en vraag hen om mijn problemen op te lossen. Wat ze me hadden aangeboden, is een ander openbaar IP-adres, alleen voor de server, Nu heb ik lokaal verkeer aan de WAN-kant van FreeBSD en hebben we specifieke pipes gemaakt snellere doorvoer van lokaal verkeer naar openbare IP van Server


1
2017-08-20 08:37



Deze oplossing implementeert een Perimeternetwerk of DMZ en is een goed alternatief voor zowel Hairpin NAT als Split-Horizon DNS. - Chris S


Als het een originele D-Link-router is (d.w.z. niet Rev. D / Firmwareversie 1.00VG van Virgin Media), zou u de instellingen moeten kunnen aanpassen om dit probleem te omzeilen. (Ik ben het echter om veel andere redenen eens met de suggestie van de vorige poster van DD-WRT!)

  1. Log in op de webinterface van de router
  2. Klik bovenaan op het tabblad Geavanceerd
  3. Klik op het tabblad Firewallinstellingen aan de linkerkant
  4. Klik op de Eindpunt onafhankelijk keuzerondje onder TCP-eindpuntfilters, zoals weergegeven in de onderstaande schermafbeelding (of bekijk de router-emulator op de website van D-Link)
  5. Wijzigingen opslaan; u bent klaar

D-Link router web UI screenshot

Deze schermafbeelding is van het Rev. C-model; de jouwe kan iets anders zijn.


1
2018-03-11 02:37