Squid IPv4-klienter og IPv6-destinationer: adskilte politikker
En IPv4-klient kan bruge Squid til at nå et IPv6-websted. Skeln mellem destinationsbegrænsninger, kilde-ACL'er og adressevalg, før du vælger en IPv6-kun-politik.
Det er muligt at acceptere en klient over IPv4 og nå dens ønskede websted over IPv6. Det er adskilte forbindelser. En politik om webstedssiden bør ikke automatisk afvise IPv4-klienter.
Det er fælden i eksempler, der kombinerer en afvisning af destinationsfamilie med src ipv4: kilde-ACL'en ændrer, hvem der må forbinde, ikke kun hvilke webstedsforbindelser der er tilladt.
Definér den tilsigtede begrænsning
For Squid-versioner, der understøtter de relevante IP-ACL'er, kan en destinationsfamilie-regel bruge dst ipv4 til at identificere IPv4-destinationer. Integrér sådanne regler med eksisterende godkendelse og destinationstilladelser; føj ikke en bred IPv6-tilladelse til, som omgår dem.
ACL-referenceen skelner mellem kilde- og destinationstyper. Dette er en begrænsning, ikke en automatisk oversættelsestjeneste. Et websted med kun IPv4 kan blive utilgængeligt, selvom maskinen ellers kunne nå det over IPv4.
Binding af en udgående IPv6-adresse er heller ikke hele håndhævelsespolitikken. Kildevalg, tilladte destinationsfamilier, DNS-svar og faktisk netværksrækkevidde bidrager alle. Beslut eksplicit, om IPv4-fallback er acceptabelt.
Ændring af forwarded_for løser ikke dette problem. Det påvirker en HTTP-header, ikke adressefamilien for proxyens TCP-forbindelse. Ligeledes garanterer en IPv6-DNS-resolver ikke, at hvert navn, den svarer på, har en IPv6-destination.
Kontrollér versionsspecifik adfærd, før du tager en stor gammel konfiguration i brug. Især: dns_v4_first er ikke en understøttet familiepræferencekontakt i Squid 5 til 7. En politik, du kan beskrive præcist, er lettere at validere end en samling af urelaterede IPv6-indstillinger.