tcpdump - available via gslapt uses a syntax like
tcpdump -i wlan0 -s 65536 -w somefile
to monitor interface wlan0 in my case, writing the details to 'somefile'
If you proxy or use ssh to access internet/web pages then traffic flow/timings (big data) can still potentially identify what traffic flowed to where. A DNS name -> IP request pretty much indicates where from and to what destination a request is about to be made, snapshot that web page and you often have a copy of the clear-text, capture the data flow packets and given two out of clear-text, key, encrypted data you can easily deduce the third. Monitor packet flows/timing and you can often associate where the initial request was made from and data/content delivered to.
So even without knowing actual content a lot of information can be gleamed. One way to obscure that is to have tcpdump running and capturing data, that is then forwarded on, and simply dumped to /dev/null at the target/server. More often the final destination is the one with the largest amount of packet flows to it, and with the latest timestamps, so by forwarding the suggested final point is not your IP, but some other IP elsewhere.
That does mean a double-up of bandwidth, as each packet received is in effect having another packet being sent out again, but does obscure things from big-data/traffic analysis (a.k.a the likes of google analytics). You don't have to forward the actual/same packets, any data will do, even /dev/urandom, just the same or ideally slightly more, and at times close to but a little later than when the packets were received.
Example, I ssh into hashbang (HB) from my laptop (LT) and run elinks to view web pages. Traffic analysis indicates requests originating from HB, content returned to HB, but similar numbers of packets also flowing through ssh to LT at around the same time. Pretty conclusive from where and to what web site LT was accessing. If however there was also a similar amount again of packets flowing from LT to HB then ??? Analysis suggests in that case that LT might be being used as a proxy/jump-leg, and where the timings indicate that the last timepoint was for delivery to HB ... suggestive that the actual origination and recipient was HB based.
My untested thinking is along the lines of
tcpdump -i wlan0 dst port 22 and inbound -w somefile
as we don't want to capture all packets when we're also sending out packets ... perpetual loop.
And where 'somefile' is a file/folder located on hashbang via sshfs
mkdir /mnt/hb
sshfs user@hashbang:/home/userid/somefolder /mnt/hb
tcpdump -i wlan0 dst port 22 and inbound -w /mnt/hb/somefile
and where on HB ln -s /dev/null /home/userid/somefolder/somefile