There are two ways to approach this, depending on just how inaccessible you want to make the data.
If you simply want to require knowledge of the LUKS passphrase to regain access to the data (more or less the normal case, but expediated), then you can use
cryptsetup luksSuspend on the dm-crypt device name. According to the man page, this:
Suspends an active device (all IO operations will blocked and accesses to the device will wait indefinitely) and wipes the encryption key from kernel memory.
To recover from a luksSuspend, do a luksResume.
NOTE: The below assumes the LUKS 1 format. The newer LUKS 2 format is different.
If you want to ensure that Trudy cannot gain access to the data, then you need something more drastic. In the easy case, we assume that Trudy does not have a LUKS header backup, in which case overwriting the LUKS header is sufficient. You can either overwrite exactly the header and nothing else (the size of the header is "payload offset" (as reported by cryptsetup luksDump) times 512 bytes, and it starts right at the beginning of the device), or you can play it safe and overwrite some more. Overwriting the first 100 MB of a rotational HDD will take somewhere around 1-3 seconds, depending mainly on the rotational speed of the drive (7200 rpm drives tend to be able to attain 100-120 MB/s, with slower drives obviously being slower):
WARNING: DO NOT DO THIS UNLESS YOU KNOW YOU WANT TO
dd if=/dev/urandom of=/dev/sdb1 bs=1M count=100 conv=sync
WARNING: DANGEROUS COMMAND ABOVE
After overwriting the header, make sure to wipe the key from kernel memory to ensure that the remaining data cannot be decrypted. This is as simple as
cryptsetup luksSuspend dm-name or
cryptsetup remove dm-name. After doing that, the container contains only random-looking data which (short of breaking the encryption algorithm used) cannot be decrypted. The output of any good encryption algorithm, absent the decryption key, will be statistically indistinguishable from random noise.
In the latter case, if you really want to make Trudy's life difficult, you can then issue a ATA Secure Erase to the underlying storage device. Assuming Secure Erase is implemented properly on the drive, once it finishes (which can take several hours on non-self-encrypting rotational HDDs, but normally cannot be interrupted once started), no previously stored data will be accessible. For most threat models, though, that is likely to be overkill; overwriting the LUKS header and clearing the key in RAM will almost certainly be sufficient to prevent access to the data by any reasonable adversary. The Secure Erase may however be needed to ensure that there are no remnants of key material on a SSD, due to wear leveling.