uzyskiwanie VPN openconnect do pracy przez menedżera sieci

jest to ten sam problem, co tutaj: Pobieranie openconnect VPN do pracy przez GUI , ale moje dodatki do niego zostały usunięte i zostałem poproszony o utworzenie nowego pytania.

w rzeczywistości jest wielu ludzi, którzy zadają podobne pytania tutaj, wszyscy z 0 odpowiedziami.

wersje oprogramowania: ubuntu 14.04, openconnect 5.02

główny problem: próbuję dodać połączenie VPN do menedżera sieci, używając openconnect. kiedy podam moją nazwę użytkownika i hasło VPN, łączy się ono pomyślnie, ale nie mogę rozwiązać dns.

jeśli uruchomię openconnect w terminalu przez sudo, dns działa.

sudo openconnect -u <username> https://<vpn concentrator name>

więcej szczegółów:

1a. podczas łączenia przez openconnect i menedżera sieci, mimo że wyraźnie dodałem dns i domenę wyszukiwania na karcie ipv4, tylko domena wyszukiwania kończy się w /etc/resolv.conf. nawet jeśli nie dostarczam DNS i domen wyszukiwania, w dziennikach widzę, że pobiera te informacje z koncentratora VPN. ponownie domena wyszukiwania jest poprawnie aktualizowana. [log poniżej]

1b. podczas łączenia przez sudo w terminalu resolv.conf jest poprawnie zapełniany dns i domenami wyszukiwania, mimo że nie dodałem tych informacji w wierszu poleceń ani nie podałem ścieżki do skryptu vpnc. to musi być pobieranie z koncentratora VPN. [log także poniżej]

2a. podczas łączenia przez openconnect i menedżera sieci tworzony jest nowy interfejs „vpn0”.

2b. podczas łączenia za pomocą sudo i wiersza poleceń tworzony jest nowy interfejs „tun0”.

zaloguj podczas łączenia przez menedżera sieci:

NetworkManager[784]: <info> Starting VPN service 'openconnect'...
NetworkManager[784]: <info> VPN service 'openconnect' started (org.freedesktop.NetworkManager.openconnect), PID 4513
NetworkManager[784]: <info> VPN service 'openconnect' appeared; activating connections
NetworkManager[784]: <info> VPN plugin state changed: init (1)

tutaj prosi o moje hasło

NetworkManager[784]: <info> VPN plugin state changed: starting (3)
NetworkManager[784]:    SCPlugin-Ifupdown: devices added (path: /sys/devices/virtual/net/vpn0, iface: vpn0)
NetworkManager[784]:    SCPlugin-Ifupdown: device added (path: /sys/devices/virtual/net/vpn0, iface: vpn0): no ifupdown configuration found.
NetworkManager[784]: <warn> /sys/devices/virtual/net/vpn0: couldn't determine device driver; ignoring...
NetworkManager[784]: <info> VPN connection '<connection name>' (Connect) reply received.
openconnect[4544]: Attempting to connect to server <ip address>:443
openconnect[4544]: SSL negotiation with <correctly identified vpn server>
openconnect[4544]: Connected to HTTPS on <correctly identified vpn server>
openconnect[4544]: Got CONNECT response: HTTP/1.1 200 OK
openconnect[4544]: CSTP connected. DPD 30, Keepalive 20
NetworkManager[784]: <info> VPN connection '<connection name>' (IP Config Get) reply received.
NetworkManager[784]: <info> VPN connection '<connection name>' (IP4 Config Get) reply received.
NetworkManager[784]: <info> VPN connection '<connection name>' (IP6 Config Get) reply received.
NetworkManager[784]: <info> VPN Gateway: <ip address>
NetworkManager[784]: <info> Tunnel Device: vpn0
NetworkManager[784]: <info> IPv4 configuration:
NetworkManager[784]: <info>   Internal Address: 10.xxx.xxx.xxx
NetworkManager[784]: <info>   Internal Prefix: 19
NetworkManager[784]: <info>   Internal Point-to-Point Address: 10.xxx.xxx.xxx
NetworkManager[784]: <info>   Maximum Segment Size (MSS): 0
NetworkManager[784]: <info>   Forbid Default Route: no
NetworkManager[784]: <info>   Internal DNS: <ip address>
NetworkManager[784]: <info>   Internal DNS: <ip address>
NetworkManager[784]: <info>   DNS Domain: '(none)'
NetworkManager[784]: <info> IPv6 configuration:
NetworkManager[784]: <info>   Internal Address: <ipv6 ip>
NetworkManager[784]: <info>   Internal Prefix: 64
NetworkManager[784]: <info>   Internal Point-to-Point Address: <ipv6 ip>
NetworkManager[784]: <info>   Maximum Segment Size (MSS): 0
NetworkManager[784]: <info>   Forbid Default Route: no
NetworkManager[784]: <info>   DNS Domain: '(none)'
openconnect[4544]: Connected vpn0 as <ip address> + <ipv6 ip>, using SSL
openconnect[4544]: Established DTLS connection (using OpenSSL)
NetworkManager[784]: <info> VPN connection '<connection name>' (IP Config Get) complete.
NetworkManager[784]: <info> Policy set '<connection name>' (vpn0) as default for IPv4 routing and DNS.
NetworkManager[784]: <info> Policy set '<connection name>' (vpn0) as default for IPv6 routing and DNS.
NetworkManager[784]: <info> Writing DNS information to /sbin/resolvconf
dnsmasq[1027]: setting upstream servers from DBus
dnsmasq[1027]: using nameserver 127.0.0.1#53 for domain 10.in-addr.arpa
dnsmasq[1027]: using nameserver 127.0.0.1#53 for domain <home search domain>
dnsmasq[1027]: using nameserver 127.0.0.1#53 for domain <vpn search domain>
dnsmasq[1027]: using nameserver <ip address>#53 for domain 10.in-addr.arpa
dnsmasq[1027]: using nameserver <ip address>#53 for domain <home search domain>
dnsmasq[1027]: using nameserver <ip address>#53 for domain <vpn search domain>
dnsmasq[1027]: using nameserver <ip address>#53 for domain 10.in-addr.arpa
dnsmasq[1027]: using nameserver <ip address>#53 for domain <home search domain>
dnsmasq[1027]: using nameserver <ip address>#53 for domain <vpn search domain>
dbus[471]: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper)
NetworkManager[784]: <info> VPN plugin state changed: started (4)
NetworkManager[784]:    keyfile: updating /etc/NetworkManager/system-connections/<connection name>-6a503043-13b0-4ce7-9749-29cd3054cae3
dbus[471]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'

