The brick can do a lot more - it can look at the various devices that are tasked with providing internet access links, it can look at the config and see what that config is telling it to do.
I see the problem now splits into two: if we are allowed/supposed to assume that this config has been working, then diagnose the current situation, otherwise if the config is suspect we have to analyse the config and see if it is acceptable to provide internet access and also then we have the question of whether some config of any sort can provide internet access given the current state of affairs. So there needs to be a parameter I suppose, assume working config or new-unknown-suspect-config and in the case of the second option the diagnostics tool’s capabilities are limited because it doesn’t know how to achieve internet access without some guidance about what is available. The two are very different use-cases, so should probably split the whole thing in two, and make the second part into its own thing, a very worthwhile tool called ‘is this config any good’.
Actually I realise that it has to check that the firewalling is not insane. There already is a function that does exactly that for a given scenario so that code could just be reused several times, testing different significant destination points such as a node at the isp as close as you can get, if known (would need to either be supplied in a tool-config thing or obtained by traceroute) and then at some standard point out there on the internet example being 8.8.8.8 not that I would want to overload that so would want to have a wide range of such destinations from which one could be randomly selected.