Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Överväg följande ämnen när du programmerar en callout-drivrutin för Windows Filtering Platform.
Användarläge jämfört med kernelläge
Om den önskade filtreringen kan göras med hjälp av standardfiltreringsfunktionen som är inbyggd i Windows-filtreringsplattformen bör oberoende programvaruleverantörer utveckla hanteringsapplikationer i användarläge för att konfigurera filtreringsmotorn i stället för att skriva calloutdrivrutiner i kernelläge. En callout-drivrutin i kernelläge ska bara skrivas när du måste bearbeta nätverksdata på ett sätt som inte kan hanteras av den inbyggda filtreringsfunktionaliteten. Information om hur du skriver ett hanteringsprogram för Windows-filtreringsplattform i användarläge finns i dokumentationen om Windows-filtreringsplattformen i Microsoft Windows SDK.
Val av filtreringslager
En callout-drivrutin bör filtrera nätverksdata på högsta möjliga filtreringsnivå i nätverksstacken. Om den önskade filtreringsuppgiften till exempel kan hanteras på dataströmlagret bör den inte implementeras på nätverksskiktet. För mer information om rekommendationer för de filtreringslager som rekommenderas för att din drivrutin ska använda för att garantera kompatibilitet med IPsec i Windows, se Utveckla IPsec-Compatible callout-drivrutiner.
Blockering på lager för tillämpningsskiktsverifiering vid etablering av ALE-flöden
Om ett utrop har lagts till i filtermotorn vid någon av de ALE-flödesfiltreringsskikten (FWPM_LAYER_ALE_FLOW_ESTABLISHED_V4 eller FWPM_LAYER_ALE_FLOW_ESTABLISHED_V6) bör dess classifyFn-funktion aldrig returnera FWP_ACTION_BLOCK för åtgärden. Ett beslut om att auktorisera eller avvisa en anslutning bör inte fattas i något av de ALE-flödesetablerade filtreringsskikten. Ett sådant beslut bör alltid fattas i något av de andra ALE-filtreringsskikten.
Det enda giltiga skälet till att en sådan classifyFn callout-funktion returnerar FWP_ACTION_BLOCK för åtgärden är om ett fel inträffar som kan utgöra en potentiell säkerhetsrisk om inte den etablerade anslutningen avslutas. I det här fallet stänger att returnera FWP_ACTION_BLOCK som åtgärd anslutningen för att förhindra att den potentiella säkerhetsrisken utnyttjas.
Körningstid för utropsfunktion
Eftersom filtermotorn vanligtvis anropar en callouts funktioner på IRQL = DISPATCH_LEVEL, bör du se till att dessa funktioner exekveras så snabbt som möjligt för att hålla systemet igång effektivt. Förlängd körning på IRQL = DISPATCH_LEVEL kan påverka prestandan negativt för hela systemet.
Injicera i mottagardatapathen
Callouts bör beräkna om IP-kontrollsummor innan de anropar paketinmatningsfunktioner som injiceras i mottagningsdatavägen eftersom kontrollsumman i det ursprungliga paketet kanske inte är korrekt när paketet återmonteras från IP-paketfragment. Det finns ingen tillförlitlig mekanism som anger om en nätbuffertlista återmonteras från fragment.
Infogning av TCP-paket från transportlager
På grund av TCP-stackens låsbeteende kan en anrop vid transportlagret inte infoga ett nytt eller klonat TCP-paket från classifyFn-utropsfunktionen. Om inline-injektion önskas måste en callout köa en DPC för att utföra injektionen.
Justering av utgående IP-huvud
Den MDL som beskriver IP-huvudet i en nettobuffertlista (NET_BUFFER_CURRENT_MDL(NET_BUFFER_LIST_FIRST_NB(netBufferList))) måste vara pekarjusterad när en av paketinmatningsfunktionerna används för att mata in paketdata i en utgående sökväg. Eftersom ett inkommande pakets IP-huvud MDL kan vara pekare-justerad måste ett återanrop återskapa IP-huvudet (om det inte redan är justerat) när ett inkommande paket matas in i en utgående väg.