Squid-klientoj IPv4 kaj IPv6-celoj: apartaj politikoj
IPv4-kliento povas uzi Squid por atingi IPv6-retejon. Distingu fontajn limigojn, fontajn ACL-ojn kaj adresan elekton antaŭ ol elekti nur-IPv6-politikon.
Eblas akcepti klienton per IPv4 kaj atingi ĝian petitan retejon per IPv6. Tiuj estas apartaj konektoj. Politiko pri la reteja flanko ne devus aŭtomate rifuzi IPv4-klientojn.
Tio estas la kaptilo en ekzemploj, kiuj kombinas rifuzon de cela familio kun src ipv4: la fonta ACL ŝanĝas, kiu rajtas konektiĝi, ne nur kiuj retejaj konektoj estas permesitaj.
Difinu la celatan limigon
Por Squid-eldonoj subtenantaj la koncernajn IP-ACL-ojn, cela familia regulo povas uzi dst ipv4 por identigi IPv4-celojn. Integru tiajn regulojn kun ekzistanta aŭtentikigo kaj celaj permesoj; ne aldonu larĝan IPv6-permeson, kiu ilin preterpasas.
La ACL-referenco distingas fontajn kaj celajn tipojn. Ĉi tio estas limigo, ne aŭtomata tradukservo. Nur-IPv4 retejo povas fariĝi neatingebla eĉ se la maŝino alie povus atingi ĝin per IPv4.
Ligado de elira IPv6-adreso ankaŭ ne estas la tuta plenumpolitiko. Fonta elekto, permesitaj celaj familioj, DNS-respondoj kaj fakta reta atingeblo ĉiuj kontribuas. Decidu eksplicite, ĉu IPv4-fallback estas akceptebla.
Ŝanĝi forwarded_for ne solvas ĉi tiun problemon. Tio efikas al HTTP-kapo, ne al la adresa familio de la TCP-konekto de la prokuro. Same, IPv6-DNS-resolvilo ne garantias, ke ĉiu nomo, al kiu ĝi respondas, havas IPv6-celon.
Kontrolu eldon-specifan konduton antaŭ ol adopti grandan malnovan agordon. Aparte: dns_v4_first ne estas subtenata familiprefera ŝaltilo en Squid 5 ĝis 7. Politikon, kiun vi povas precize priskribi, pli facile validigi ol kolekton de nerilataj IPv6-agordoj.