pomimo całego szumu w dzienniku związanego z aktualizacją resolv.conf usuwa serwery nazw, ale nie zastępuje ich adresami IP w dzienniku. poprawnie aktualizuje domenę wyszukiwania, więc prawdopodobnie nie jest to problem z uprawnieniami.

zaloguj się podczas łączenia za pomocą sudo openconnect w terminalu:

NetworkManager[784]:    SCPlugin-Ifupdown: devices added (path: /sys/devices/virtual/net/tun0, iface: tun0)
NetworkManager[784]:    SCPlugin-Ifupdown: device added (path: /sys/devices/virtual/net/tun0, iface: tun0): no ifupdown configuration found.
NetworkManager[784]: <warn> /sys/devices/virtual/net/tun0: couldn't determine device driver; ignoring...
dbus[471]: [system] Activating service name='org.freedesktop.hostname1' (using servicehelper)
kernel: [ 3258.725774] systemd-hostnamed[4927]: Warning: nss-myhostname is not installed. Changing the local hostname might make it unresolveable. Please install nss-myhostname!
dbus[471]: [system] Successfully activated service 'org.freedesktop.hostname1'

nic o aktualizacji resolv.conf, a jednak poprawnie aktualizuje serwery nazw i domenę wyszukiwania.

zaktualizuj, jeśli zignoruję wszystkie ostrzeżenia w resolv.conf i dodam do niego serwery nazw koncentratora VPN, natychmiast mogę przeglądać. oczywiście, jak tylko się rozłączę, te zmiany zostaną zastąpione.

w 2012 r. wystąpił błąd , ale wygasł. problemem wydaje się być skrypt vpnc.

Próbowałem ręcznie zaktualizować moje skrypty vpnc do najnowszych wersji, ale bezskutecznie.

niektóre dalsze badania okazują się, że od 12.04 resolv.conf nie jest już tam, gdzie serwery nazw szukają rozwiązania dns podczas korzystania z menedżera sieci. dlatego działa, gdy korzystam z wiersza polecenia, ale nie działa przy użyciu menedżera sieci. zamiast tego dodawany jest serwer nazw 127.0.1.1 [dnsmasq] i ten serwer nazw otrzymuje adresy IP rzeczywistych serwerów nazw.

Dużą zaletą jest to, że jeśli łączysz się z VPN, zamiast przekierowywać cały ruch DNS przez VPN, tak jak w przeszłości, zamiast tego wysyłasz tylko zapytania DNS związane z podsiecią i domenami ogłoszonymi przez tę VPN

aktualizacja wyłączająca dnsmasq, jak wyjaśniono w powyższym linku, rozwiązuje problem, ponieważ plik /etc/resolv.conf jest zapełniony.

to nie jest prawdziwe rozwiązanie, ale jest to awaria.

Sprawdź, czy istnieje niezgodność między hostem, który próbujesz rozwiązać za pośrednictwem sieci VPN, a „domeną DNS” wysyłaną przez serwer Cisco VPN.

