Tunnel break mac os

Tunnelblick for Mac

Tunnelblick 3.8.7 Beta 02 Build 5730 LATEST

Mac OS X 10.7 or later

Tunnelblick for Mac 2021 full offline installer setup for Mac

Tunnelblick for Mac is a program that can be used to securely connect a Mac running OS X or macOS to an OpenVPN server. The server then connects the Mac to a remote network or to the Internet, bypassing untrusted networks, censorship, and eavesdropping.

It does this by creating a «Virtual Private Network«, or «VPN» to the OpenVPN server using a program named «OpenVPN», which is included within the Tunnelblick application. When you connect through a VPN, your computer sends some or all network traffic through a «tunnel» to the VPN server, which then passes on your network traffic to a local network or the Internet. It is as if you were connecting to the network or Internet through the VPN server instead of your computer. Normally, all traffic between your computer and the VPN server is encrypted.

VPNs are primarily used for three purposes (sometimes all three simultaneously):

  • To securely connect a computer to the Internet, even though it may be connecting through an untrusted network (a wireless network at a hotel or airport, for example);
  • To securely connect a computer to the Internet as if it were located somewhere else (connect a computer in the USA as if it were located in the UK so that BBC content may be accessed, for example); and
  • To securely connect a computer to a company’s internal network or some part of it (a branch office, for example).

In addition to Tunnelblick for macOS, you need access to a VPN server. Your company may provide one, or you can obtain VPN service from any of several VPN service providers, or you can use another one of your computers or a router to act as a VPN server.

Note: Requires 64-bit processor.

Источник

Настройка OpenVPN соединения в Tunnelblick на macOS

Скачайте Stable версию Tunnelblick на ваш компьютер с официального сайта. Убедитесь, что скачиваете версию программы, которая подходит для вашей версии macOS.

Запустите установку. Затем дважды кликните на иконку Tunnelblick.app.

Разрешите открыть программу.

Введите Логин и Пароль от вашей учетной записи на macOS.

Tunnelblick установлен. Нажмите на кнопку У меня есть файлы конфигурации.

В разделе Подписки скачайте конфиги Tunnelblick и распакуйте Zip архив в любую папку.

В верхней строке macOS найдите иконку Tunnelblick и нажмите Детали VPN.

Для загрузки конфигурационных файлов необходимо перетащить эти файлы с окна Finder в раздел Конфигурации программы Tunnelblick.

Нажмите Применить ко всем, чтобы все файлы успешно загрузились. И выберите установку файлов только для вашей учетной записи или для всех Пользователей macOS.

Введите Логин и Пароль от учетной записи macOS.

Для подключения к OpenVPN нажмите на иконку Tunnelblick в верхнем меню и выберите желаемое подключение.

В следующем окне укажите:

  1. Логин VPN
  2. Отметьте, если нужно запомнить Логин
  3. Пароль VPN
  4. Отметьте, если нужно запомнить Пароль

Источник

Install Tunnelblick on macOS

1. Download Tunnelblick

To connect to OVPN you first need to download Tunnelblick.

2. Install Tunnelblick

Double-click on the file you downloaded in the previous step and go through the installation process.

3. Download the configuration you want

Double-click the downloaded file to import it into Tunnelblick.

If you see:

Choose Only Me. You might need to enter your password in order to allow Tunnelblick to install the configuration file.

4. Connect to OVPN

The tunnelblick icon, which looks like a tunnel, should be visible on the upper right corner of your screen.

Click the icon connect to the configuration file you downloaded.

5. Enter your credentials

Enter the username and password you used when creating your OVPN account.

Select Save to keychain if you want Tunnelblick to remember your login credentials.

6. Finished

You should now be connected to OVPN and be able to browse the internet safely. To make sure everything was set up correctly, please check the dashboard to verify that you are connected.

Источник

Установка OpenVPN на Mac OS X, Tunnelblick

