Data inscrierii: Jul 03, 2002 Locatie: Frankfurt am Main
Trimis: 10 11 2015, 13:00 Titlul subiectului:
Muta cablul Ethernet din eth0 in eth1, schimba maparea adreselor de IP intre eth0 si eth1 si adauga o ruta persistenta de la net-ul adresei eth0 la net-ul adresei eth1(care acum are legatura la internet).
eu cred ca zice altceva: vrea sa foloseasca un NIC pt proxy si cu celalalr sa aiba conexiune la net (pt ssh sau rdp-uri probabil). Problema e ca nu ai decat o ruta default pt 0.0.0.0 pe sisteme simple. Ambele NIC-uri sunt in acelasi segment de ip, probabil.
Astept sa vad si eu ce zice unul mai inteligent ca fara alte componente de retea e greu de rezolvat asta.
Data inscrierii: Jul 03, 2002 Locatie: Frankfurt am Main
Trimis: 10 11 2015, 13:25 Titlul subiectului:
cip_a a scris:
eu cred ca zice altceva: vrea sa foloseasca un NIC pt proxy si cu celalalr sa aiba conexiune la net (pt ssh sau rdp-uri probabil). Problema e ca nu ai decat o ruta default pt 0.0.0.0 pe sisteme simple. Ambele NIC-uri sunt in acelasi segment de ip, probabil.
Astept sa vad si eu ce zice unul mai inteligent ca fara alte componente de retea e greu de rezolvat asta.
Sigur se poate in cazul in care are doua interfete de retea. Raspberry Pi ruleaza Linux si deci se poate conecta si seta adresele de IP dupa cum are nevoie.
Probabil ca ar trebui sa mai activeze IP forwarding in cazul in care e deactivat din kernel.
Proxy functioneaza doar daca aplicatia/device-ul stie de protocolul proxy - in caz ca ai ceva ce nu se descurca cu proxy, e bine sa il pui in DMZ (pe partea de WAN/Internet). Un proxy e de fapt un router la nivel aplicatie.
Daca alegi proxy si vrei ssa il folosesit pt a separa consistent cele doua (sub) retele, nic0/nic1 ar trebui sa funtioneze cu IP din clase diferite astfel incat sa existe o separare clara. Daca vrei si filtrare, trebuie sa folosesti un demon care stie asta si deactivat ipforwarding.
Orice router DSL are 2 interfete: W(ide)AN si L(ocal)AN. Are NAT (care face rutare la nivel IP) pt a face ceva asemanator proxy-ului fara a intelege ce e inpachetat. Cam asta ar putea sa faca si PI-ul. Probabil ca interfata LAN va fi cea WIFI si WAN va fi cea cu cablu. Nu sunt convins ca proxy e ceea ce iti trebuie, dar fara sa expui cazul nu te pot ajuta.
Sigur se poate in cazul in care are doua interfete de retea. Raspberry Pi ruleaza Linux si deci se poate conecta si seta adresele de IP dupa cum are nevoie.
Probabil ca ar trebui sa mai activeze IP forwarding in cazul in care e deactivat din kernel.
nu sunt expert Linux si s-ar putea sa bat campii, dar mi se pare incredibil sa ai un sistem de operare simplu cum e Linuxul si careuia sa-i spui sa foloseasca ca default gateway pt internet un NIC dar pentru acelasi internet sa-l foloseasca al doilea NIC atunci cand are userul chef de internet nefiltrat de proxy.
Ca de aia instaleaza lumea proxy - pt securitate si filtrarea continutului.
Sau poate sub linux poti sa instalezi proxy-ul respectiv, cumva incapsulat impreuna cu NIC1 ca gateway default numai pt prxy, dar pt restul sistemului de operare si restul aplicatiilor e NIC2 default gateway. Se poate chestia asta sub Linux?
Data inscrierii: Jul 03, 2002 Locatie: Frankfurt am Main
Trimis: 12 11 2015, 8:46 Titlul subiectului:
cip_a a scris:
nu sunt expert Linux si s-ar putea sa bat campii, dar mi se pare incredibil sa ai un sistem de operare simplu cum e Linuxul si careuia sa-i spui sa foloseasca ca default gateway pt internet un NIC dar pentru acelasi internet sa-l foloseasca al doilea NIC atunci cand are userul chef de internet nefiltrat de proxy.
Ca de aia instaleaza lumea proxy - pt securitate si filtrarea continutului.
Sau poate sub linux poti sa instalezi proxy-ul respectiv, cumva incapsulat impreuna cu NIC1 ca gateway default numai pt prxy, dar pt restul sistemului de operare si restul aplicatiilor e NIC2 default gateway. Se poate chestia asta sub Linux?
Ceea ce descrii tu mai sus nu e o particularitate Linux ci e o chestie generica de networking.
Default GW-ul are scopul de a primi toate pachetele care nu se regasesc in routing table-u serverului respectiv. Daca exista o ruta de la definitul Default GW spre urmatorul network hop atunci pachetele vor fi routate catre urmaturul hop, daca nu - no route to host.
In cazul serverelor multi-home (cu mai mult de un eth) nu se recomanda in niciun caz ca cele doua (sau mai multe) eth-uri sa fie configurate cu adrese din acelasi subnet. Asta deoarece in acelasi subnet doar un singur eth poate sa transmita frames-urile "at a time" si celalalt (celelalte) trebuie sa astepte pana ce termina acel eth de transmis (secvential). De asemeni toate eth-urile vor primi toate broadcast-urile ceea ce va duce la un overhead significant pentru acel segment de retea.
Proxy-ul nu este un router ci ... un proxy. Adica termina o conexiune TCP si deschide o noua conexiune TCP "on the client's behalf".
Cu alte cuvinte daca sa zicem clientul face un request cu adresa de IP 192.168.1.10 si proxy-ul asculta pe sistemul multi-home pe adresele 192.168.1.1 si 192.168.2.1 (retele diferite) atunci proxyul va mentine doua conexiuni, una intre client si el si una intre el si destinatia finala a request-ului.
Daca te uiti cu un tcpdump la trafic vei vedea ca vor exista tot timpul doua conexiuni, una intre 192.168.1.10 si 192.168.1.1 si alta intre 192.168.2.1 si IP-ul lui www.yahoo.com (sa zicem).
In cazul in care vrei sa protejezi intranet-ul instalezi proxy-ul pe serverul multi-home (Raspberry Pi in cazul nostru) si nu activezi IP forwarding intre cele doua retele. In asa fel toti clienti din clasa de adrese "interne" (sa zicem 192.168.1.0/24) nu vor putea avea access direct la internet ci doar vor putea browsa prin proxy.
Nu mi-e clar insa daca Criffy doreste sa activeze si routing-ul sau doar sa foloseasca proxy-ul. Ideea e ca ambele variante sunt realizabile foarte simplu.
ckunst, sunt de acord cu tine dar ma refeream la alst scenariu. Nu ma refer la proxy-uri cu 2 NIC-uri (inside/dmz-outside) ci la un proxy simplu, pe un singur NIC pt in si out.
- server home in spatele unui router care stie de VLAN-e. ca nici eu nu vad ce sens are sa le folosesti in acelasi IP segment (sau sub aceeasi masca)
- serverul are 2 NIC-uri, NIC1 192.168.1.2, cu gateway .1 care e ori routerul ori gateway de la VLAN-ul respectiv
- NIC2 172.16.0.2 conectata la acelasi router in alt VLAN.
- ai o aplicatie proxy definita pe NIC1 si care deserveste clientii interni. Proxy-ul asculta requesturile clientilor de pe 192.168.1.X pe 8080 si le trimite spre internet (0.0.0.0)pe 80 (standard) prin acelasi NIC1.
- router/FW-ul are un singur IP extern sa zicem 99.77.66.55
- NIC2 il configuri pentru remote-access sau sistem de alarma, camere video etc.
- daca vrei sa accesezi serverul din afara prin NIC2 iti trebuie un NAT, dar avand un singur IP extern pe care il folosesti deja ca NAT pt proxy...deci cum poti sa conectezi al doilea NIC la internet (fara NAT dinamic sau 2 IP-uri externe)?
In plus, daca esti logat (fizic, la consola) si startezi un browser al serverului pe care ruleaza aplicatia de proxy ca sa ajungi la yahoo.com sistemul va intreba intai ruta spre internet (default gateway) care e NIC1. Prin NIC2 vei putea accesa default 172.16.0.0/0.0.255.255 plus orice alte rute le setezi tu manual. Daca setezi ca 0.0.0.0 sa treca prin NIC2, o sa crape proxy-ul, care nu stie ca NIC2 exista.
Technic e posibil, dar nu cu routere gen Fritz sau componente home edition.
- ai o aplicatie proxy definita pe NIC1 si care deserveste clientii interni. Proxy-ul asculta requesturile clientilor de pe 192.168.1.X pe 8080 si le trimite spre internet (0.0.0.0)pe 80 (standard) prin acelasi NIC1.
....
- daca vrei sa accesezi serverul din afara prin NIC2 iti trebuie un NAT, dar avand un singur IP extern pe care il folosesti deja ca NAT pt proxy...deci cum poti sa conectezi al doilea NIC la internet (fara NAT dinamic sau 2 IP-uri externe)?
In plus, daca esti logat (fizic, la consola) si startezi un browser al serverului pe care ruleaza aplicatia de proxy ca sa ajungi la yahoo.com sistemul va intreba intai ruta spre internet (default gateway) care e NIC1. Prin NIC2 vei putea accesa default 172.16.0.0/0.0.255.255 plus orice alte rute le setezi tu manual. Daca setezi ca 0.0.0.0 sa treca prin NIC2, o sa crape proxy-ul, care nu stie ca NIC2 exista.
Ai cam incurcat conceptele.
Proxy server nu face routing ci lucreaza la nivel aplicatie. El nu trimite mai departe req. pe portul 80, ci contacteaza serverul destinatie - asa cum il gaseste impachetat in proxy-request - de pe ce port gaseste liber (foarte probabil nu 80) si de pe stiva outbound
Intr-un final, HTTP-request e trimis de Proxy server in jos spre stiva outbound pe care o are configurata de unde e preluat de nivelul IP (singurul care face routarea) si care trimite la urmatorul hop conform cu tabela lui de routare.
Structura tabelei: Destination, (netmask), Gateway, Interface, Metric
Daca PI (unde ruleaza proxy-ul) are un entry 0.0.0.0 catre DSL router (de pe stiva IP outbound cu adresa respectiva), acolo va trimite toate request-urile care sunt preluate de NAT-ul de pe DSL-router si trimise mai departe in internet. Inapoi are grija NAT-ul sa le trimita la cel de la care au venit, respectiv proxy server cu interfata (stiva IP) corespunzatoare. De acolo e preluata de proxy server care re-impacheteaza HTTP-data in proxy-envelope si o trimite inapoi prin stiva IP inbound unde il are inregistrat pe client (ARP), stiva care care nu are nevoie de default gateway. Deci proxy-ul trimite packetul proxy direct (print stiva IP inbound) la clientul care ruleaza browser-ul.
arp -g pe PI arata tabela MAC<->IP cu toate computerele pe care le poate accesa direct.
Cam asa arata povestea dpdv al browser-ului:
Cod:
Proto Local Address Foreign Address State
TCP 10.132.1.5:49631 txpbdedcsu001:8090 FIN_WAIT_2
TCP 10.132.1.5:49654 proxyinternal:8080 TIME_WAIT
TCP 10.132.1.5:49656 txpbdedcsu001:8090 ESTABLISHED
TCP 10.132.1.5:49661 proxyinternal:8080 ESTABLISHED
TCP 10.132.1.5:49662 proxyinternal:8080 ESTABLISHED
TCP 10.132.1.5:49665 proxyinternal:8080 ESTABLISHED
Trebuie notat ca un program oarecare va accesa direct capabilitatile de retea ale computer-ului, deci pe computerul unde ruleaza browser-ul nu ar trebui pus ca default gateway router-ul DSL (daca se doreste filtrare totala) ci inbound IP de la proxy server (PI).
Browserul de internet se poate configura si asa va fi fortat sa foloseasca proxy server, care inseamna ca nu va incerca sa trimita http-SYN la destinatia finala ci un request proxy catre... serverul proxy.
P.S. imi ia mult prea mult timp sa traduc in romana toti termenii de retea... imi cer scuze pentru cocktail
ce cocepte incurcai ca eu nu ma simt vinovat? mai bine da un "route print" daca ai doua sau mai multe NIC-uri si ne apropiem de intrebare. Banuiesc ca ai si lan si wlan, daca tot esti intr-un loc cu adresa cu 10.
pe urma da un trace route catre yahoo.com si primul trace da-l prin lan si al doilea prin wlan, in TCP 4, fara sa dezactivezi ceva sau sa schimbi metric-ul.
daca nu merge yahoo.com, dns-ul lui gugal 8.8.8.8 ar trebui sa fie liber prin orice fw.
- ai o aplicatie proxy definita pe NIC1 si care deserveste clientii interni. Proxy-ul asculta requesturile clientilor de pe 192.168.1.X pe 8080 si le trimite spre internet (0.0.0.0)pe 80 (standard) prin acelasi NIC1.
Pachetul IP (care impacheteaza un SYN spre serverul HTTP extern, port 80) e rutat spre urmatorul "hop" de nivelul transport al stivei outbound. Portul e pe TCP si nu are legatura cu rutarea simpla (la nivel IP). Urmatorul hop, cata vreme nu e o ruta explicita, e default gateway adica DSL router. Proxy server are definit foarte clar ce stiva e accesata ca inbound si outbound. Iar default gateway are rost numai pe outbound.
apoi asta:
Citat:
daca vrei sa accesezi serverul din afara prin NIC2 iti trebuie un NAT, dar avand un singur IP extern pe care il folosesti deja ca NAT pt proxy...deci cum poti sa conectezi al doilea NIC la internet (fara NAT dinamic sau 2 IP-uri externe)?
Daca te referi la PI ca si proxy server (cu 2 stive IP care pot fi construite si pe o singura interfata fizica) si care e separat de router DSL, nu e problema proxy sa administreze NAT-ul.
NAT e facut la un nivel mai inalt fata de rutarea simpla si implica reconstruirea pachetelor IP cu recalcularea checksum pt ca va schimba adresa sursa (trimitere) si destinatie (receptie). Adica routerul DSL citeste destination and soruce IP din pachetul trimis de proxy si inlocuieste source address cu propria adresa externa (pe langa mentionata recalculare a checksum). Pt a putea re-transmite raspunsul server-ului inapoi la proxy, NAT (numit si port forwarding) mentine in mod evident o mapare.
Nu se poate expune un server intern din spatele proxy. Proxy-ul are o singura directie pt pachetele SYN: de pe inbound pe outbound.
Expunerea unui server intern (de ftp de exemplu) se face numai cu conectarea directa la DSL router care foloseste static NAT pt asta. Simplist, NAT mapping table permanenta are asa ceva: ExternalIP:portX -> InternalIP:portY. Adica SYN receptionat de DSL pe WAN portul X este redirectat pe partea LAN pe portul Y.
Proxy nu retrimite pachetele SYN decat in directia inversa.
Nu a disparut din contextul discutat de mine. Crify ne-a lasat in ceata cu ceea ce vrea sa faca, furnizand numai cum are vrea sa o faca.
Si da, am uitat sa discut aceasta ameteala numita Virtual LAN. V-LAN inseamna asignarea de broadcasting domain si nu prea are de-a face cu tema discutata. Avantajul major e reducerea confestiei specifice CDMA-CD (i.e. tehnologia ethernet). Nu are legatura NAT sau proxy si nici nu e nevoie de asa ceva.
proxiul se poate configura in 'jde scenarii, la fel ca si un ftp/sftp server, pe care il poti pune in fundu' inside-ului si tot sa ramana facing internet.
dar tu tot nu-mi raspunsasi la problema cu trace route, cum faci pachetele sa treaca catre 0.0.0.0 prin NIC1 si pe urma prin NIC2, fara sa modifici metricul, in tcp 4.
Nu voi sa stiu de stack-uri, syn, eigrp-uri si alte alea.
dragos, te rog, pentru linistea mea, nu-mi explica cum functioneaza retelele si standardele. ma enerveaza. Lucrez de 25 de ani cu asa ceva si pana in 2010 am avut o groaza de certificari de retea, obtinute corect.
daca poti sa raspunzi simplu la o intrebare simpla - e ok.
0. Nu (mai) vreau sa enervez pe nimeni (ca doar nu am imbatranit de pomana). Sper sa imi si reuseasca si imi cer scuze pt cand nu-mi iese...
traceroute (tracert in win) lucreaza la nivel IP (rutare chioara). Raspunsul la intrebarea ta e ca nu e nevoie sa fiu conectat la nivel IP cu clientul-browser - explicatia mai jos.
Nu am (la birou) exact configuratia respectiva (adica nu am acces la OS care ruleaza proxy, deci nu pot sa-ti dau tracert de acolo.
Nu am nici un fel de certificari. Daor ca am inteles inca din facultate cum functioneaza TCP/IP in amanunt si am folosit asta relativ intensiv in ultimii 20 de ani.
TCP connection (deci orice server ftp/http/etc) functioneaza numai cu 3-way-handshake. Asta inseamna ca un request initial (spre portul 80) incepe cu un pachet TCP SYN.
Astea fiind spuse,
Asadar, avem CLIENT cu IP=C, PI(=proxy) cu IP pe stiva inbound P si IP pe stiva outbound (sau DMZ) O, routerul DSL cu IP-local L si IP-WAN W si in cele din urma un server FTP cu IP F.
Pachetul TCP SYN e initiat de broserul cleintului cu IP C catre yahoo.com:80 si impachetat in protocol proxy care e rutat de nivelul IP direct catre P pe portul 8080.
Proxy server proceseaza req http din proxy pachet si vede http req. SYN[Src:C Dest:yahoo.com:80] pe care-l scoate (forțat de configurație către outbound) prin O sub forma de req SYN[Src:O Dest:yahoo.com:80].
Stiva de pe O rezolva (are ca DNS pe L) mai întâi yahoo.com cu adresa Y și trimite req SYN[Src:O Dest:Y:80] către următorul hop. Hop-ul următor e L (DSL intern) pt ca in tabela de rutare de pe PI e un singur default gateway (significat de destinația de broadcast 0.0.0.0 ) pe stiva O, cealaltă interfață evident ca va comunica numai cu clasa de IP (subnet) proprie (unde e numai clientul C).
DSL proceseaza cu NAT si trimite (prin interfata/stiva W) req SYN[Src:W Dst Y:80]
Răspunsul vine ca si SYN-ACK[Src:Y Dst:W] si e preluat de NAT care face drop daca nu il gaseste in tabela de mapare.
NAT reconstruiește (pe baza mapării dinamice interne) in SYN-ACK[Src:Y Dst:O] care ajunge la proxy (evident pe O).
Proxy pe baza tabelei dinamice interne trimite raspunsul - prin P, pt ca asa e configurat si oricum aia e cea mai scurta cale - inapoi la client.
Pe windows nu am ping, numai DNS (de care de fapt browser-ul nu are nevoie).
Browser impacheteaza http req. in proxy req. catre proxy server, deci nu are nevoie de conectivitate IP - asta e delegata proxy-ului care astfel poate controla foarte bine ce adrese si ce porturi TCP sunt accesate.
Cu Process Explorer poti vedea la tab-ul TCP/IP pe procesul Firefox ca singura conexiune e cu proxy:8080. Alternativ poti volosi nestat -p tcp -b (cu drepturi de admin).
Asa se explica ce vezi mai jos, desi eu sunt conectat la ro-de.org.
Tracing route to yahoo.com [206.190.36.45]
over a maximum of 30 hops:
1 2 ms 3 ms 4 ms 10.132.0.1
2 6 ms 6 ms 35 ms 172.27.100.156
3 6 ms * 6 ms 10.100.11.102
4 6 ms 6 ms 6 ms 10.100.11.101
5 6 ms * 6 ms 10.100.11.102
6 7 ms 6 ms 6 ms 10.100.11.101
7 6 ms * 6 ms 10.100.11.102
8 7 ms 7 ms 6 ms 10.100.11.101
.......
>ping yahoo.com
Pinging yahoo.com [206.190.36.45] with 32 bytes of data:
Reply from 10.100.11.101: TTL expired in transit.
Reply from 10.100.11.101: TTL expired in transit.
Reply from 10.100.11.101: TTL expired in transit.
Reply from 10.100.11.101: TTL expired in transit.
Acum sa vedem cum facem cu un server FTP in spatele DSL router.
Presupunand ca NAT e configurat cu o mapare statica (W:80->P:80), va trimite SYN[Src:ClientDinInternet Dest:W:80] catre proxy prin L ca SYN[Src:CleintInterner Dest:P:80], care va refuza asa ceva pt ca nu are o destinatie pt el. Iar DSL router nu are ruta catre subnet-ul unde e clientul C (acum pe post de server http).
De aceea, un astfel de server trebuie sa aiba acces direct la DSL router, adica trebuie plasat in acest pseudo-DMZ.
Nu poti crea un subiect nou in acest forum Nu poti raspunde in subiectele acestui forum Nu poti modifica mesajele proprii din acest forum Nu poti sterge mesajele proprii din acest forum Nu poti vota in chestionarele din acest forum
Nu raspundem pentru continutul mesajelor si comentariilor din forum si cele atasate articolelor. Acestea apartin in intregime utilizatorilor siteului si sunt proprietatea acestora. Stirile si marcile inregistrate apartinand diverselor companii care apar pe site sunt proprietatea acestora, prin postarea comentariilor/mesajelor acordand dreptul de folosire in scop public a informatiilor publicate. Materialele si informatiile preluate partial din alte jurnale si ziare sunt proprietatea acestora, iar daca citarea lor aduce lezarea intereselor respectivilor vor fi eliminate la cerere de pe site, daca aceasta cerere este indreptatita.
FAQ
Cautare
Mesaje private
Adica termina o conexiune TCP si deschide o noua conexiune TCP "on the client's behalf".
