Det är möjligt att ta emot en klient över IPv4 och nå den begärda webbplatsen över IPv6. Det är separata anslutningar. En policy för webbplatssidan bör inte automatiskt avvisa IPv4-klienter.

Det är fällan i exempel som kombinerar en avvisning av målfamilj med src ipv4: käll-ACL:n ändrar vem som får ansluta, inte bara vilka webbplatsanslutningar som tillåts.

Definiera den avsedda begränsningen

För Squid-versioner som stöder de relevanta IP-ACL:erna kan en målfamiljsregel använda dst ipv4 för att identifiera IPv4-mål. Integrera sådana regler med befintlig autentisering och målbehörigheter; lägg inte till ett brett IPv6-tillstånd som kringgår dem.

ACL-referensen skiljer mellan käll- och måltyper. Detta är en begränsning, inte en automatisk översättningstjänst. En webbplats med bara IPv4 kan bli otillgänglig även om maskinen annars skulle kunna nå den över IPv4.

Att binda en utgående IPv6-adress är inte heller hela tillämpningspolicyn. Källval, tillåtna målfamilyer, DNS-svar och faktisk nätverksnåbarhet bidrar alla. Bestäm uttryckligen om IPv4-fallback är acceptabelt.

Att ändra forwarded_for löser inte detta problem. Det påverkar en HTTP-header, inte adressfamiljen för proxyns TCP-anslutning. På samma sätt garanterar inte en IPv6-DNS-resolver att varje namn den svarar på har ett IPv6-mål.

Kontrollera versionsspecifikt beteende innan du antar en stor gammal konfiguration. I synnerhet: dns_v4_first är inte en stödd familjepreferensbrytare i Squid 5 till 7. En policy som du kan beskriva exakt är lättare att validera än en samling orelaterade IPv6-inställningar.

Relaterade artiklar