Создание VPN подключения

  • Шаг 1. Скачайте Tunnelblick с http://code.google.com/p/tunnelblick/ и откройте контейнер. Дважды щелкните по иконке приложения.
  • Шаг 2. Щелкните Открыть.
  • Шаг 3. Введите ваш Mac OS Пароль и щелкните OK.
  • Шаг 4. Щелкните Launch после успешной инсталяции.
  • Шаг 5. Щелкните I have configuration files.
  • Шаг 6. Щелкните OpenVPN Configuration(s).
  • Шаг 7. Щелкните Open Private Configurations Folder.
  • Шаг 8. Переместите конфигурационные файлы (см. ссылка mac OpenVPN конфиг в панели пользователя) в открытую папку и щелкните Done.
  • Шаг 9. Щелкните по иконке Tunnelblick в строке меню и выберите наименование вашего подключения с приставкой Connect.NB! Мы прежде всего рекомендуем использовать UDP соединение, если оно стабильно, в обратном случае используйте TCP.
  • Шаг 10. Введите ваш Mac OS пароль.
  • Шаг 11. Для разъединения щелкните по иконке Tunnelblick icon в строке меню и выберите наименование вашего подключения с приставкой Disconnect.NB! Никогда не сохраняйте конфигурационные файлы на компьютерах общего пользования! Если кто-либо подключится по сохраненным данным, ваше соединение будет разорвано!

Удаление VPN подключения

  • Шаг 1. Найдите папку конфигураций Tunnelblick (путь по умолчанию: Library/Application Support/Tunnelblick), выделите конфигурации vpnlux, щелкните правой кнопкой мыши и выберите Переместить в Корзину, после чего Очистите Корзину.
Читайте также:  Windows 10 браузер сам запускается с рекламой
  • Что такое ВПН? VPN — технология используется для создания на вашем компьютере во время соединения с интернетом специального защищенного зашифрованного туннеля, по которому передаются данные во время работы.

Услуги Мы предоставляем различные пакеты услуг VPN от одиночного соединения до двойных связок. В каждом пакете Вы сможете пользоваться всеми доступными технологиями VPN, такими как L2TP VPN, PPTP VPN и OpenVPN.

Преимущества VPN Решение купить сервис VPN позволит вам в дальнейшем пользоваться сайтами в Интернете, не оставляя следов своего пребывания, пользоваться торрентами, посещать сайты, запрещенные для просмотра в вашей стране проживания, обходить ограничения корпоративных сетевых экранов.

КонтактыE-mail: supportvpnlux.com
Jabber: vpnlux_supportradio.pm

Источник

Multiple unused utun interfaces after macOS upgrade #340

Comments

essandess commented Nov 3, 2016

My Mac has several unused utun0, utun1, interfaces after upgrading to Sierra.

This causes a problem with pf firewalls because Tunnelblick randomly assigns its interface to one of these, and if it’s not the default utun0 listed in /etc/pf.conf , the tunnel doesn’t work.

Does anyone know how to destroy these unused interfaces so that Tunnelblick reliably grabs utun0 on launch?

Trying to destroy existing utun interfaces with ifconfig throws this error:

See, e.g., this pf.conf that depends on knowing which utun interface Tunnelblick uses.

The text was updated successfully, but these errors were encountered:

jkbullard commented Nov 3, 2016

OpenVPN uses «/sbin/ifconfig utun0 delete» to delete utun0 («delete», not «destroy»), so you might try that (with sudo).

Or maybe changing the «dev tun» option in the configuration to «dev utun0» would force OpenVPN to use utun0.

That could cause other problems, I suppose, because It is a little-used and little-tested option, so Tunnelblick may not deal with it properly. For example, you might need to tell Tunnelblick to never load its tun driver if Tunnelblick doesn’t deal with the option properly. You can do that in the «Advanced» settings window. But that’s just a guess, it may work fine.

(If you have «pf» expertise, have you considered helping Tunnelblick use «pf»? Please take a look at this «help wanted» post.)

essandess commented Nov 3, 2016 •

The ifconfig delete command reigns the following error, which appears in lots of Tunnelblick logs:

I was able to remove most of the superfluous utun devices by deleting their appearance in the routing table, then rebooting. I believe, but am not certain, that these unnecessary utun devices are related to repeated upgrades of Tunnelblick. The commands look like a bunch of this:

After these steps:

  1. Delete utun appearance from routing table
  2. Delete Tunnelblick
  3. Reboot
  4. Reinstall Tunnelblick

I still have a utun0 interface on boot.

For now, I’ve simply replaced utun0 in /etc/pf.conf with utun1 and hope that these interfaces don’t swap names on boot.

_Update:_ All my unnecessary utun interfaces have reappeared since I posted a few minutes ago. No idea how they’re being created, how to get rid of them, or how to ensure Tunnelblick always grabs the same utun interface on boot.

essandess commented Nov 3, 2016

