Facebook being down killed AdGuard
Permalink | Author: Dan Dart | Published: 2021-10-08 16:37:31 UTC | Tags: adguard bgp dns facebook internet
Tbh Facebook being down the other day did have one knock-on effect for me who doesn’t use it.
Adguard DNS got quite a pummeling from folks trying to access Facebook and their entire DNS effectively got DDoSed, leaving nothing getting resolved for a good while.
Meanwhile I over here killed my own internet by disabling DNS on my router for days thinking it would revert to default. Was very confusing as I had adguard hardcoded on my PC as well, but not my phone.
My week went like this:
My phone: "No internet".
Me on my PC: "Huh? But it’s working! See?"
Comments
No comments yet...
Post a comment:
Retro dial-up network fun
Permalink | Author: Dan Dart | Published: 2018-07-27 00:46:00 UTC | Tags: 98 address dial-up dialup emulate emulation internet isp kernel linux modem nat network nostalgia protocol routing serial server windows
I remember those days when your computer hissed and made strange noises in order to connect to the Internet. Today, most of us look back at those days in disdain. But for some, we want to repeat the same kind of experiences that we used to, just for the pure nostalgia of it. Some of the most remembered operating systems can take us back to those days.
Windows for Workgroups 3.11 is remembered for its Terminal application and ability to use a multitude of networking technologies to connect to networks back in the day.
DOS also had limited support for networks - but this required third party software, unless one would talk directly to "COM1" as it would name the serial device.
Windows 98, although it has proper TCP/IP and Ethernet card support built in and there's therefore no need to use serial for internet when virtualising, for the most part it is remembered for its dial-up connections, since when we were using it, no one had broadband yet. But one of the best things about Windows 98 and serial is HyperTerminal! One can now connect to SynchroNet or other telnet services from Windows 98, just using HyperTerminal like dialling a phone, and possibly other things even with TLS, using socat. If you have a Windows 98 computer without ethernet, and a serial port between your host and Windows 98 computer, you can also connect to the Internet via this setup, by modifying the setup instructions to use a real serial port.
I'm not including instructions to emulate a "Lucent" win-modem because as far as I can see, qemu doesn't support these.
Although this isn't needed for dial up internet connection sharing, one can emulate a terminal with a SLIP interface too.
I'm going to explain how to pretend to be your own ISP, to old versions of Windows, and make HyperTerminal available for telnet fun, all via a virtual serial port.
To set this serial emulation up, I tried doing this through the VICE RS232 mode of tcpser, but it ultimately came up short. My VMs could use it just fine for telnetting places, but wouldn't go through pppd properly if I just socatted from its port to a pty, and made pppd listen on that pty. I think there was a protocol problem somewhere there, plus pppd kept hanging when I tried to make it listen on a TCP port - this is probably because it was trying to connect - but it is OK with a serial port. But this won't work with any old pty, it has to "look" like a serial port as well, and you can't just redirect physical serial ports using socat as if they were a file either.
The secret ingredient is to install a virtual serial port - its module is called tty0tty and it can be found here: https://github.com/freemed/tty0tty.
After installation (check the page for up to date instructions) you have access to 4 virtual serial port loops:
/dev/tnt0 <=> /dev/tnt1
/dev/tnt2 <=> /dev/tnt3
/dev/tnt4 <=> /dev/tnt5
/dev/tnt6 <=> /dev/tnt7
For use as a normal user, these should be chmod'd to 666:
sudo chmod 666 /dev/tnt\*
Anything sent to either end will be echoed on the other end, and this will act like a proper serial port, plugged in one end and the other end. For more information on this, see their GitHub repo.
Once this is set up, we can start the virtual machine. First, run qemu using the virtual serial line:
qemu-system-i386 win98.img -serial /dev/tnt0
Connect the other end to tcpser, which will emulate the phone line and allow you to dial a TCP connection.
tcpser -tsSiI -i 's0=1&k3' -s 57600 -S 57600 -l5 -d /dev/tnt1 -n 1=127.0.0.1:2323 -n 2=synchro.net -n 3=
localhost:23 -n 08450880101=localhost:2323 -n 08458457444=127.0.0.1:2323 -n "0845 845 7444"=127.0.0.1:2323 -n 0018002169575=127.
0.0.1:2323 -n 0018005433279=127.0.0.1:2323 -n 08450801000=127.0.0.1:2323
Explanation: Log everything. Set pickup to 1 ring. Set speed to 56k. Use the other end of the first serial line. Add a few example phone numbers (-n number=IP:port), (these I've used for ISP detection in Windows 98).
Listen to that TCP connection with socat and redirect it to a second virtual serial line loopback. I don't want it to die so I'll put it in a while true.
while true; do socat -s -d -d tcp-listen:2323 /dev/tnt2; done
In order to pretend to be our own ISP, we need to run pppd on the other end of that serial line. I couldn't use IP directly, this needs a serial line, and tcpser couldn't use a second interface, so we need to use socat. The IPs I'm using are within my current network. The rest of the settings are to disable authentication (for now, as I couldn't get it to work, which needs root), not fork the process so we can debug, not die if there's no call, show the debug logs, not communicate via serial (just IP), allow the connection to be seen by the LAN, adjust the forwarding parameters of the kernel appropriately and set a default DNS server of Quad9.
sudo pppd /dev/tnt3 57600 192.168.1.100:192.168.1.101 asyncmap 0 netmask 255.255.255.0 noauth silent nodetach passive persist debug local proxyarp ktune
ms-dns 9.9.9.9
If you'd like to define your own DNS mappings from your /etc/hosts, such as pretending to be the server for updates and ISP information (if you host a web server locally), add the appropriate lines to your /etc/hosts like this:
192.168.1.100 ispreferral.microsoft.com www.update.microsoft.com v4.windowsupdate.microsoft.com windowsupdate.microsoft.com ww
w.msn.com
and change ms-dns 9.9.9.9 to ms-dns 192.168.1.100 in the pppd command, then run dnsmasq:
sudo dnsmasq -zdippp0 -2ppp0
The -z specifies only binding to ppp0 (to not interfere with other services running on port 53/udp, such as systemd-resolved), -d to not daemonise, -i ppp0 to specify the interface and -2 ppp0 to specify only DNS, not DHCP.
In any case, do the usual NAT stuff:
Allow IP forwarding...
echo 1 | sudo tee /proc/sys/net/ipv4/ip\_forward
And allow forwarding and masquerading in the firewall (replace wlp7s0 with your main interface)
sudo iptables -t nat -A POSTROUTING -o wlp7s0 -j MASQUERADE
sudo iptables -A FORWARD -i wlp7s0 -o ppp0 -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A FORWARD -i ppp0 -o wlp7s0 -j ACCEPT
...
Hooray! Connecting to phone number 1 will give us a "dial up" connection through our virtual serial line! 2 will give us a line to synchro.net for use in the Terminal or HyperTerminal application, 3 will telnet to our local system if we need that for any reason and 08450880101 is the default Windows 98 "find my ISPs" service, which I've also redirected to our "ISP" connection for good measure.
Coming next time: Can we emulate update servers and ISP information servers? Given Windows 98 only supports 128-bit SSL / TLS 1.0, I think it's time to break SSL.
Comments
No comments yet...
Post a comment:
How to use SSH for an Internet Connection Sharing Proxy
Permalink | Author: Dan Dart | Published: 2010-11-13 13:10:00 UTC | Tags: connection internet internet connection sharing linux proxy sharing ssh tunnel
I haven't made a blog in a long while, so I'd thought I'd share this, which I recently discovered how to do.
If you find the idea of proxies a bit restrictive. because after all, they have to be set up in the applications in question, and may not work for some applications, help is here. And all you need is an SSH server you can connect to. Sadly, this method requires root, but it's worth having for the system-wide Internet connection you'll get from it.
Authenticating as root
First, make sure you're root on the client machine (sudo -s or su -, depending on your distro), and that you can ssh as root to your target server. This is of course causes security implications, so it may be a good idea to generate a key pair for root-to-root access and block off passworded access for root, so that no one can bruteforce your root password.
Generate the key pair as root on the client:
And copy the key to the server
client:~# ssh-copy-id [server]
Test the root login. It should not prompt you for password authentication (unless you've set one in ssh-keygen). Now, to block off password logins, edit /etc/ssh/sshd_config (or /etc/sshd/sshd_config) on the server and make sure this line is present:
PermitRootLogin without-password
Hooray! We're now somewhat more secure!
Creating the tunnel
Now to start a tunnel. The -w switch on ssh will do what we need, and create a tunnel network interface on both computers. The first number is the number of the interface on the client, and the second is for the server. For example, 0:! will create tun0 on the client connected to tun1 on the server. You may specify auto for the next available one. Let's create tunnels called tun0 to make it simpler.
client:~# ssh -w0:0 [server]
Now, see if your tunnels were set up correctly.
server:~# ifconfig -a tun0
You should see a tun0 interface. This is a layer 3 tunneled virtual interface (point-to-point).
Set up an IP on both sides so each computer can talk to each other.
server:~# ifconfig tun0 10.0.0.1 pointopoint 10.0.0.2
client:~# ifconfig tun0 10.0.0.2 pointopoint 10.0.0.1`
Try pinging each side to see if you have a connection.
Once each host can talk to the other, we can set up the routing.
Setting up the routing
Server setup
Ensure that the tun0 interface is not restricted:
server:~# iptables -A INPUT -i tun0 -j ACCEPT
server:~# iptables -A OUTPUT -o tun0 -j ACCEPT
server:~# iptables -A FORWARD -i tun0 -j ACCEPT
Allow packets in from the external interface to be processed by the tunnel:
server:~# iptables -A INPUT -i eth0 -d 10.0.0.2 -j ACCEPT
Allow forwarded packets to be routed to their destination:
server:~# iptables -A FORWARD -i eth0 -o tun0 -j ACCEPT`
Set up tun0 for NAT:
server:~# iptables -A POSTROUTING -o tun0 -t nat -j MASQUERADE
Enable IP forwarding in the kernel:
server:~# echo 1 > /proc/sys/net/ipv4/ip_forward`
Client setup
Allow packets to be processed from the tun0 interface:
client:~# iptables -A INPUT -i tun0 -j ACCEPT
client:~# iptables -A OUTPUT -o tun0 -j ACCEPT
client:~# iptables -A FORWARD -i tun0 -j ACCEPT`
Setting up the gateways
Find the existing default gateway:
client:~# route | grep ^default
Add a backbone to stop the server not being found once we switch gateways:
client:~# route add [server IP] gw [existing default gateway]`
Add the new default gateway:
client:~# route add default gw 10.0.0.1
Remove the existing default gateway (Be very careful!):
client:~# route del default gw [existing default gateway]`
Testing the tunnel
Try going to whatismyip.com in your browser. It should show you the IP of your server. If you're curious, you can also check the default route to somewhere like Google by using the traceroute utility.
You're done!
Troubleshooting
I can't see a tun0 interface!
Make sure you're root on both sides. (It sounds obvious - I've thumped my head on my desk so much because of this!)
Start ssh with the -v switch to show more verbosity. If you see a message a bit like this:
debug1: Remote: Failed to open the tunnel device.
channel 0: open failed: administratively prohibited: open failed
it could mean that someone else is trying to create a tunnel with the same interface name on the server.
If you see something a little like this:
debug1: sys_tun_open: failed to configure tunnel (mode 1): Device or resource busy
it might mean that you already have a tunnel with that interface name open. Check ifconfig -a.
I get the message "ping: sendmsg: Operation not permitted" when testing the tunnel connection!
You didn't allow traffic to flow between the tunnel and local network device. Try turning the client firewall off.
The connection is slow!
There will be significant overhead as all the traffic is encapsulated into SSH and encrypted. You will also see latencies go up as traffic needs to travel from your client to your server and back additionally.
Xenon Project looking for helpers!
Permalink | Author: Dan Dart | Published: 2009-10-14 14:17:00 UTC | Tags: css design hardware html internet javascript linux mysql php project software sql web windows xenon xhtml
I started a project some time ago, which is for now called "Codename: Project Xenon".
Xenon is a browser-based GUI designed to be implemented on netbooks. The difference between other netbook OSes and cloud systems is that not only can you test it online, it will also be installed on netbooks - which will update from the Web automatically, giving you updates, and ability to use it without being connected to the Internet due to a local web server instance.
It will have a very small footprint - being built on very few programs, and so will run on very low-end systems, so it will bring life to your old computers as well.
We are now looking for helpers to make this project a reality. If you are a designer or a programmer who can program using any combination of (X)HTML, CSS, JavaScript, PHP or MySQL, then we would like you to help us out. We are afraid pay is out of the question at the moment, until we start selling subscriptions to the web service, the budget is zero.
If you have any ideas to help the project along, then please give us feedback!
To apply, simply email: dan.dart@googlemail.com
To visit the main website of the project, click here: https://web.archive.org/web/20100107134808/http://xenon.kevinghadyani.com/ (edit 2021: archived) To try out the web based desktop for yourself, click here: Try The Desktop (edit 2021: archived partially). Please note that it is nowhere near finished at the moment. To view the SDK and programming procedures to help you, click here: Xenon SDK at xenon.kevinghadyani.com/wiki/index.php/Developing_Apps (edit 2021: not archived)
Thank you, and have a good day!
Comments
No comments yet...
Post a comment: