Change Instance

HTTP 200 OK
Allow: GET, HEAD, OPTIONS
Content-Type: application/json
Vary: Accept

{
    "unit": "https://translate-dev.freebsd.org/api/units/23551/?format=api",
    "component": "https://translate-dev.freebsd.org/api/components/freebsd-doc/articles_filtering-bridge/?format=api",
    "translation": "https://translate-dev.freebsd.org/api/translations/freebsd-doc/articles_filtering-bridge/es/?format=api",
    "user": "https://translate-dev.freebsd.org/api/users/carlavilla@FreeBSD.org/?format=api",
    "author": "https://translate-dev.freebsd.org/api/users/carlavilla@FreeBSD.org/?format=api",
    "timestamp": "2020-01-05T19:10:14.545231Z",
    "action": 2,
    "target": "Ahora es el momento de crear su propio archivo de configuración con las reglas personalizadas del firewall, para proteger la red interna. Habrá alguna complicación al hacerlo porque no todas las funcionalidades del firewall están disponibles en los paquetes bridge. Además, existe una diferencia entre los paquetes que están en proceso de reenvío y los paquetes que está recibiendo la máquina local. En general, los paquetes de entrada pasan por el firewall solo una vez, no dos veces, como suele ser el caso; en realidad se filtran solo después de la recepción, por lo que las reglas que usan <option>out</option> o <option>xmit</option> nunca coincidirán. Personalmente, utilizo <option>in via</option>, aunque es una sintaxis más antigua, tiene sentido cuando la lees. Otra limitación es que usted está restringido a usar solo los comandos <option>pass</option> o <option>reject</option> para los paquetes filtrados por un bridge. Opciones más complejas como <option>divert</option>, <option>forward</option> o <option>reject</option> no están disponibles. Estas opciones pueden seguir utilizándose, pero solo en el tráfico hacia o desde la propia máquina bridge (si tiene una dirección IP).",
    "id": 61757,
    "action_name": "Translation changed",
    "url": "https://translate-dev.freebsd.org/api/changes/61757/?format=api"
}