For now, I can point to a fully functional pf.conf firewall configuration for a Tunnelblick-based OpenVPN Server at the repo osx-openvpn-server.

That has most (all?) of the tricks you need for a pf-based firewall with Tunnelblick.

jkbullard commented Nov 3, 2016

Tunnelblick itself, and/or installing or uninstalling it, will not affect the utun devices.

It is OpenVPN that creates (and should destroy) the utun devices, and OpenVPN is only run when you connect to a VPN. My guess is that your OpenVPN configuration causes OpenVPN to not destroy the utun device when disconnecting, either because OpenVPN crashes before it deletes the utun device, or you are using «user nobody / group nobody» options in the OpenVPN configuration. If you do that, then OpenVPN is running as nobody when the configuration disconnects, and it is unable to destroy the utun device (which it can only do when it is running as root).

Depending on your setup, «user nobody / group nobody» may also leave bad entries in the routing table, because it can’t remove the routes it created. Some configurations don’t do any routing, so they don’t have this problem.

Thanks for pointing to the pf.conf configuration; I’ll take a look at it.

essandess commented Nov 3, 2016 •

Depending on your setup, «user nobody / group nobody» may also leave bad entries in the routing table, because it can’t remove the routes it created.

That’s exactly what I’m doing in my OpenVPN server configuration file, openvpn-server-tun.tblk/config.ovpn

I’ll have to go off and think about the security implications of changing user and group permissions.

I’ll bet the creation of the other utun devices I observed above were created when OpenVPN launched a server using this file.

jkbullard commented Nov 4, 2016

Originally I was thinking you could use a custom «down» script

  • Take Tunnelblick’s standard down script (/Applications/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh) and modify it to do the additional cleanup that must be done as root. See the OpenVPN documentation for info on environment variables that the down script can use and the arguments it is invoked with. I think the arguments to the down script include the device name that the connection used (such as «utun0»), which would make it easy to delete that device. I don’t know about obtaining the routing information, though — or rather the «unrouting» information.
  • If you use the «openvpn-down-root» plugin (which will be used by Tunnelblick automatically if you agree to that), then the down script runs as root. At some point you may have told Tunnelblick to not use openvpn-down-root; otherwise it would ask you each time you try to connect a configuration with «user nobody / group nobody».
Читайте также:  Running windows on mac gaming

But I am not completely sure that it is OK for the down script to delete the device — it would not be OK if OpenVPN does anything else with the device, I don’t think it does but I don’t really know.

As an alternative, you could use a custom «post-disconnect.sh» script that deletes the utun device. The catch there is that that script isn’t given any info about the device (or anything else!), so it would have to hard-code the «utun0» or «utun1» or whatever.

Info on using scripts is available at Using Scripts.

Now that I’m thinking about it, maybe Tunnelblick should have an option in it

essandess commented Nov 4, 2016

I’ll need to debug this step-by-step.

Step 1: Do you know how to figure out what’s creating the utun0 interface after a reboot without launching OpenVPN at boot?

jkbullard commented Nov 4, 2016

It’s OpenVPN itself that «creates» utun devices; Tunnelblick doesn’t have anything to do with them.

Maybe you have a configuration set to connect «when system starts»? So when you restart, it would try to connect that configuration and create utun0.

Even if you don’t, see if there is anything that mentions Tunnelblick or OpenVPN in /Library/LaunchDaemons. Maybe something got left there. If so, you can just delete it.

essandess commented Nov 4, 2016

Google groups is terrible—my response there was just lost twice, ado I’ll post it here.

You’ll want to use pf anchors for this. The pf directives will look like:

The repo osxfortress shows how to build a dynamic firewall using pf anchors and scripts.

This repo uses launchd plists to download open source threat data and update the firewall. It’s obvious how to modify the example for your design. See these files:

jkbullard commented Nov 4, 2016

Thanks. It’s totally off-topic, but:

I’ve already received this info two times (and responded once) in private emails that you sent, so there is definitely a problem somewhere. If you haven’t gotten my response, here it is:

Thanks. I’ll look all this over carefully. I am aware of your work but
didn’t remember that it uses pf.

It’s probably obvious, but what I’m looking to do is for an OpenVPN
client, not a server, although I do understand that the pf mechanism
is the same either way. I think the main difference is that on a
server you want it to be active at boot and never deactivate, but on a
client you want to be able to activate and deactivate it dynamically.

