Squid IPv4-klienter og IPv6-destinasjoner: atskilte retningslinjer

Det er mulig å ta imot en klient over IPv4 og nå nettstedet den ber om over IPv6. Dette er atskilte tilkoblinger. En retningslinje for nettstedssiden bør ikke automatisk avvise IPv4-klienter.

Det er fellen i eksempler som kombinerer en avvisning av destinasjonsfamilie med src ipv4: kilde-ACL-en endrer hvem som kan koble til, ikke bare hvilke nettstedstilkoblinger som er tillatt.

Definer den tiltenkte begrensningen

For Squid-versjoner som støtter de relevante IP-ACL-ene, kan en destinasjonsfamilie-regel bruke dst ipv4 til å identifisere IPv4-destinasjoner. Integrer slike regler med eksisterende autentisering og destinasjonstillatelser; ikke legg til en bred IPv6-tillatelse som omgår dem.

ACL-referansen skiller mellom kilde- og destinasjonstyper. Dette er en begrensning, ikke en automatisk oversettelsestjeneste. Et nettsted med bare IPv4 kan bli utilgjengelig selv om maskinen ellers kunne nå det over IPv4.

Å binde en utgående IPv6-adresse er heller ikke hele håndhevingsretningslinjen. Kildevalg, tillatte destinasjonsfamilier, DNS-svar og faktisk nettverkstilgjengelighet bidrar alle. Bestem eksplisitt om IPv4-fallback er akseptabelt.

Å endre forwarded_for løser ikke dette problemet. Det påvirker en HTTP-header, ikke adressefamilien til proxyens TCP-tilkobling. På samme måte garanterer ikke en IPv6-DNS-resolver at hvert navn den svarer på, har en IPv6-destinasjon.

Kontroller versjonsspesifikk atferd før du tar i bruk en stor gammel konfigurasjon. Spesielt: dns_v4_first er ikke en støttet familievalg-bryter i Squid 5 til 7. En retningslinje du kan beskrive presist, er lettere å validere enn en samling urelaterte IPv6-innstillinger.