![]() #Cloudflare’s IPs, My v2ray is behide cloudflare Iptables -t mangle -A XRAY -p udp -j TPROXY -on-port 12346 -tproxy-mark 1 Iptables -t mangle -A XRAY -p tcp -j TPROXY -on-port 12346 -tproxy-mark 1 Iptables -t mangle -A XRAY -d 240.0.0.0/4 -j RETURN Iptables -t mangle -A XRAY -d 224.0.0.0/4 -j RETURN Iptables -t mangle -A XRAY -d 192.0.0.0/24 -j RETURN Iptables -t mangle -A XRAY -d 127.0.0.0/8 -p udp ! -dport 53 -j RETURN ![]() Iptables -t mangle -A XRAY -d 10.0.0.0/8 -j RETURN Iptables -t mangle -A XRAY -d 1.1.1.1/32 -j RETURN Iptables -t mangle -A XRAY -d 1.0.0.1/32 -j RETURN ![]() Iptables -t mangle -A XRAY -d 223.5.5.5/32 -j RETURN Ip route add local 0.0.0.0/0 dev lo table 100 My iptables configuration: ip rule add fwmark 1 table 100 I don't know if the information on the internet is outdated or if my device is special, I hope someone can help point out the problem. The "firewall" settings in OpenWrt have not been changed, and "_forward=1" has been set correctly. I checked a lot of information, according to the information on the Internet to configure: stop dnsmasq, use xray to handle all the DNS of port 53.Īt first it's OK (with "curl "), but after a minute or so, it can not access the Internet. Now I'm trying to set up a global proxy in OpenWrt to breach the Great Firewall (I can breach the Great Firewall normally with socks). As for why they bother with a free plan with such cryptic rules, their S1 explains it.My device is GL-iNet, version is "OpenWrt 21.02.1 r16325-88151b8303", I use XRAY (V2ray compatible), through cloudflare's CDN to pass the Great Firewall in China. If the subdomain is some website that is primarily used in the browser, CF will generally be fine leaving it up even if you push TBs a day, but if it's just a file host CF has been known to flag that for abuse and disable proxying for the domain. If you're referring to the TOS issue that is often discussed here, it depends on what that subdomain is, since Cloudflare doesn't just want to be pushing binary data for free. If you just want to try tunnels at all, with a non-descript hostname, Tunnel gives out subdomains that end in. Unless you want to pay for the business plan with a CNAME Setup, you do need to use their DNS offering, even if the rest of your site's DNS records are 'unproxied'. Do the boring bits so it can be even better than the primary offering. In other words, the hard part of this offering is done. And maybe even really open-source the tunnel client for real, because it would be quite nice to have the actual origin server connect via a plugin instead of a separate daemon. And the pane for managing website origin servers could let you choose between the traditional cloudflare-initiated connection and a tunnel, and the tunnel mode could give some controls for how the origin server is protected, whether connections load balance across multiple tunnels, etc. Hey jgc et all, if you’re reading this, maybe the cloudflare console UI could have a pane for managing tunnels. Unfortunately, cloudflare tunnels feel a bit like a cute 20% project that was never quite finished and is barely integrated with the rest of cloudflare’s offering. In principle, there is no reason at all to use TLS inside the tunnel - the tunnel itself is authenticated and encrypted. If only there was a straightforward way to manage the credentials used by cloudflared for tunnels, bind them to specific websites, and revoke them. I'm hopeful for the Pinephone, but we have a long way to go. I'm fine with sane defaults, but it should be easy to switch them off. We need a mobile OS that respects the user's control over their device. Overall I consider Android to be a very hostile environment for native applications, and networked apps in particular. One example I would see huge performance differences as soon as I turned the screen off. * Android has endless optimizations for battery life that are trying to shut down/throttle your program. * You have to do weird hacks in order to run native applications such as Golang programs. I solved this by setting DNS servers manually to 1.1.1.1, 8.8.8.8, etc. * DNS name resolution doesn't work by default (with Golang at least) because android doesn't use nf. Not a problem in theory but annoying to implement. * You have to run it as a foreground service so the user knows it's running. There are countless hoops to jump through for running server software, including: I spent considerable time last year porting boringproxy to run on Android.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |