Path MTU discovery

Det siste jeg skal minne dere på i denne omgang når det gjelder feilsøking, er prosessen som omtales som 'path MTU discovery'. Internett-protkollene ble konstruert for å være utstyrsuavhengige, og en konsekvens av denne utstyrsuavhengigheten er at det ikke alltid er mulig å forutse hva som vil være optimal pakkestørrelse for en gitt forbindelse. Den viktigste begrensningen kalles Maximum Transmission Unit (største overføringsenhet) eller MTU, som angir den øvre grensen for pakkestørrelsen på et nettverksgrensesnitt. Kommandoen ifconfig vil blant annet vise deg gjeldende MTU for nettverksgrensesnittene dine.

Moderne TCP/IP-implementasjoner er konstruert slik at de forventer å være i stand til å finne frem til riktig pakkestørrelse for en forbindelse ved hjelp av en prosess som består i å sende pakker med varierende størrelser med 'ikke fragmenter'-flagget (Do not fragment) slått på, med forventing om at det vil komme en ICMP-returpakke med indikasjonen "type 3, kode 4" når øvre grense er nådd. Det er ikke nødvendig å kaste seg over RFCene med en gang. Type 3 betyr "destination unreachable" (mål kan ikke nås), mens kode 4 er kortformen av "fragmentering nødvendig, men ikke fragmenter-flagget er på". Så hvis forbindelsene dine til nettverk der MTUen kan være en annen enn den er i ditt nettverk kan virke suboptimale og du ikke har andre grunner til å være så spesifikk, kan du prøve å endre listen over tillatte ICMP-typer noe, slik at også 'Destination unreachable'-pakker kommer gjennom:

icmp_types = "{ echoreq, unreach }"

det betyr som vi ser at vi ikke trenger å røre selve pass-regelen:

pass inet proto icmp all icmp-type $icmp_typer keep state

PF gir deg mulighet til å filtrere på alle variasjoner av ICMP-typer og koder, og hvis du vil fordype deg i hva du bør og ikke bør slippe gjennom av ICMP-trafikk, finner du listen over alle mulige typer og koder i man-sidene icmp(4) and icmp6(4). Bakgrunnsinformasjonen er tilgjengelig i RFCene[1] .