Dit is moontlik om ’n kliënt oor IPv4 te aanvaar en sy versoekte webwerf oor IPv6 te bereik. Dit is afsonderlike verbindings. ’n Beleid oor die webwerf-kant moet nie outomaties IPv4-kliënte verwerp nie.

Dit is die lokval in voorbeelde wat ’n bestemmingsfamilie-weiering met src ipv4 kombineer: die bron-ACL verander wie mag konekteer, nie net watter webwerfverbindings toegelaat word nie.

Bepaal die beoogde beperking

Vir Squid-weergawes wat die relevante IP-ACL's ondersteun, kan ’n bestemmingsfamilie-reël dst ipv4 gebruik om IPv4-bestemmings te identifiseer. Integreer sulke reëls met bestaande verifikasie en bestemmingsregte; moenie ’n breë IPv6-toelating byvoeg wat hulle omseil nie.

Die ACL-verwysing onderskei bron- en bestemmingstipes. Dit is ’n beperking, nie ’n outomatiese vertaaldiens nie. ’n Slegs-IPv4-webwerf kan onbeskikbaar word selfs al kon die masjien dit andersins oor IPv4 bereik.

Die bind van ’n uitgaande IPv6-adres is ook nie die hele handhawingsbeleid nie. Bronkeuse, toegelate bestemmingsfamilies, DNS-antwoorde en werklike netwerkbereikbaarheid dra almal by. Besluit uitdruklik of IPv4-terugval aanvaarbaar is.

Om forwarded_for te verander los nie hierdie probleem op nie. Dit beïnvloed ’n HTTP-kop, nie die adresfamilie van die proxy se TCP-verbinding nie. Net so waarborg ’n IPv6-DNS-resolver nie dat elke naam wat dit antwoord ’n IPv6-bestemming het nie.

Kontroleer weergawe-spesifieke gedrag voordat jy ’n groot ou konfigurasie aanvaar. Veral: dns_v4_first is nie ’n ondersteunde familie-voorkeur-skakelaar in Squid 5 tot 7 nie. ’n Beleid wat jy presies kan beskryf, is makliker om te valideer as ’n versameling onverwante IPv6-instellings.

Verwante artikels