One basic question: Must I modify pf.conf, or can I do everything via
pfctl? It looks to me like I have to define an anchor in pf.conf (with
directives like you describe) before manipulating it with pfctl, but
I’m really not clear about that. I really hate making modifications to
system files directly because of possible race conditions and
conflicts with other programs that my make modifications to them.

jkbullard commented Nov 7, 2016

That folder (/var/log/Tunnelblick) should be created (if it doesn’t exist)
each time Tunnelblick runs its «installer».

That happens when you originally install Tunnelblick, when you install or
modify configurations, or make other changes that require Tunnelblick to
ask for a computer admin’s username/password. The folder should be owned by
root:wheel with 0755 permissions.

I assume it’s not a permissions problem – Tunnelblick doesn’t try to repair
permissions on that folder because it should be the only thing creating it
and it is created by Tunnelblick’s «installer» program with the proper
permissions.

On Mon, Nov 7, 2016 at 8:31 AM, Steve Smith notifications@github.com
wrote:

I have a plist net.tunnelblick.tunnelblick.tunnelblickd.plist that dumps
logs to:

But the directory /var/log/Tunnelblick doesn’t exist. Install bug?

essandess commented Aug 4, 2017

I haven’t been able to resolve this on the macOS or Tunnelblick sides, so I just added a bunch of extra rules to pf.conf for robustness in case it happens.

essandess commented Dec 9, 2018 •

Following up, unfortunately the fix to #493 doesn’t address this issue. Here’s what I see with ifconfig -a while running an OpenVPN server with Tunnelblick:

utun1: flags=8051 mtu 1500 inet 10.8.0.1 —> 10.8.0.2 netmask 0xffffffff utun2: flags=8051 mtu 2000 inet6 fe80::2c03:3e37:c633:5ede%utun2 prefixlen 64 scopeid 0x11 nd6 options=201

utun3: flags=8051 mtu 1380 inet6 fe80::6e78:9f4:5364:ab26%utun3 prefixlen 64 scopeid 0x12 nd6 options=201

utun4: flags=8051 mtu 1380 inet6 fe80::bbcb:aff:bb0b:e94%utun4 prefixlen 64 scopeid 0x13 nd6 options=201

utun5: flags=8051 mtu 1380 inet6 fe80::bee2:1994:fc74:d790%utun5 prefixlen 64 scopeid 0x14 nd6 options=201

utun6: flags=8051 mtu 2000 inet6 fe80::81b4:0775:c99d:a1ec%utun6 prefixlen 64 scopeid 0x15 nd6 options=201

jkbullard commented Dec 9, 2018

@essandess — Please post the diagnostic info obtained by following the procedure, which is a modified version of the one found at Read Before You Post:

  1. Make sure all Tunnelblick configurations are set to connect manually.
  2. Restart your computer.
  3. (Wait for the computer to completely start up.)
  4. Use ifconfig -a to verify that no utun devices exist.
  5. Open Tunnelblick’s «VPN Details» window.
  6. On the «Preferences» tab, please click the button to «Reset Disabled Warnings».
  7. On the «Configurations» tab, please select the configuration you want to connect in the list on the left.
  8. Make sure that «VPN log level» is set to «OpenVPN level 3 — normal output». This is the default setting; higher levels are for debugging OpenVPN itself, which is almost never needed and usually makes it harder to find the cause of a problem.
  9. Click the «Advanced» button; a new window will appear.
  10. Make sure «Keep connected» is not checked.
  11. Close the «Advanced Settings» window.
  12. Click on the «Log» tab.
  13. Click on the «Connect» button.
  14. Wait until the VPN is connected, then wait two minutes more.
  15. Click on the «Disconnect» button and wait until the disconnection is complete. If the disconnection is not complete within 60 seconds, continue anyway.
  16. Click on the «Copy Diagnostic Info to the Clipboard» button.
    Wait for the copy to complete (there is a spinning progress indicator; when it disappears the copy is complete).
  17. Paste into an email or web form.
  18. Remove any sensitive information before sending the email or the form.
Читайте также:  Для автозапуска установки windows

bins90 commented Jan 9, 2019

可以尝试使用 sudo ifconfig utun(数字序号) down
例如:sudo ifconfig utun1 down
输入个人用户密码确认删除

jkbullard commented Jul 1, 2019

I think this was caused by the Tunnelblick down script fails. When that happens, a bug in OpenVPN causes OpenVPN to fail to destroy the utun interface.