Aby to sprawdzić, otwórz terminal i uruchom:

tail -f /var/log/syslog

Następnie uruchom openconnect poprzez menedżera sieci. Zobaczysz całą masę wyników, w tym kilka takich wierszy:

5 grudnia 12:54:31 kajak NetworkManager [1266]: Wewnętrzny DNS: 10.0.20.21

5 grudnia 12:54:31 kajak NetworkManager [1266]: Wewnętrzny DNS: 10.10.3.32

5 grudnia 12:54:31 kajak NetworkManager [1266]: Domena DNS: „internal.example.com”

A dalej zobaczysz

5 grudnia 12:54:31 canoe dnsmasq [1871]: using nameserver 10.0.20.21 # 53 dla domeny internal.example.com

Oznacza to, że serwer VPN instruuje klienta, że ​​serwery DNS powinny być używane do rozpoznawania hostów internal.example.com, takich jak server.internal.example.com.

W moim przypadku muszę rozwiązać problem server.example.com(i nie uzyskałem żadnego wyniku).

Rozwiązaniem było dla mnie przejście do ustawień VPN i dodanie example.comjako dodatkowej domeny wyszukiwania:

Nie zapomnij rozłączyć VPN, a następnie połączyć się ponownie, aby ustawienie zaczęło obowiązywać.

Więc rozwiązałem to dla siebie wystarczająco zadowalająco. Jestem na Mint 18 / Ubuntu 16.04

Mój problem polegał na tym, że po połączeniu się z Openconnect VPN przez NetworkManager nie mogłem już rozpoznać DNS dla domen spoza moich domen roboczych. Tzn. Straciłem internet!

Moja poprawka była następująca:

1. W NetworkManager edytowałem połączenie VPN w „Połączenia sieciowe”.
2. Na karcie IPv4 zmieniono metodę na „Tylko adresy automatyczne (VPN)”
3. Dodano moją pracę serwera DNS (np. 10.10.10.100) i „Szukaj domeny” w „mywork.tld”
4. Kliknij „Trasy”.
5. Dodaj trasę obejmującą moją sieć roboczą, np. 10.10.0.0 / 255.255.0.0 i bramę 10.10.10.253 <- brama VPN, którą dostałem od „traceroute”.
6. Następnie zaznaczyłem obie opcje: „Ignoruj ​​automatycznie wybrane trasy” ii. „Używaj tego połączenia tylko do zasobów w jego sieci”

Działa na moim komputerze.

Rozumiem, co się stało, że:

1. Mój plik /etc/resolv.conf jest skonfigurowany z programem dnsmasq i wskazuje na 127.0.1.1
2. dnsmasq używa serwerów DNS mojego usługodawcy internetowego do ogólnego rozpoznawania DNS w Internecie. Na przykład ISP DNS to powiedzmy 8.8.8.8.
3. Łączę się z VPN, serwer DNS 10.10.10.100 został dodany jako dodatkowy serwer do dnsmasq, który ma być używany do rozpoznawania DNS „mywork.tld”.
4. Gdy jestem w sieci VPN, moja zapora robocza nie pozwala mi używać portu 53 do 8.8.8.8, więc moja ogólna rozdzielczość Internetu zanika. DNS powinien przekroczyć limit czasu i przejść na dodatkowy serwer DNS, ale z jakiegoś powodu tak nie jest?
5. Pozostaje mi tylko dostęp do rozdzielczości DNS dla „server01.mywork.tld”, ponieważ to zapytanie trafia do 10.10.10.100, do którego mam dostęp przez VPN.
6. Jeśli zapytam o www.google.com, nie powiedzie się, mimo że mój wewnętrzny DNS może przekazać dalej. Mogę tylko założyć, że mój wewnętrzny DNS nigdy nie jest pytany.

Wydaje się, że moja poprawka działa tak długo, jak długo moja praca nie zmienia adresu IP sieci ani serwera DNS.

Jestem trochę zamglony, ale myślę, że to działa dla mnie, ponieważ kiedy to zrobisz, moja bezprzewodowa karta sieciowa stanie się moim domyślnym połączeniem sieciowym. Tak więc zapytania DNS przechodzą do wersji 8.8.8.8 przez Wi-Fi. Każde zapytanie dotyczące „xyz.mywork.tld” jest proszone przez dnsmasq, aby przejść do 10.10.10.100. Ustawiłem dla tego trasę, dzięki czemu przechodzi ona przez kartę sieciową „vpn0”, która zwraca prawidłowy adres IP 10.10.10.x dla „xyz.mywork.tld”. Bingo bango Rozdzielczość DNS dla sieci wewnętrznych i zewnętrznych i wszyscy są zadowoleni.