Vraag Heeft u aparte IPv4- en IPv6-luisterinstructies nodig in nginx?


Ik heb verschillende configuratievoorbeelden gezien voor het afhandelen van dual-stack IPv4 en IPv6 virtuele hosts op nginx. Velen suggereren dit patroon:

listen 80;
listen [::]:80 ipv6only=on;

Voor zover ik kan zien, bereikt dit precies hetzelfde als:

listen [::]:80 ipv6only=off;

Waarom zou je de eerste gebruiken? De enige reden die ik kan bedenken is of je extra params nodig hebt die specifiek zijn voor elk protocol, bijvoorbeeld als je alleen maar wilt instellen deferred op IPv4.


60
2017-10-20 16:26


oorsprong


Uitgevoerd als niets te maken met IP-stackversie is het een TCP-optie. - Xavier Lucas
Natuurlijk, maar je hebt het ingevoerd listen richtlijnen en de opties worden toegepast per host: poortpaar. - Synchro
Hum Ik kan me echt geen geval voorstellen waarin je dat zou willen doen. Ik denk dat de enige reden historisch is en Michael Hampton het heeft genageld. - Xavier Lucas


antwoorden:


Dat waarschijnlijk is om de enige reden waarom je de vorige constructie zou gebruiken, tegenwoordig.

De reden dat je dit ziet, is waarschijnlijk dat de standaard van ipv6only veranderd in nginx 1.3.4. Daarvoor was het standaard ingesteld op off; in nieuwere versies is het standaard ingesteld op on.

Dit gebeurt om te communiceren met de IPV6_V6ONLY socketoptie op Linux en vergelijkbare opties op andere besturingssystemen, waarvan de standaardwaarden niet noodzakelijk voorspelbaar zijn. Dus de vorige constructie was vereist vóór 1.3.4 om ervoor te zorgen dat je eigenlijk luisterde naar verbindingen op zowel IPv4 als IPv6.

De wijziging van de nginx standaard voor ipv6only zorgt ervoor dat de standaardinstelling van het besturingssysteem voor dual-stack-sockets niet relevant is. Nu bindt nginx zich expliciet aan IPv4, IPv6 of beide, nooit afhankelijk van het besturingssysteem om standaard een dual stack-socket te maken.

Inderdaad, mijn standaard nginx-configs voor pre-1.3.4 hebben de eerste configuratie en post-1.3.4 hebben allemaal de tweede configuratie.

Hoewel het binden van een dual stack-socket een Linux-ding is, lijken mijn huidige configuraties nu meer op het eerste voorbeeld, maar zonder ipv6only ingesteld, te weten:

listen [::]:80;
listen 80;

37
2017-10-20 16:32



Sommige besturingssystemen gebruiken geen dual ipv4- en ipv6-sockets, zoals OpenBSD, dus daarvoor moet je twee keer luisteren. - Justin Cormack
@JustinCormack Ja, je hebt gelijk, en daar heb ik al geruime tijd rekening mee gehouden. Ik heb dit bericht tot nu toe niet bijgewerkt. - Michael Hampton♦
listen localhost:8080; lijkt naar zowel (1.12.2) als naar gebruik te luisteren proxy_pass http://localhost:8080 zou de balans laden tussen :: 1 en 127.0.0.1 - Ik moest een regel toevoegen voor ipv6 om real ip in logs te krijgen set_real_ip_from 127.0.0.1; set_real_ip_from ::1; real_ip_header X-Forwarded-For; - Antony Gibbs


Als u meerdere vhost-domeinen host met een enkele Nginx-instantie, kunt u de enkele gecombineerde luisterrichtlijn niet gebruiken

listen [::]:80 ipv6only=off;

voor elk van hen. Nginx heeft een rare eigenaardigheid waar je alleen de. Kunt specificeren ipv6only parameter één keer voor elke poort, anders kan deze niet starten. Dat betekent dat u het niet voor elk vhost-domeinserverblok kunt specificeren.

Zoals Michael al zei, te beginnen met Nginx 1.3.4, de ipv6only parameter standaard in on.

Daarom, als u meerdere domeinen op zowel IPv4 als IPv6 met een enkele Nginx-server wilt hosten, bent u gedwongen om twee luisterinstructies te gebruiken voor elk domeinserverblok:

listen 80;
listen [::]:80; 

Bovendien, zoals Sander zei, gebruiken ipv6only=off heeft als nadeel dat IPv4-adressen worden vertaald naar IPv6. Dit kan problemen veroorzaken als uw app IP-controle uitvoert tegen zwarte lijsten zoals Akismet of StopForumSpam, want tenzij u een omgekeerde vertaallaag opzet, controleert uw app de IPv6-vertaling van het IPv4-adres van de spammer, die niet overeenkomt met een van de IPv4-adressen in de zwarte lijst.


54
2018-04-24 10:10



Ja, dat is hetzelfde als waar ik het over had deferreden andere richtlijnen per protocol. Het zou nuttig zijn als ze los van de luisterrichtlijn zouden kunnen worden vermeld om de reden die u zegt. - Synchro
En de kern van de zaak is dat u de luisterrichtlijn voor elk domein afzonderlijk moet specificeren. Anders wat zou er gebeuren? site zou prima werken via ipv4 en via ipv6 zou het de nginx welkomstpagina tonen. ROFL - Silver Moon
Bedankt voor de grondige uitleg! Ik kreeg een verwarrende fout toen ik dit opsomde ipv6only=off voor dezelfde poort twee keer. Je antwoord loste het probleem op! - Bruno Sutic
Ook als je 2 vhosts wilt gebruiken die allebei naar 443 luisteren: listen 443; listen [::]:443; . Gebruik makend van listen [::]:80 ipv6only=off; zal een nginx-fout genereren die de poort al in gebruik is - luke_aus
Heel handig, bedankt. - Basil A


Met de ipv6only=off configuratiestijl de IPv4-adressen kunnen worden weergegeven als IPv6-adressen met behulp van de (alleen-software) IPv6-IPv6-adressen in bijvoorbeeld logbestanden, omgevingsvariabelen (REMOTE_ADDR) enz.


12
2017-10-20 17:08



Ja, ze worden op deze manier getoond. - Michael Hampton♦


Voor zover ik weet (en volgens de documenten op http://nginx.org/en/docs/http/ngx_http_core_module.html#listen), met alleen

listen 80;

... is voldoende als u zowel IPv4- als IPv6-verkeer op dezelfde poort wilt verzenden.


1
2018-03-09 06:38



Dat is al vastgesteld en vermeld in de vraag. Zie de andere antwoorden voor het verschil. - Synchro
Het was niet voor mij, ik had beide nodig. wget en curl mislukten bij gebruik van ipv6 totdat ik de regel "listen [::]: 80 ipv6only = on;" - Basil A