<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Networking on Lloyd Rochester's Geek Blog</title><link>https://lloydroc.github.io/categories/networking/</link><description>Recent content in Networking on Lloyd Rochester's Geek Blog</description><generator>Hugo</generator><language>en</language><copyright>Copyright © 2025, Lloyd Rochester.</copyright><lastBuildDate>Wed, 05 Jul 2023 00:00:00 +0000</lastBuildDate><atom:link href="https://lloydroc.github.io/categories/networking/index.xml" rel="self" type="application/rss+xml"/><item><title>Network Programming Rant</title><link>https://lloydroc.github.io/post/networking/network-programming-rant1/</link><pubDate>Wed, 28 Jun 2023 00:00:00 +0000</pubDate><guid>https://lloydroc.github.io/post/networking/network-programming-rant1/</guid><description>&lt;h1 id="hahahugoshortcode78s0hbhb">Network Programming Rant&lt;/h1>
&lt;p>When I mow the lawn I typically try to find a good podcast to listen to. Every once in a while I get lucky. This time I found a great pod cast on &lt;a href="#References">The Origins of the Internet Internet with John Day&lt;/a>. There are two episodes dedicated with (Professor John Day&amp;rsquo;s)[https://www.bu.edu/met/profile/john-day/] thoughts. Hearing what John Day had to say about the design and evolution of the Internet was intriguing to me. Many times when working with computers we just take for granted how things are and assume their design is the best approach. John has a deep understanding of the Internet&amp;rsquo;s origin and witnessed it&amp;rsquo;s infancy from ARPA Net to what it is and isn&amp;rsquo;t today.&lt;/p></description></item><item><title>Browser UI using sshuttle VPN in WSL</title><link>https://lloydroc.github.io/post/wsl/ui-vpn/</link><pubDate>Tue, 30 May 2023 00:00:00 +0000</pubDate><guid>https://lloydroc.github.io/post/wsl/ui-vpn/</guid><description>&lt;h1 id="hahahugoshortcode106s0hbhb">Browser UI using sshuttle VPN in WSL&lt;/h1>
&lt;figure>&lt;img src="https://lloydroc.github.io/assets/png/browser-remote-server-vpn-sshuttle-windows.png">&lt;figcaption>
 &lt;h4>Browser viewing a UI in Windows using sshuttle in WSL as a VPN&lt;/h4>
 &lt;/figcaption>
&lt;/figure>

&lt;p>In this post we will create VPN connections using &lt;code>sshuttle&lt;/code> in WSL for Windows 11. This post will focus on pointing a Browser to a URL in a private network in Windows. The private network - VPN - can be reached from &lt;code>sshuttle&lt;/code> running in WSL. For this setup we unfortunately need to have a &amp;ldquo;double networking hop&amp;rdquo; in that Windows needs to be configured to send traffic to WSL (1) and WSL needs will then use &lt;code>sshuttle&lt;/code> to (2) forward that traffic to the public network.&lt;/p></description></item><item><title>Unix UDP Example in C</title><link>https://lloydroc.github.io/post/c/unix-udp-example/</link><pubDate>Thu, 27 Feb 2020 17:14:45 +0000</pubDate><guid>https://lloydroc.github.io/post/c/unix-udp-example/</guid><description>&lt;h1 id="hahahugoshortcode39s0hbhb">Unix UDP Example in C&lt;/h1>
&lt;p>In this post we&amp;rsquo;ll create an example client and server that communicate over UDP in C using Unix as the Operating System. UDP is a connection-less, unreliable datagram packet service. The term connection-less means there is no handshake between the client and server before information is exchanged. The term &amp;ldquo;fire and forget&amp;rdquo; applies here since the client sends and beforehand has no negotiation with the server. The term unreliable means there is no guarantee of delivery, ordering or duplicate protection. UDP is best for time-sensitive applications where it is preferable to discard packets rather than waiting for delayed ones.&lt;/p></description></item><item><title>Unix Virtual Network Device Types</title><link>https://lloydroc.github.io/post/unix/virtual_networking_device_types/</link><pubDate>Fri, 07 Feb 2020 00:00:00 +0000</pubDate><guid>https://lloydroc.github.io/post/unix/virtual_networking_device_types/</guid><description>&lt;h1 id="hahahugoshortcode102s0hbhb">Unix Virtual Network Device Types&lt;/h1>
&lt;p>This blog post attempts to list and describe the majority of Virtual Network Device types in Unix. Networking with Linux is a hot topic especially in the IoT and Datacenter areas. Read on and you&amp;rsquo;ll see a large array of Device Types found in Unix.&lt;/p>
&lt;h2 id="background-on-network-configuration-in-unix">Background on Network Configuration in Unix&lt;/h2>
&lt;p>The &lt;code>iproute2&lt;/code> framework replaces &lt;code>ifconfig&lt;/code> as well as many other commands. The command family &lt;code>ip link&lt;/code> deals with network device configuration in Unix. We can use &lt;code>iproute2&lt;/code> to add, change, and delete network configurations. When adding a network using &lt;code>iproute2&lt;/code> we can do a &lt;code>ip link add name NAME type TYPE&lt;/code> where &lt;code>TYPE&lt;/code> is one of the many Linux Networking Device Types.&lt;/p></description></item><item><title>Creating IP Tunnels in Linux with iproute2</title><link>https://lloydroc.github.io/post/unix/iproute2_create_tunnel/</link><pubDate>Tue, 04 Feb 2020 07:40:31 +0000</pubDate><guid>https://lloydroc.github.io/post/unix/iproute2_create_tunnel/</guid><description>&lt;h1 id="hahahugoshortcode90s0hbhb">Creating IP Tunnels in Linux with iproute2&lt;/h1>
&lt;p>In this post we&amp;rsquo;ll use &lt;em>iproute2&lt;/em> to create tunnels between two unix hosts. This will be the simplest form of an &lt;em>IP-in-IP&lt;/em> tunnel.&lt;/p>
&lt;h2 id="how-the-tunnels-will-work">How the Tunnels will work&lt;/h2>
&lt;p>In this example we have two Unix hosts with IP addresses &lt;em>10.255.254.96&lt;/em> and &lt;em>10.255.254.196&lt;/em> on a &lt;em>10.255.254.0/24&lt;/em> network and a gateway address of &lt;em>10.255.254.2&lt;/em>. These two hosts are on the same network. For this tunnel example we are going to add &lt;em>dummy&lt;/em> interfaces to each of our hosts and assign addresses &lt;em>192.168.2.111&lt;/em> and &lt;em>192.168.2.222&lt;/em> addresses to each of them respectively. Once the tunnels are up we will be able to send a ping from the first tunnel to the second tunnel as if the hosts are on the same network. This is known as encapsulation, since inside an IPv4 packet with a source of &lt;em>10.255.254.96&lt;/em> and destination of &lt;em>10.255.254.196&lt;/em> we have another IPv4 packet encapsulated inside with a source of &lt;em>192.168.2.111&lt;/em> and destination of &lt;em>192.168.2.222&lt;/em>.&lt;/p></description></item><item><title>Learning how the Internet Works</title><link>https://lloydroc.github.io/post/networking/learn-how-internet-works/</link><pubDate>Fri, 26 Jul 2019 07:28:41 +0000</pubDate><guid>https://lloydroc.github.io/post/networking/learn-how-internet-works/</guid><description>&lt;h1 id="hahahugoshortcode85s0hbhb">Learning how the Internet Works&lt;/h1>
&lt;p>The Internet is the most complex public service ever created! The Internet is truly amazing. Curriculums from four year College Institutions focused on Computer Science and/or Programming Background don&amp;rsquo;t spend much time teaching &lt;em>The Internet&lt;/em>.&lt;/p>
&lt;p>Recently, I found myself tired of the Interenet being a black box and pursued a deeper understanding. I wanted to post about how I obtained a deeper understanding of the internet and jot down some of my notes and references.&lt;/p></description></item><item><title>Enable CORS when not Supported</title><link>https://lloydroc.github.io/post/networking/nginx-cors-proxy/</link><pubDate>Fri, 05 Jul 2019 07:40:01 +0000</pubDate><guid>https://lloydroc.github.io/post/networking/nginx-cors-proxy/</guid><description>&lt;p>Some services don&amp;rsquo;t support &lt;a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS">CORS&lt;/a>, but we can use NGINX to make CORS supported with this simple hack! To enable CORS on any service we need to have NGINX configured as a &lt;a href="https://lloydroc.github.io/post/networking/couchdb-nginx-proxy/">Reverse Proxy&lt;/a> and have NGINX add a successful pre-flight response to the CORS pre-flight request. Read on to get this simple example to work.&lt;/p>
&lt;p>Let&amp;rsquo;s back all the way up on why CORS is needed? Security! What if we could write Javacript on a server somewhere and that Javascript could use any back-end server it wanted for requests? That would introduce huge security vulnerabilities. For example, I could write a webpage that looks like a store, but not have a back-end for the store at all and send bogus orders to another store somewhere else on the internet that my site isn&amp;rsquo;t affiliated with. CORS gives us security that a front-end and back-end match up. From the back-end we can control what front-end has access to the back-end and also what requests that front-end can make.&lt;/p></description></item><item><title>Passing Datagrams Between Python and C</title><link>https://lloydroc.github.io/post/c/unix-domain-socket-datagram/</link><pubDate>Tue, 18 Jun 2019 06:45:00 +0000</pubDate><guid>https://lloydroc.github.io/post/c/unix-domain-socket-datagram/</guid><description>&lt;p>Let&amp;rsquo;s discuss how to pass data from a C program to a Python Script and vice-versa. This subject involves IPC - Inter-Process Communications. In this blog post we&amp;rsquo;ll discuss the more exotic IPC mechanism of the &lt;strong>Unix domain datagram socket&lt;/strong>. Specifically, this is domain &lt;code>AF_UNIX&lt;/code> and type &lt;code>SOCK_DGRAM&lt;/code> type of socket. Before you consider this method let&amp;rsquo;s address some of it&amp;rsquo;s benefits and limitations of using Unix Domain Sockets for Interprocess Communications:&lt;/p></description></item><item><title>NGINX/CouchDB Reverse Proxy</title><link>https://lloydroc.github.io/post/networking/couchdb-nginx-proxy/</link><pubDate>Wed, 10 Oct 2018 03:10:00 +0000</pubDate><guid>https://lloydroc.github.io/post/networking/couchdb-nginx-proxy/</guid><description>&lt;p>Using NGINX as a front-end server to forward to multiple back-end services works great by configuring NGINX as a reverse proxy. The reverse proxy configuration will have NGINX serve HTTP/HTTPS URLs and forward them to them to network addresses such as a database listening on HTTP at a specific port, API servers, static websites, etc. Basically we can turn NGINX into an HTTP router. NGINX is also a great front man for back-end services such as HTTPS and HTTP/2. For instance if you had a Database, API Server and static site you could have an SSL certificate just for NGINX and they would all be behind HTTPS and the reverse proxy would convert the HTTPS and send HTTP. That&amp;rsquo;s a post for another time however.&lt;/p></description></item></channel></rss>