Este foarte frecvent, în special în companii, că există anumite site-uri la care accesul este restricționat din anumite motive (uneori absurd, alteori nu), cum ar fi site-uri de descărcare, e-mailuri web și altele.
În general, aceste restricții sunt făcute prin blocarea domeniului site-ului în cauză, adăugând, de asemenea, restricții la anumite porturi. Ce facem atunci dacă trebuie să obținem niște informații imediat?
De obicei utilizatorii de ferestre din folosiți programe precum Putty (care este disponibil și pe GNU / Linux)sau Libertatea ta, dar există un alt mod puțin mai sigur de a putea accesa site-urile pe care le-am refuzat, folosind SSH y Șosete5.
Pentru acest exemplu, mă bazez pe faptul că avem porturi deschise 80, 3128 (utilizat în mod normal pentru navigație) și 9122, și vom vedea două cazuri reale. Nu este scopul meu cu acest articol să explic în detaliu ce este SSH, Șosete5 și cum funcționează, vom lăsa asta pentru altă dată. Vom vedea două exemple:
- Conectarea la un alt PC prin SSH folosind adresa sa IP.
- Conectarea la un alt PC prin SSH folosind un domeniu (prin DNS).
De ce avem nevoie?
- Un computer cu acces la Internet pe care îl putem accesa prin SSH.
- SSH instalat, desigur.
- Tirbușon (în cazul în care suntem în spatele unui proxy).
Deschidem un terminal și punem (în cazul Debian):
$ sudo aptitude install ssh corkscrew
OK .. Am instalat deja. Cum mă conectez?
E foarte simplu. Deschidem un terminal și punem ssh -p 443 user @ internet_computer_ip:
ssh -p 9122 -D 1080 elav@192.168.1.1
Parametru -p După cum este logic, este folosit pentru a stabili prin ce port ne vom conecta. Atat de simplu Acum, deschidem preferințele browserului (în cazul meu Firefox) și în Opțiuni de rețea, bifăm doar opțiunea de utilizat Server de șosete și punem:
127.0.0.1:1080
Acest lucru este suficient pentru a naviga.
Ce se întâmplă dacă suntem în spatele unui proxy?
Este posibil să fim în spatele unui server proxy foarte restrictiv sau pur și simplu al nostru ISP nu ne permite să ne conectăm printr-o adresă IP, deci trebuie să o facem DNS. Aici vine jocul Tirbușon. Pentru a utiliza această aplicație, tot ce trebuie să facem este să creăm un fișier în dosar cu editorul nostru preferat .ssh la noi / Home, numit config:
$ vim ~/.ssh/config
și în interior punem așa ceva:
host dominio.net
user tu_usuario
hostname dominio.net
port 9122
proxycommand corkscrew IP_Proxy 3128 %h %p
DynamicForward 1080
Compression yes
LocalForward 8888 localhost:8888
Explicând puțin acest lucru. În parametrul gazdă punem adresa URL a serverului la care urmează să ne conectăm (care trebuie să aibă SSH disponibil de către 9122, așa cum am văzut în această postare. În parametru comandă proxy după tirbuşon punem IP-ul proxy-ului nostru sau FQDN, de exemplu: proxy.domain.net și portul care este utilizat pentru a naviga.
Acum trebuie doar să deschidem un terminal și să punem:
ssh usuario@dominio.net
Acum, un ultim detaliu. Poate fi necesar să modificați un parametru în configurația Firefox dacă nu am avea nicio legătură. Deschidem o filă și tastăm about: config. Promitem că nu vom pune mâna în setări și căutăm:
network.dns.disablePrefetch
Și dacă este în fals l-am pus adevărat.
Excelent, aș vrea doar să am un server pentru a putea face acest lucru într-un mod funcțional și nu doar pentru a practica între 2 computere din rețeaua mea locală:) ...
Una duda, ¿No se podrá navegar a desdelinux.net desde https?
Nu, chiar acum nu poți. Ar trebui să cumpărăm un certificat SSL și costă aproximativ 60 USD pe lună sau pe an, bani pe care nu-i avem 🙁 ... scuze prieten.
Și de ce nu un certificat autosemnat?
Nu știu prea multe despre asta, dar dacă generăm noi înșine un certificat, atunci browserul dvs. vă va spune că site-ul nu este de încredere și că ... 🙁
Dacă îmi amintesc bine, mi se pare că am văzut vreodată certificate limitate la aproximativ 15 USD pe an, desigur, acest lucru depinde în mare măsură de furnizorul de hosting. Dar, sincer, pentru un blog (public din fire) nu văd necesitatea navigării HTTPS, cu excepția poate pentru a ne asigura că informațiile pe care le vedem sunt într-adevăr originale și nu fac parte dintr-un atac om-în-mijloc (sau dorința poate fi, de asemenea, un semn că devenim puțin paranoici) 😉
pe serverul de șosete îți lipsea un punct la 127.0.0.1:1080
Mulțumesc. Chiar acum îl corectez.
Ei bine, trebuie să spun că SSH arată foarte interesant ...
hehehe da, nu știi minunile care se pot face doar cu o conexiune SSH 😀
Poate fi posibil să scoateți tirbușonul din ecuație, cel puțin pentru Firefox.
În „despre: config”, setați intrarea network.proxy.socks_remote_dns la adevărat, ceea ce, în cazul unui proxy șosete v5, face ca cererile DNS să fie făcute și de proxy-ul șosete.
Link-ul meu nu are restricții majore, așa că nu știu dacă va funcționa. Încearcă și raportează. 😉
O altă sugestie pe care am văzut-o acolo este să o folosesc -4D în loc de -D pentru a crea proxy-ul doar pe o adresă ipv4. Se pare că acest lucru optimizează puțin conexiunea.
În cele din urmă: dacă nu doriți să executați nicio comandă la distanță, puteți utiliza parametrul la final -N (astfel evităm să punem căștile), iar pentru a ne deconecta ar trebui doar să dăm un Ctrl + C.
Mulțumesc pentru sugestie Hugo, ar trebui să încerce. Apropo, cu toată această combinație folosesc și Screen 😀
Îl folosesc și eu, deși prin byobu. De fapt, sunt momente în care am format o mizerie extraordinară, deoarece am avut acces la gazde în care am avut acces la alte gazde în care am avut acces și la alții, etc. O vreme am ajuns să închid totul pentru că îmi era greu să știu de unde accesam unde, hehehe.
Hugo despre vreme, sună-mă din casa ta pe telefonul meu mobil ca să te sun înapoi 😉
În plus față de -4D (pentru a optimiza conexiunea) și -N (pentru a spune SSH că mergem doar la porturi de redirecționare) putem adăuga chei securizate pe ambele părți ale conexiunii și un & la sfârșitul liniei de invocare SSH la inițiați un tunel într-un mod automat.
Presupunând că avem fișierele configurate corect:
~ / .ssh /
chei_autorizate2
id_rsa
id_rsa.pub
pe mașinile implicate în conexiune, instrucțiunea finală ar fi:
$ssh -p 9122 -4D 1080 -N elav@192.168.1.1 &
Puteți să o adăugați la /etc/rc.local pentru a ne asigura că conexiunea este stabilită automat de fiecare dată când pornește sistemul.
Mai mult, folosind pm-suspend și eth-tool putem configura /etc/rc.local pentru a trezi mașina care va acționa ca un proxy prin internet și pentru a se conecta automat la acesta și apoi pentru a o lăsa din nou în standby - până când ne închidem sistemul ...
Tocmai fericit 😀
Contribuție excelentă .. Mulțumesc 😀