I live in China so I have to use VPN all the time if I want any kind of stable connection to sites in the west. Unfortunately the VPN will at times randomly disconnect and then all traffic will immediately start going over chinese Internet again. While this is not a big deal really, I would just prefer not to be logged in to Facebook or Gmail and have my traffic open to be sniffed by the great firewall. It also occurred to me that many people use VPNs in the states in order to safely torrent.
I know some VPN providers have 'Internet kill switches' for their VPN that will cut your Internet connection incase of a disconnect and make sure you are not leaking anything. The problem with these is that they are almost all using openVPN, while I use L2TP over IPSec for my VPN. I searched for a long time for a way to do this and could not find one so I thought of a way to do it on my own. The following is how I set my system up. Please keep in mind that I am not an experienced Terminal user or power user so if anyone knows of a better way to do this please let me know.
Many advanced network configuration commands can be reached with the scutil command line tool. Launch Terminal.app and run:
ENABLE_EXPERIMENTAL_SCUTIL_COMMANDS=1 scutil --net, then type help and press the Return key to see the available options.
For example:
localhost:~ user$ ENABLE_EXPERIMENTAL_SCUTIL_COMMANDS=1 scutil --net
set "Automatic" selected
> help
Available commands:
help : list available commands
f.read file : process commands from file
quit [!] : quit
commit : commit any changes
apply : apply any changes
create interface [ | ]
create protocol
create service [ | [ ]]
create set [setName]
disable protocol [ ]
disable service [ | ]
enable protocol [ ]
enable service [ | ]
remove protocol [ ]
remove service [ | ]
remove set [ | ]
select interface | | $child | $service | $vlan | $bond | $bridge
select protocol
select service |
select set |
set interface context-sensitive-arguments (or ? for help)
set protocol context-sensitive-arguments (or ? for help)
set service [ name ] [ order new-order ] [ rank ( | First | Last | Never) [temp] ]
set set [ name setName ] | [ current ]
show interfaces
show interface [ | ]
show protocols
show protocol [ ]
show services [ all ]
show service [ | ]
show sets
show set [ | ]
update : update the network configuration
>
[crarko adds: I haven't tested this one. Obviously be careful before using the commands. I'd suggest making a log of any changes made, and understand how to undo them. This would be a good time to do a full system backup.]
This procedure shows you how to prevent Time Machine from using all available free space on a local volume by backing up to a sparse disk image bundle stored on a shared folder on a local volume.
Time machine uses a feature of the HFS+ filesystem that was introduced in Mac OS X 10.5 (Leopard) called 'directory hard links.' Like file hard links, a directory that is hard linked to another directory is not actually a distinct directory, but is instead a pointer to the original directory. Time Machine uses these directory hard links to reduce duplication and save space by making references to entire directory trees whose contained files have not been modified.
To properly copy or duplicate a Time Machine backup, these directory hard links must be preserved. Unfortunately, directory hard links are proprietary to Apple. Apple discourages their casual use by third party developers because, if used incorrectly, they could create recursive directory structures that would render a volume effectively useless. This introduces obstacles to anyone wishing to make copies of a Time Machine volume.
Time Machine may be configured to back up to a local volume that is connected directly to a Mac (either internally, or externally with a Firewire or USB connection), where it creates a Backups.backupdb folder at the root of the volume, storing all of the backup data in the volume's native file system using the previously mentioned directory hard links. Unfortunately, Time Machine will not back up to a local directory, but instead requires an entire volume be dedicated to backups. Further, Time Machine will utilize as much free space as possible on the volume. To prevent Time Machine from filling a disk, you could partition the disk to create multiple volumes, dedicating only one of the partitions to Time Machine backups. Yet you would still have no easy way to copy the backup data off the partition, due to the directory hard links.
Time Machine may also be configured to back up to volume that exists on a remote Mac and is mounted locally as a shared network volume. In this configuration, Time Machine creates a sparse disk image bundle which contains its own internal file system where backup data is stored. Since the backup data (with directory hard links) is stored within a self-contained disk image, one can easily make a copy of the entire disk image without worrying about effecting the directory hard links contained within the disk image. For this reason, backing up to a shared volume could be preferable for those who don't want to dedicate an entire volume to backups, or who want to be able to easily make file system level copies of the backup data for added security.
Sandisk gives you an app that allows you to connect to the Flash Drive's WiFi and transfer files. You can either connect via USB on the Mac or connect using a WiFi network. But what was not very clear was how to do this if you wanted to connect to the drive and upload or download files to and from your Mac wirelessly.
I tried to do this once I had connected to the drive's WiFi network and using a browser (as they suggest) to connect to the given URL. The address is served from the Flash Drive's WiFi network and in turn shows you the files on the drive. But I could not see my files and realised the page was being directed via my Ethernet connection across the Internet to a SandDisk page telling me the drive was not connected.
Turning off the Ethernet connection fixed this but it was not especially convenient. And the webpage that shows the files on the Disk is basic HTML which does not allow you to upload files.
The goal was to not have to disconnect the ethernet and have the SanDisk URL only connect over WiFi. And then to be able to upload or download files on the Mac over WiFi and not have to plug the drive into a USB port. The flash drive uses a simple server so using its IP address I then tried to connect to it via my FTP program (Transmit). The connection was refused. So instead of using FTP protocol I tried WebDav.
I had set already set a password using the Sandisk app but the connection just ignored this fact and just connected. The folders and files where listed and I could send and pull files no problem, and I did not need to disconnect from ethernet.
The other thing to note is you can use Bonjour and connect to the flash drive within Safari. But you will not be able to do much. The best way is to use an FTP program that can use Bonjour or WebDav. The drive it seems has a .local name along the lines of sandiskxxx.local. The xxx is probably part of its MAC address.
[crarko adds: This sounds like a cool, if somewhat pricey, device. It looks like it's also intended to be used with iOS, Android, and Kindle. It would be worth also trying an SMB connection, although WebDAV looks like it is the native protocol. SanDisk says it supports Snow Leopard and up.]
AirPort Utility 5.6 could show you all the devices connected to your AirPort base station—wired and wireless alike. AirPort Utility 6.x, however, only lists devices connected to your base station over Wi-Fi. There’s no way to use the app to list off the IP addresses and names of devices plugged directly into the base station.
But while you can force AirPort Utility 5.6 to install on Mountain Lion, there’s no guarantee that the app will continue to work on OS X 10.9 Mavericks or beyond. So if you want to find the IP addresses of other devices connected directly to your base station, you might prefer another option.
There are several.
In Terminal, you can use the arp -na command, which will list out devices it finds using the address resolution protocol. You won’t necessarily see friendly names for the devices it finds, but you’ll at least get a list of all the local IP addresses in use that it discovers.
You can also turn to multiple third-party apps. One such app, iNet, is available on the Mac App Store. There are iOS apps for the same purpose, like the free Fing and the $3 LAN Scan.
Those apps will, if possible, list off friendlier device names (in addition to IP addresses) than arp -na offers.
Here is how to set up a Mac, running OS X Client 10.5 or later, as a PXE boot server. We will configure OS X's built-in DHCP, TFTP, and NFS servers, start the servers, and put the client boot files in place. (The NFS server may be optional, depending on the operating system we are booting.)
You'll need the Mac, a PXE-capable PC, and an ethernet cable. Some steps will require being logged in as an administrator on the Mac.
We'll boot Debian Live on the client PC as an example. We'll show a regular setup with NFS, an alternate setup without NFS, and how to uninstall.
Regular setup (with NFS):
Connect the Mac and the client PC with the ethernet cable.
On the Mac, in System Preferences > Network, click "Ethernet" and enter the following settings:
Configure IPv4: Manually
IP Address: 192.168.1.1
Subnet Mask: 255.255.255.0
(All others can be left blank)
Note the status may read "Cable Unplugged" at this point, which is ok.
In Terminal, make new directories /srv and /srv/debian-live (we'll be sharing /srv/debian-live over NFS) with the following commands:
$ sudo mkdir /srv
$ sudo mkdir /srv/debian-live
To create the NFS configuration file, enter the following command:
and press Control-O to save and Control-X to exit nano.
Notes:
If the file /etc/bootpd.plist already exists, turn off Internet Sharing in System Preferences > Sharing. Then the file will be removed, and you can create it as in this step.
(Make sure to move /etc/bootpd.plist to the Trash and disable the DHCP server before turning Internet Sharing back on. See "Uninstall steps" below.)
If you are using an ethernet port other than en0 (see System Information or System Profiler for the port name), change the value for the dhcp_enabled key to the port you are using.
The data for the dhcp_option_67 key is the bootloader filename "pxelinux.0" (see step 9 below), null terminated and encoded into base64. This can be generated with the free DHCP Option Code Utility, or by entering the following command in Terminal:
See man launchd, man launchctl, man launchd.plist, and this article.
Download a Debian Live netboot archive, gnome-desktop or another flavor, from one of the following (choose i386 or amd64 depending on the client PC's architecture):
Place the .tar.gz file on the Desktop (or anywhere convenient), then double-click it to expand the archive.
Open the folder that is created (with a name like "debian-live-6.0.7-i386-gnome-desktop-net"), open the "tftpboot" subdirectory, select all of the files, and move them to /private/tftpboot. (This includes the pxelinux.0 file mentioned in step 6, and other boot menu and kernel files.)
Note that files in /private/tftpboot should be readable by everyone (so they will transfer), but not writeable by everyone (so they can't be modified). Check permissions with Get Info or ls -l if needed.
Click the Back button to leave the "tftpboot" subdirectory, then open the "debian-live" subdirectory, then select the folder called "live" and move it to /srv/debian-live. (When Debian Live is booting, it will look for the file /srv/debian-live/live/filesystem.squashfs over NFS, which contains the root filesystem.)
Optionally, test the TFTP server:
$ tftp localhost
tftp> get pxelinux.0
tftp> quit
$ ls -l pxelinux.0
You should see that a copy of the file pxelinux.0 has been downloaded to the current directory.
Turn on the client PC, and press or hold the key to bring up the boot options (something like F2 or F12; check the documentation for your machine or look for a message onscreen).
Choose to boot from the network (PXE). The PC receives an IP address from the DHCP server, loads pxelinux from the TFTP server, and displays the Debian Live boot menu.
Choose a boot option, and after the kernel is downloaded, the root filesystem is accessed over NFS, and the operating system is loaded, you'll end up at your graphical desktop or shell prompt of choice!
To uninstall, see "Uninstall steps" below.
Alternate setup (no NFS):
This is a shorter method, because NFS is not required. Debian Live will download its root filesystem over TFTP. (However, the largest file that can be downloaded is limited by a bug.)
Follow steps 1, 2, 6, and 7 of the regular setup, and skip steps 3, 4, and 5.
In step 8, choose a smaller archive, like the standard flavor from 6.0.7, or the lxde-desktop flavor from 5.0.10. (A bug causes some of the larger versions to stall when downloading the root filesystem over TFTP.) Place the .tar.gz file on the Desktop, then double-click it to expand the archive.
Follow step 9 of the regular setup.
In step 10, instead of moving the folder "live", open it and move the file "filesystem.squashfs" to /private/tftpboot.
Open the file /private/tftpboot/debian-live/i386/boot-screens/live.cfg in TextEdit. Edit the kernel parameters for the boot menu option you'll be using, replacing the two parameters
netboot=nfs nfsroot=192.168.1.1:/srv/debian-live
with a single parameter
fetch=tftp://192.168.1.1/filesystem.squashfs
then save the file and quit TextEdit.
Follow the regular setup steps 11, 12, 13, and 14. The root filesystem may take some time to download in step 14 (1 to 2 minutes over 100mbps ethernet), but when it finishes, you'll end up booted into Debian Live!
To uninstall, follow steps 1, 3, and 4 under "Uninstall steps", but ignore the /etc/exports file in step 1, and the /srv/debian-live directory in step 4. Skip steps 2 and 5.
Uninstall steps:
Move the files /etc/bootpd.plist and /etc/exports to the Trash.
Restart the NFS server:
$ sudo nfsd restart
and check the status of the server (should say enabled, not running):
Password managers are a good thing, as they encourage you to maintain strong passwords. Just the sort of thing you’d want if you were opening every port on every computer on your enterprise network. Unfortunately, Juniper doesn’t see it this way. This can be resolved with some crafty scripting.
First, we need a scripting addition called Useable Keychain Scripting. Download it and copy it to /Library/Scripting Additions. You'll need to type your password to do this.
Next, you need to be able to connect to your VPN, so do this, then disconnect. Network Connect should retain the address of your server (e.g. https://vpn.example.com).
Now create a password item for the server (https://vpn.example.com), and grant access to Usable Keychain Scripting. Or not, your call.
Now fire up the script. It will get the address of the server from Network Connect, get your username and password from Keychain Access, and log you in.
property appName : "Network Connect"
on main()
tell application "Network Connect"
if connected then
sign out
delay 5
quit
else
tell application "System Events"
-- Recover the name of the VPN from Network Connect.
set myAddress to value of combo box 1 of group 2 of tool bar 1 of
window appName of application process appName
set ASTID to AppleScript's text item delimiters
set AppleScript's text item delimiters to "://"
-- Get just the server address
set vpnName to (text items 2 through -1 of myAddress) as text
set AppleScript's text item delimiters to ASTID
end tell
tell application "Usable Keychain Scripting" to tell current keychain
-- Recover the username and password from the login keychain
set myPass to password of first internet password
whose name contains vpnName
set myAccount to account of first internet password
whose name contains vpnName
end tell
connect to vpnName
delay 5
tell application "System Events"
-- enter the account name and password in the dialog box and click 'Sign In"
set value of text field 1 of group 7 of UI element 1 of scroll area 1 of
window appName of application process appName to myAccount of
set value of text field 1 of group 10 of UI element 1 of scroll area 1
window appName of application process appName to myPass
click button "Sign In" of group 14 of UI element 1 of scroll area 1 of
window appName of application process appName
end tell
-- Could launch an application here if it's scriptable.
return
end if
end tell
end main
main()
A reader at Stack Exchange asked an interesting question about whether it was possible to set up an "airplane mode" for OS X. The idea was to ensure that there is no network activity through any possible network interfaces.
It's actually pretty simple to do this. If you go to the Network pane of System Preferences, you'll see a Location popup menu at the top of the window. Click on that menu and choose Edit Locations. Click on the + icon to add a new location, then enter a name, such as AirplaneMode. Click on Done.
Next, choose that location in the Location menu, and click on each available network interface in the list at the left of the window. Click on the Configure iPv4 menu, and choose Off. For Wi-Fi, just click on the Turn Wi-Fi Off button. Click Apply, and this location will block all network activity.
To activate the location, there are two ways. You can click on the Apple menu, then Location, and choose the location. Or, if you wish to do this from the command line, as the poster had requested, you can run this command:
networksetup -switchtolocation AirplaneMode
Replace AirplaneMode with the name you've chosen for the location.
Using airplane mode can be useful if you're worried about security when using a laptop in public places. It can also save battery power, as Wi-Fi will go off, and your Mac will no longer search for networks.
You can find out which wi-fi networks a Mac has connected to by going to the Network preference pane, then clicking on Advanced, then on the Wi-Fi tab; they'll be listed in Preferred Networks. But if you want to do this from Terminal - say for a Mac you've connected to via ssh - this hint, posted on OS X Daily, can do it as well:
defaults read /Library/Preferences/SystemConfiguration/com.apple.airport.preferences RememberedNetworks | egrep -o '(SSID_STR|_timeStamp).+' | sed 's/^.*= \(.*\);$/\1/' | sed 's/^"\(.*\)"$/\1/' | sed 's/\([0-9]\{4\}-..-..\).*/\1/'
The list will be the same as that in Preferred Networks, and you can't alter it, but it my be useful in some situations.
