Ցանկանու՞մ եք աշխատավայրում օգտագործել Linux-ը, բայց ձեր կորպորատիվ VPN-ն ձեզ թույլ չի տա: Այնուհետև այս հոդվածը կարող է օգնել, թեև դա որոշակի չէ: Նախապես ուզում եմ զգուշացնել, որ ես լավ չեմ հասկանում ցանցի ադմինիստրացիայի հարցերը, ուստի հնարավոր է, որ ես ամեն ինչ սխալ եմ արել։ Մյուս կողմից, հնարավոր է, որ ես կարողանամ այնպիսի ուղեցույց գրել, որ այն հասկանալի լինի սովորական մարդկանց համար, ուստի խորհուրդ եմ տալիս փորձել։
Հոդվածը պարունակում է շատ անհարկի տեղեկատվություն, բայց առանց այդ գիտելիքի ես չէի կարողանա լուծել այն խնդիրները, որոնք ինձ անսպասելիորեն հայտնվեցին VPN տեղադրելու հետ կապված: Կարծում եմ, որ յուրաքանչյուրը, ով կփորձի օգտվել այս ուղեցույցից, կունենա խնդիրներ, որոնք ես չունեի, և հուսով եմ, որ այս լրացուցիչ տեղեկատվությունը կօգնի ինքնուրույն լուծել այս խնդիրները:
Այս ուղեցույցում օգտագործվող հրամանների մեծ մասը պետք է գործարկվի sudo-ի միջոցով, որը հանվել է հակիրճ լինելու համար: Մտապահեք.
IP հասցեների մեծ մասը խիստ խեղաթյուրված է, այնպես որ, եթե դուք տեսնում եք 435.435.435.435-ի նման հասցե, ապա այնտեղ պետք է լինի նորմալ IP՝ հատուկ ձեր գործին:
Ես ունեմ Ubuntu 18.04, բայց կարծում եմ, որ փոքր փոփոխություններով ուղեցույցը կարող է կիրառվել այլ բաշխումների վրա: Այնուամենայնիվ, այս տեքստում Linux == Ubuntu:
Cisco Connect
Նրանք, ովքեր աշխատում են Windows կամ MacOS-ով, կարող են միանալ մեր կորպորատիվ VPN-ին Cisco Connect-ի միջոցով, որը պետք է նշի դարպասի հասցեն և ամեն անգամ միանալիս մուտքագրեք գաղտնաբառ, որը բաղկացած է ֆիքսված մասից և Google Authenticator-ի կողմից ստեղծված կոդից:
Linux-ի դեպքում ես չկարողացա գործարկել Cisco Connect-ը, բայց ինձ հաջողվեց google-ում գտնել openconnect-ն օգտագործելու առաջարկությունը, որը հատուկ ստեղծված էր Cisco Connect-ին փոխարինելու համար:
Բացեք միացումը
Տեսականորեն, Ubuntu-ն ունի հատուկ գրաֆիկական ինտերֆեյս openconnect-ի համար, բայց դա ինձ մոտ չաշխատեց: Միգուցե դա դեպի լավն է:
Ubuntu-ում openconnect-ը տեղադրված է փաթեթի կառավարիչից:
apt install openconnectՏեղադրվելուց անմիջապես հետո կարող եք փորձել միանալ VPN-ին
openconnect --user poxvuibr vpn.evilcorp.comvpn.evilcorp.com-ը մտացածին VPN-ի հասցե է
poxvuibr - մտացածին օգտանուն
openconnect-ը կխնդրի մուտքագրել գաղտնաբառ, որը, հիշեցնեմ, բաղկացած է ֆիքսված մասից և Google Authenticator-ի կոդից, այնուհետև կփորձի միանալ vpn-ին։ Եթե դա ստացվում է, շնորհավորում եմ, կարող եք ապահով բաց թողնել միջնամասը, որը շատ ցավ է պատճառում, և անցնել ֆոնային ռեժիմում գործարկվող openconnect-ի կետին: Եթե դա չի աշխատում, ապա կարող եք շարունակել: Թեև եթե այն աշխատեց, օրինակ, աշխատավայրում հյուրի Wi-Fi-ից միանալիս, ապա ուրախանալու համար դեռ վաղ է, դուք պետք է փորձեք կրկնել ընթացակարգը տնից:
Ատեստատ
Մեծ հավանականություն կա, որ ոչինչ չի սկսվի, և openconnect-ի ելքը այսպիսի տեսք կունենա.
POST https://vpn.evilcorp.com/
Connected to 777.777.777.777:443
SSL negotiation with vpn.evilcorp.com
Server certificate verify failed: signer not found
Certificate from VPN server "vpn.evilcorp.com" failed verification.
Reason: signer not found
To trust this server in future, perhaps add this to your command line:
--servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
Enter 'yes' to accept, 'no' to abort; anything else to view: fgets (stdin): Operation now in progressՍա մի կողմից տհաճ է, քանի որ VPN-ի հետ կապ չկար, բայց մյուս կողմից՝ ինչպես շտկել այս խնդիրը, սկզբունքորեն պարզ է։
Այստեղ սերվերը մեզ ուղարկեց վկայագիր, որով մենք կարող ենք որոշել, որ կապն իրականացվում է մեր հայրենի կորպորացիայի սերվերին, և ոչ թե չար խաբեբաին, և այս վկայականը անհայտ է համակարգին: Եվ հետևաբար նա չի կարող ստուգել, թե արդյոք սերվերը իրական է, թե ոչ: Եվ այսպես, ամեն դեպքում, այն դադարում է աշխատել։
Որպեսզի openconnect-ը միանա սերվերին, դուք պետք է հստակորեն ասեք, թե որ վկայականը պետք է ստացվի VPN սերվերից՝ օգտագործելով —servercert ստեղնը:
Եվ դուք կարող եք պարզել, թե սերվերը մեզ ինչ վկայական է ուղարկել անմիջապես այն բանից, թե ինչ է տպել openconnect-ը: Ահա այս հատվածից.
To trust this server in future, perhaps add this to your command line:
--servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
Enter 'yes' to accept, 'no' to abort; anything else to view: fgets (stdin): Operation now in progressԱյս հրամանով կարող եք նորից փորձել միանալ
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.comՄիգուցե հիմա այն աշխատում է, ապա կարող եք անցնել մինչև վերջ: Բայց անձամբ Ubunta-ն ինձ ցույց տվեց մի թուզ այս տեսքով
POST https://vpn.evilcorp.com/
Connected to 777.777.777.777:443
SSL negotiation with vpn.evilcorp.com
Server certificate verify failed: signer not found
Connected to HTTPS on vpn.evilcorp.com
XML POST enabled
Please enter your username and password.
POST https://vpn.evilcorp.com/
Got CONNECT response: HTTP/1.1 200 OK
CSTP connected. DPD 300, Keepalive 30
Set up DTLS failed; using SSL instead
Connected as 192.168.333.222, using SSL
NOSSSSSHHHHHHHDDDDD
3
NOSSSSSHHHHHHHDDDDD
3
RTNETLINK answers: File exists
/etc/resolvconf/update.d/libc: Warning: /etc/resolv.conf is not a symbolic link to /run/resolvconf/resolv.conf/etc/resolv.conf
# Generated by NetworkManager
search gst.evilcorpguest.com
nameserver 127.0.0.53/run/resolvconf/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.
nameserver 192.168.430.534
nameserver 127.0.0.53
search evilcorp.com gst.publicevilcorp.comhabr.com-ը կլուծի, բայց դուք չեք կարողանա այնտեղ գնալ: Jira.evilcorp.com-ի նման հասցեներն ընդհանրապես չեն լուծվում:
Այն, ինչ տեղի ունեցավ այստեղ, ինձ համար պարզ չէ։ Բայց փորձը ցույց է տալիս, որ եթե տողը ավելացնեք /etc/resolv.conf
nameserver 192.168.430.534այնուհետև VPN-ի ներսում գտնվող հասցեները կսկսեն կախարդական կերպով լուծվել, և դուք կարող եք անցնել դրանց միջով, այսինքն՝ այն, ինչ փնտրում է DNS-ը հասցեները լուծելու համար, հատուկ է /etc/resolv.conf-ում, այլ ոչ թե այլ տեղ:
Դուք կարող եք ստուգել, որ կապ կա VPN-ի հետ և այն աշխատում է առանց որևէ փոփոխության /etc/resolv.conf-ում: Դա անելու համար պարզապես բրաուզերում մուտքագրեք ոչ թե VPN-ի ռեսուրսի խորհրդանշական անունը, այլ դրա IP հասցեն:
Արդյունքում երկու խնդիր է առաջանում
- VPN-ին միանալիս դրա dns-ը չի հավաքվում
- ամբողջ տրաֆիկը անցնում է VPN-ի միջոցով, որը թույլ չի տալիս մուտք գործել ինտերնետ
Ես ձեզ կասեմ, թե ինչ անել հիմա, բայց նախ մի փոքր ավտոմատացում:
Գաղտնաբառի ֆիքսված մասի ավտոմատ մուտքագրում
Մինչ այժմ դուք, ամենայն հավանականությամբ, արդեն մուտքագրել եք ձեր գաղտնաբառը առնվազն հինգ անգամ, և այս ընթացակարգն արդեն հոգնեցրել է ձեզ: Նախ, քանի որ գաղտնաբառը երկար է, և երկրորդ, քանի որ մուտքագրելիս պետք է տեղավորել որոշակի ժամկետում
Խնդրի վերջնական լուծումը հոդվածում ներառված չէր, բայց կարող եք համոզվել, որ գաղտնաբառի ֆիքսված հատվածը պետք չէ բազմիցս մուտքագրել։
Ենթադրենք, որ գաղտնաբառի ֆիքսված մասը fixedPassword է, իսկ Google Authenticator-ի մասը՝ 567: Ամբողջ գաղտնաբառը կարող է փոխանցվել openconnect-ին ստանդարտ մուտքագրման միջոցով՝ օգտագործելով --passwd-on-stdin արգումենտը:
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdinԱյժմ դուք կարող եք անընդհատ վերադառնալ վերջին մուտքագրված հրամանին և այնտեղ փոխել Google Authenticator-ի միայն մի մասը:
Կորպորատիվ VPN-ը ձեզ թույլ չի տալիս շրջել ինտերնետում:
Ընդհանրապես, շատ անհարմար չէ, երբ դուք պետք է օգտագործեք առանձին համակարգիչ Habr գնալու համար: Stackoverfow-ից copy-paste անելու անկարողությունը կարող է ընդհանուր առմամբ կաթվածահար անել աշխատանքը, ուստի ինչ-որ բան պետք է անել:
Մենք պետք է ինչ-որ կերպ կազմակերպենք այն այնպես, որ երբ դուք պետք է մուտք գործեք ռեսուրս ներքին ցանցից, Linux-ը գնա VPN, իսկ երբ դուք պետք է գնաք Habr, այն գնա ինտերնետ:
openconnect-ը, vpn-ի հետ կապ գործարկելուց և հաստատելուց հետո, կատարում է հատուկ սկրիպտ, որը գտնվում է /usr/share/vpnc-scripts/vpnc-script-ում։ Որոշ փոփոխականներ փոխանցվում են սկրիպտին որպես մուտքագրում, և այն կարգավորում է VPN-ը: Ցավոք, ես չկարողացա պարզել, թե ինչպես կարելի է բաժանել երթևեկության հոսքերը կորպորատիվ VPN-ի և ինտերնետի մնացած մասերի միջև՝ օգտագործելով հայրենի սցենար:
Ըստ երևույթին, vpn-slice կոմունալը մշակվել է հատուկ ինձ նման մարդկանց համար, որը թույլ է տալիս առանց դափի պարելու թրաֆիկը ուղարկել երկու ալիքով։ Դե, այսինքն, դուք պետք է պարեք, բայց պետք չէ շաման լինել:
Երթևեկության տարանջատում vpn-slice-ի միջոցով
Նախ, դուք պետք է տեղադրեք vpn-slice, դուք պետք է ինքներդ պարզեք դա: Եթե մեկնաբանություններում հարցեր լինեն, այս մասին առանձին գրառում կգրեմ։ Բայց սա սովորական Python ծրագիր է, ուստի որևէ դժվարություն չպետք է լինի: Ես տեղադրել եմ virtualenv-ի միջոցով:
Եվ այնուհետև կոմունալը պետք է կիրառվի՝ օգտագործելով -script անջատիչը՝ նշելով, որ բացել կապը, որ ստանդարտ սցենարի փոխարեն պետք է օգտագործել vpn-slice:
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin
--script "./bin/vpn-slice 192.168.430.0/24 " vpn.evilcorp.com --script-ին փոխանցվում է հրաման, որը պետք է կանչվի սկրիպտի փոխարեն: ./bin/vpn-slice - ուղի դեպի vpn-slice գործարկվող ֆայլ 192.168.430.0/24 - հասցեների դիմակ, որոնց պետք է գնալ vpn-ում: Այստեղ մենք նկատի ունենք, որ եթե հասցեն սկսվում է 192.168.430-ով, ապա այս հասցեով ռեսուրսը պետք է փնտրել VPN-ի ներսում։
Իրավիճակն այժմ պետք է գրեթե նորմալ լինի։ Գրեթե. Այժմ դուք կարող եք գնալ Habr և կարող եք գնալ ներկորպորատիվ ռեսուրս ip-ով, բայց դուք չեք կարող գնալ ներկորպորատիվ ռեսուրս խորհրդանշական անունով: Եթե դուք նշում եք համապատասխանություն սիմվոլիկ անվան և հասցեի միջև, ապա ամեն ինչ պետք է աշխատի: Եվ աշխատեք այնքան ժամանակ, մինչև ip-ը փոխվի: Linux-ն այժմ կարող է մուտք գործել ինտերնետ կամ ինտրանետ՝ կախված IP-ից: Բայց ոչ կորպորատիվ DNS-ը դեռ օգտագործվում է հասցեն որոշելու համար:
Խնդիրը կարող է դրսևորվել նաև այս ձևով՝ աշխատավայրում ամեն ինչ լավ է, բայց տանը կարող եք մուտք գործել կորպորատիվ ներքին ռեսուրսներ միայն IP-ի միջոցով: Դա պայմանավորված է նրանով, որ երբ դուք միացված եք կորպորատիվ Wi-Fi-ին, օգտագործվում է նաև կորպորատիվ DNS-ը, և VPN-ից սիմվոլիկ հասցեները լուծվում են դրանում, չնայած այն հանգամանքին, որ դեռևս անհնար է նման հասցե գնալ առանց VPN օգտագործելու:
Հոսթեր ֆայլի ավտոմատ փոփոխություն
Եթե vpn-slice-ը պահանջվում է քաղաքավարի կերպով, ապա VPN-ը բարձրացնելուց հետո այն կարող է գնալ իր DNS, այնտեղ գտնել անհրաժեշտ ռեսուրսների IP հասցեները իրենց խորհրդանշական անուններով և մուտքագրել դրանք հոսթներում։ VPN-ն անջատելուց հետո այս հասցեները կհեռացվեն հոսթներից։ Դա անելու համար դուք պետք է սիմվոլիկ անուններ փոխանցեք vpn-slice-ին որպես փաստարկներ: Սրա նման.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin
--script "./bin/vpn-slice 192.168.430.0/24 jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com Այժմ ամեն ինչ պետք է աշխատի թե՛ գրասենյակում, թե՛ լողափում։
Որոնեք VPN-ի կողմից տրված DNS-ում բոլոր ենթադոմեյնների հասցեները
Եթե ցանցի ներսում քիչ հասցեներ կան, ապա hosts ֆայլը ավտոմատ կերպով փոփոխելու մոտեցումը բավականին լավ է աշխատում։ Բայց եթե ցանցում շատ ռեսուրսներ կան, ապա դուք անընդհատ պետք է ավելացնեք տողեր, ինչպիսիք են zoidberg.test.evilcorp.com-ը, սկրիպտին zoidberg-ը փորձարկման նստարաններից մեկի անունն է:
Բայց հիմա, երբ մենք մի փոքր հասկացանք, թե ինչու կարելի է վերացնել այս անհրաժեշտությունը:
Եթե VPN-ը բարձրացնելուց հետո նայեք /etc/hosts-ում, կարող եք տեսնել այս տողը
192.168.430.534 dns0.tun0 # vpn-slice-tun0 ԱՎՏՈՍՏԵՂԾՎԱԾ
Եվ նոր տող ավելացվեց resolv.conf-ում: Մի խոսքով, vpn-slice-ը ինչ-որ կերպ որոշեց, թե որտեղ է գտնվում vpn-ի dns սերվերը:
Այժմ մենք պետք է համոզվենք, որ evilcorp.com-ով վերջացող տիրույթի անվան IP հասցեն պարզելու համար Linux-ը գնում է կորպորատիվ DNS, իսկ եթե այլ բան է անհրաժեշտ, ապա լռելյայն։
Ես բավական ժամանակ փնտրեցի Google-ում և պարզեցի, որ նման ֆունկցիոնալությունը հասանելի է Ubuntu-ում առանց տուփի: Սա նշանակում է, որ կարող եք օգտագործել տեղական DNS սերվերը dnsmasq անունները լուծելու համար:
Այսինքն՝ դուք կարող եք համոզվել, որ Linux-ը IP հասցեների համար միշտ գնում է տեղական DNS սերվեր, որն էլ իր հերթին, կախված տիրույթի անունից, IP-ն կփնտրի համապատասխան արտաքին DNS սերվերի վրա։
Ցանցերի և ցանցային միացումների հետ կապված ամեն ինչ կառավարելու համար Ubuntu-ն օգտագործում է NetworkManager-ը, և գրաֆիկական ինտերֆեյսը, օրինակ, Wi-Fi կապեր ընտրելու համար, պարզապես դրա ճակատն է:
Մենք պետք է բարձրանանք դրա կոնֆիգուրացիայի մեջ:
- Ստեղծեք ֆայլ /etc/NetworkManager/dnsmasq.d/evilcorp-ում
հասցե=/.evilcorp.com/192.168.430.534
Ուշադրություն դարձրեք evilcorp-ի դիմաց գտնվող կետին: Այն ազդանշան է տալիս dnsmasq-ին, որ evilcorp.com-ի բոլոր ենթադոմեյնները պետք է որոնվեն կորպորատիվ dns-ում:
- Ասեք NetworkManager-ին, որ օգտագործի dnsmasq անունների լուծման համար
Ցանցի կառավարչի կոնֆիգուրացիան գտնվում է /etc/NetworkManager/NetworkManager.conf-ում: Դուք պետք է այնտեղ ավելացնեք.
[հիմնական] dns=dnsmasq
- Վերագործարկեք NetworkManager-ը
service network-manager restartԱյժմ, VPN-ին միանալուց հետո, օգտագործելով openconnect-ը և vpn-slice-ը, ip-ը կորոշվի նորմալ, նույնիսկ եթե դուք սիմվոլիկ հասցեներ չավելացնեք արգումենտներին vpnslice-ին։
Ինչպես մուտք գործել անհատական ծառայություններ VPN-ի միջոցով
Այն բանից հետո, երբ ինձ հաջողվեց միանալ VPN-ին, ես երկու օր շատ ուրախ էի, և հետո պարզվեց, որ եթե ես VPN-ին միանում եմ գրասենյակային ցանցից դուրս, ապա փոստը չի աշխատում։ Ախտանիշը ծանոթ է, այնպես չէ՞:
Մեր փոստը գտնվում է mail.publicevilcorp.com-ում, ինչը նշանակում է, որ այն չի մտնում կանոնների տակ dnsmasq-ում և փոստային սերվերի հասցեն որոնվում է հանրային DNS-ի միջոցով:
Դե, գրասենյակը դեռ օգտագործում է DNS, որը պարունակում է այս հասցեն: Ես այդպես էլ մտածեցի։ Փաստորեն, տողը dnsmasq-ին ավելացնելուց հետո
հասցե=/mail.publicevilcorp.com/192.168.430.534
իրավիճակը ընդհանրապես չի փոխվել. ip մնաց նույնը: Ես պետք է գնայի աշխատանքի։
Եվ միայն հետո, երբ խորացա իրավիճակի մեջ ու մի փոքր հասկացա խնդիրը, մի խելացի մարդ ինձ ասաց, թե ինչպես լուծել այն։ Պետք էր միանալ փոստի սերվերին ոչ թե հենց այնպես, այլ VPN-ի միջոցով
Ես օգտագործում եմ vpn-slice՝ VPN-ի միջոցով անցնելու 192.168.430-ով սկսվող հասցեներին: Իսկ փոստային սերվերը ոչ միայն ունի խորհրդանշական հասցե, որը evilcorp-ի ենթադոմեյն չէ, այլև չունի IP հասցե, որը սկսվում է 192.168.430-ով: Եվ, իհարկե, նա թույլ չի տալիս ընդհանուր ցանցից որևէ մեկին գալ իր մոտ:
Որպեսզի Linux-ը անցնի VPN-ով և դեպի փոստի սերվեր, դուք պետք է այն նաև ավելացնեք vpn-slice-ում: Ենթադրենք փոստառուի հասցեն է 555.555.555.555
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin
--script "./bin/vpn-slice 555.555.555.555 192.168.430.0/24" vpn.evilcorp.com Մեկ արգումենտով VPN-ի բարձրացման սցենար
Այս ամենը, իհարկե, այնքան էլ հարմար չէ։ Այո, դուք կարող եք տեքստը պահել ֆայլում և պատճենել-տեղադրել այն վահանակի մեջ՝ ձեռքով մուտքագրելու փոխարեն, բայց դա դեռ այնքան էլ հաճելի չէ: Գործընթացը հեշտացնելու համար դուք կարող եք հրամանը փաթաթել սցենարով, որը տեղակայված կլինի PATH-ում: Իսկ հետո միայն պետք է մուտքագրեք Google Authenticator-ից ստացված կոդը
#!/bin/sh
echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin
--script "./bin/vpn-slice 192.168.430.0/24 jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com Եթե սկրիպտը դնեք connect~evilcorp~-ում, կարող եք պարզապես գրել վահանակում
connect_evil_corp 567987Բայց հիմա դուք դեռ պետք է ինչ-ինչ պատճառներով բաց պահեք այն վահանակը, որում աշխատում է openconnect-ը
Աշխատում է openconnect-ը հետին պլանում
Բարեբախտաբար, openconnect-ի հեղինակները հոգ էին տանում մեր մասին և ծրագրին ավելացնում հատուկ բանալի՝ ֆոն, որը գործարկումից հետո ծրագիրը դարձնում է հետին պլանում։ Եթե այն գործարկեք այսպես, կարող եք փակել վահանակը գործարկումից հետո
#!/bin/sh
echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
--user poxvuibr
--passwd-on-stdin
--background
--script "./bin/vpn-slice 192.168.430.0/24 jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com Այժմ պարզ չէ, թե ուր են գնում տեղեկամատյանները: Ընդհանուր առմամբ, մեզ իրականում տեղեկամատյաններ պետք չեն, բայց դուք երբեք չգիտեք: openconnect-ը կարող է դրանք վերահղել դեպի syslog, որտեղ դրանք կպահվեն ապահով և ապահով: դուք պետք է հրամանին ավելացնեք –syslog անջատիչը
#!/bin/sh
echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
--user poxvuibr
--passwd-on-stdin
--background
--syslog
--script "./bin/vpn-slice 192.168.430.0/24 jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com Եվ այսպես, պարզվում է, որ openconnect-ը աշխատում է ինչ-որ տեղ հետին պլանում և ոչ մեկին չի անհանգստացնում, բայց պարզ չէ, թե ինչպես դա կանգնեցնել: Այսինքն, դուք, իհարկե, կարող եք զտել ps ելքը՝ օգտագործելով grep և փնտրել գործընթաց, որի անունը պարունակում է openconnect, բայց դա ինչ-որ կերպ հոգնեցուցիչ է: Շնորհակալություն հեղինակներին, ովքեր նույնպես մտածեցին այս մասին: Openconnect-ն ունի բանալին -pid-file, որով դուք կարող եք հրահանգել openconnect-ին գրել իր գործընթացի նույնացուցիչը ֆայլում:
#!/bin/sh
echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
--user poxvuibr
--passwd-on-stdin
--background
--syslog
--script "./bin/vpn-slice 192.168.430.0/24 jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com
--pid-file ~/vpn-pidԱյժմ դուք միշտ կարող եք սպանել գործընթացը հրամանով
kill $(cat ~/vpn-pid)Եթե գործընթաց չլինի, սպանելը անիծի, բայց սխալ չի նետի: Եթե ֆայլը չկա, ապա ոչ մի վատ բան նույնպես չի պատահի, այնպես որ դուք կարող եք ապահով կերպով սպանել գործընթացը սցենարի առաջին տողում:
kill $(cat ~/vpn-pid)
#!/bin/sh
echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
--user poxvuibr
--passwd-on-stdin
--background
--syslog
--script "./bin/vpn-slice 192.168.430.0/24 jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com
--pid-file ~/vpn-pidԱյժմ դուք կարող եք միացնել ձեր համակարգիչը, բացել վահանակը և գործարկել հրամանը՝ փոխանցելով այն Google Authenticator-ի կոդը: Այնուհետև կարելի է մխիթարել:
Առանց VPN-հատվածի: Հետբառի փոխարեն
Պարզվեց, որ շատ դժվար է հասկանալ, թե ինչպես ապրել առանց VPN-slice-ի։ Ես ստիպված էի շատ կարդալ և գուգլել: Բարեբախտաբար, խնդրի հետ այդքան ժամանակ անցկացնելուց հետո տեխնիկական ձեռնարկները և նույնիսկ man openconnect-ը հուզիչ վեպեր են կարդացվում:
Արդյունքում ես պարզեցի, որ vpn-slice-ը, ինչպես մայրենի սցենարը, փոփոխում է երթուղային աղյուսակը առանձին ցանցերի։
Երթուղային աղյուսակ
Պարզ ասած, սա աղյուսակ է առաջին սյունակում, որը պարունակում է այն հասցեն, որով Linux-ը ցանկանում է անցնել, պետք է սկսվի, իսկ երկրորդ սյունակում, թե որ ցանցի ադապտեր անցնել այս հասցեով: Իրականում խոսողներն ավելի շատ են, բայց դա չի փոխում էությունը։
Ուղղորդման աղյուսակը դիտելու համար անհրաժեշտ է գործարկել ip route հրամանը
default via 192.168.1.1 dev wlp3s0 proto dhcp metric 600
192.168.430.0/24 dev tun0 scope link
192.168.1.0/24 dev wlp3s0 proto kernel scope link src 192.168.1.534 metric 600
192.168.430.534 dev tun0 scope link Այստեղ յուրաքանչյուր տող պատասխանատու է այն բանի համար, թե որտեղ պետք է գնաք՝ ինչ-որ հասցեով հաղորդագրություն ուղարկելու համար: Առաջինը նկարագրություն է, թե որտեղից պետք է սկսվի հասցեն: Որպեսզի հասկանաք, թե ինչպես կարելի է որոշել, որ 192.168.0.0/16 նշանակում է, որ հասցեն պետք է սկսվի 192.168-ով, դուք պետք է google-ով փնտրեք, թե ինչ է IP հասցեի դիմակը: Dev-ից հետո կա ադապտերի անունը, որին պետք է ուղարկվի հաղորդագրությունը:
VPN-ի համար Linux-ը պատրաստեց վիրտուալ ադապտեր՝ tun0: Գիծն ապահովում է, որ 192.168-ից սկսած բոլոր հասցեների երթևեկությունն անցնում է դրա միջով
192.168.0.0/16 dev tun0 scope link Կարող եք նաև դիտել երթուղային աղյուսակի ներկա վիճակը՝ օգտագործելով հրամանը երթուղին `ն (IP հասցեները խելամտորեն անանունացված են) Այս հրամանը արդյունք է տալիս այլ ձևով և ընդհանուր առմամբ հնացած է, բայց դրա արդյունքը հաճախ հանդիպում է ինտերնետի ձեռնարկներում, և դուք պետք է կարողանաք կարդալ այն:
Որտեղ պետք է սկսվի երթուղու IP հասցեն, կարելի է հասկանալ Destination և Genmask սյունակների համակցությունից: IP հասցեի այն հատվածները, որոնք համապատասխանում են Genmask-ի 255 թվերին, հաշվի են առնվում, իսկ որտեղ կա 0՝ ոչ։ Այսինքն՝ Destination 192.168.0.0-ի և Genmask 255.255.255.0-ի համադրությունը նշանակում է, որ եթե հասցեն սկսվում է 192.168.0-ով, ապա դրան ուղղված հարցումը կանցնի այս ճանապարհով: Եվ եթե նպատակակետ 192.168.0.0, բայց Genmask 255.255.0.0, ապա 192.168-ով սկսվող հասցեների հարցումները կանցնեն այս ճանապարհով:
Որպեսզի պարզեմ, թե իրականում ինչ է անում vpn-slice-ը, ես որոշեցի նայել աղյուսակների վիճակներին՝ առաջ և հետո:
Մինչև VPN-ը միացնելը այսպիսին էր
route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0
222.222.222.0 0.0.0.0 255.255.255.0 U 600 0 0 wlp3s0
333.333.333.333 222.222.222.1 255.255.255.255 UGH 0 0 0 wlp3s0Openconnect-ը առանց vpn-slice-ի զանգահարելուց հետո դարձավ այսպես
route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0
222.222.222.0 0.0.0.0 255.255.255.0 U 600 0 0 wlp3s0
333.333.333.333 222.222.222.1 255.255.255.255 UGH 0 0 0 wlp3s0
192.168.430.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
192.168.430.534 0.0.0.0 255.255.255.255 UH 0 0 0 tun0Իսկ openconnect-ը զանգահարելուց հետո vpn-slice-ի հետ միասին այսպես
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0
222.222.222.0 0.0.0.0 255.255.255.0 U 600 0 0 wlp3s0
333.333.333.333 222.222.222.1 255.255.255.255 UGH 0 0 0 wlp3s0
192.168.430.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
192.168.430.534 0.0.0.0 255.255.255.255 UH 0 0 0 tun0Կարելի է տեսնել, որ եթե դուք չեք օգտագործում vpn-slice, ապա openconnect-ը բացահայտ գրում է, որ բոլոր հասցեները, բացառությամբ հատուկ նշվածների, պետք է մուտք գործել vpn-ի միջոցով։
Հենց այստեղ:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0Այնտեղ, կողքին, անմիջապես նշվում է մեկ այլ ճանապարհ, որը պետք է օգտագործվի, եթե այն հասցեն, որով փորձում է անցնել Linux-ը, չի համընկնում աղյուսակի որևէ դիմակի հետ։
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0Այստեղ արդեն գրված է, որ այս դեպքում պետք է օգտագործել ստանդարտ Wi-Fi ադապտեր։
Կարծում եմ, որ VPN ուղին օգտագործվում է, քանի որ այն առաջինն է երթուղային աղյուսակում.
Եվ տեսականորեն, եթե դուք հեռացնում եք այս լռելյայն ուղին երթուղային աղյուսակից, ապա dnsmasq openconnect-ի հետ համատեղ պետք է ապահովվի նորմալ աշխատանքը:
Ես փորձեցի
route del defaultԵվ ամեն ինչ ստացվեց:
Հարցումների ուղղում դեպի փոստի սերվեր առանց vpn-slice-ի
Բայց ես նաև ունեմ փոստի սերվեր 555.555.555.555 հասցեով, որը նույնպես պետք է մուտք գործել VPN-ի միջոցով: Դեպի երթուղին նույնպես պետք է ձեռքով ավելացվի:
ip route add 555.555.555.555 via dev tun0Իսկ հիմա ամեն ինչ լավ է։ Այսպիսով, դուք կարող եք անել առանց vpn-slice, բայց դուք պետք է լավ իմանաք, թե ինչ եք անում: Ես հիմա մտածում եմ՝ արդյոք ավելացնել հայրենի openconnect սկրիպտի վերջին տողին՝ լռելյայն երթուղին հեռացնելու և փոստարկղի համար երթուղի ավելացնել vpn-ին միանալուց հետո, միայն թե իմ հեծանիվում ավելի քիչ շարժվող մասեր լինեն։
Հավանաբար, այս վերջաբանը բավական կլիներ, որ ինչ-որ մեկը հասկանա, թե ինչպես ստեղծել VPN: Բայց մինչ ես փորձում էի հասկանալ, թե ինչ և ինչպես անել, ես կարդացի բավականին շատ նման ուղեցույցներ, որոնք աշխատում են հեղինակի համար, բայց ինչ-ինչ պատճառներով ինձ համար չեն աշխատում, և որոշեցի այստեղ ավելացնել այն բոլոր կտորները, որոնք գտա: Ես շատ ուրախ կլինեի նման բանի համար։
Source: www.habr.com