Although AFAIK that bug still exists in OpenVPN, Tunnelblick’s down script has been fixed so it should not fail, thus the OpenVPN bug will not be encountered.

aikfiend commented Jul 3, 2019 •

@jkbullard it looks like my 10 month baby girl was able to reproduce this issue twice on Mac OS Mojave Version: 10.14.5 (18F132) by just unplugging the power cable from Mac mini when Tunnelblick (version 3.7.9a (build 5321)) was launched and OpenVPN tunnel was created.
Could you please clarify in which version of Tunelblick it was fixed and which script exactly fixes that. I hope that I can find how I can remove utun0 interface there.

jkbullard commented Jul 3, 2019

@aikfiend — Tunnelblick 3.7.8beta03 includes the fixed scripts. They are used if you have set «DNS/WINS» to «Set nameserver».

However, they won’t help you with removing extra utun devices. Neither Tunnelblick not its scripts create them or destroy them. OpenVPN creates them and should destroy them.

See the earlier comments by @essandess about his attempts to delete the extra utun interfaces. A Google search for «remove utun» (without the quotation marks) shows some links with ideas. Note that one utun interface may be used by «Back to My Mac» or other macOS features [1], so you might not be able to delete all of them.

Or see Tunnelblick’s Support page for links to sources of help with OpenVPN; perhaps the OpenVPN users mailing list would get you some help deleting the utun devices.

Tunnelblick 3.7.9a could have caused a different problem with such a power loss, too. It could have left DNS set up for the VPN without restoring it to the pre-VPN values. (3.7.8beta03 won’t do that.) To fix that:

  1. Open System Preferences
  2. Click on «Network»
  3. Click on the «Advanced» button
  4. Click on the «DNS» tab
  5. Click on each entry in the list on the left side («DNS Servers») and click the minus button («-«) at the bottom of the list. If the entry is dim (grey instead of black, move on to the next step.
  6. Click on each entry in the list on the right side (Search domains») and click the minus button («-«) at the bottom of the list. √
  7. Click the «OK» button.
  8. Click the «Apply» button.
  9. Wait a few seconds for the changes to take effect.

jkbullard commented Jul 3, 2019

Since this «multiple utun» problem first appeared, I was assuming that since OpenVPN creates the utun device, it must be responsible for destroying it, too. I suspected that if the Tunnelblick «down» script failed, it caused OpenVPN to forget to destroy the utun device, leading to multiple utun devices. I never tested that assumption. Now I have, and it may have been wrong. Something else may be causing the multiple utun devices.

Although it’s true that OpenVPN destroys the utun when it does a normal shutdown of the VPN connection, some testing with Tunnelblick 3.7.9a and 3.8.0beta03 in a 10.14.5 virtual machine seems to indicate that the utun devices that OpenVPN creates do not survive a computer restart.

After connecting to a VPN (which created utun1 because utun0 already existed), I crashed the VM by «stopping» it. As I understand it, that should result in OpenVPN not being able to clean up, because the VM halts without doing any cleanup of any kind. (This was a Parallels VM, and I used «Stop» – not «Shutdown», which does an orderly shutdown of the computer.)

On restarting the VM, utun1 was gone and only utun0 remained. (By «gone», I mean it didn’t show up in the output of «netstat -nr».)

The same thing happens if I force quit Tunnelblick and then force quit OpenVPN while a VPN is connected: after that, the utun device seems to have disappeared. (That makes some sense because even a force quit «closes» file descriptors that the process has created, and, as described below, closing the file descriptor for utun is part of the procedure that OpenVPN uses to clean up when shutting down the VPN.)

So maybe something else is creating the utun devices? The first, utun0, seems to exist without OpenVPN ever being used. (It exists on a «virgin» 10.14.5 installation.)

OpenVPN destroying utun devices

I looked at OpenVPN’s code to see how it destroys the utun devices. Although I wrote earlier that:

OpenVPN uses «/sbin/ifconfig utun0 delete» to delete utun0 («delete», not «destroy»), so you might try that (with sudo).

I now think that that code is actually used for some other purpose. It looks like OpenVPN destroys the utun device by doing two things (in tun.c):

  1. It does «route delete -inet6 ifconfig_ipv6_local» (I assume «ifconfig_ipv6_local» is some kind of ipv6 subnet specifier.)
  2. It does «close(tt->fd);» which closes the utun device by specifying it’s file descriptor.

Источник

Оцените статью