HTTP-proxy, SSH-tunnel of VPN: kies de juste laach

Freegje trije yngenieurs hoe't se by in ynterne tsjinst komme en do krijst trije ûntwerpen: in webproxy, in SSH-tunnel of in folsleine VPN. Alle trije kinne in tsjinst op ôfstân berikber meitsje, en alle trije kinne ferkear lykje litte as komt it fan earne oars. De ferskillen komme letter oan it ljocht, as it brûkte protokol net dat is dat it keazen ark ferûnderstelt. In ûntwerp dat in flugge browserkontrôle trochstiet, mislearret geregeld op de applikaasje dy't it fersyk feroarsake.

Beslis út twa feiten: hokker protokollen moatte passearje, en wa kin de belutsen nammen resolvje. Al it oare is foarkar.

In proxy ferpleatst allinnich wat er begrypt

In webproxy parselet it protokol dêr't er foar boud is. De kliïnt jout him in fersyk en hy jout dat fersyk fierder, sadat in applikaasje sûnder proxy-ynstelling hielendal net meidocht. Foar HTTPS hat de kliïnt in ûntrochsichtich kanaal nedich, dat de proxy fia CONNECT leveret yn plak fan it fersyk te lêzen.

In dynamyske SSH-oerstjoering iepenet in lokale poarte dy't SOCKS praat, en dy poarte stjoert in TCP-stream troch nei hokker bestimming de kliïnt ek neamt. Protokollen boud op TCP wurkje der oer it algemien troch. UDP net, útsein as in ark stipe eksplisyt tafoeget. In lokale oerstjoering is noch smeller: ien lokale poarte keppele oan ien fêste host en poarte, wat ien bekende tsjinst betsjinnet en neat mear.

ssh -D 1080 user@bastion
ssh -L 8443:fileserver.internal:443 user@bastion

In VPN ferpleatst pakketten. Alles wat de kliïnt de tunnel yn rjochtet, giet der trochhinne, UDP en ICMP ynbegrepen, dêrom past it by in netwurkferplichting en net by ien ferbining.

Immen moat de namme resolvje

As de namme fan it doel allinnich yn de DNS fan it netwurk op ôfstân bestiet, moat de masine dy't it sykjen docht dy sône sjen kinne. In webproxy docht it sykjen sels, sadat in ynterne namme der troch wurket sels as de laptop de namme hielendal net resolvje kin. SOCKS kin him itselde gedrage, mar allinnich as de kliïnt de namme trochstjoert yn plak fan te ferbinen mei in adres dat er al resolvt hat. Dy kar leit by de kliïnt, net by de tsjinner.

curl lit de skieding dúdlik sjen: ien flagge jout de hostnamme oan de proxy, in oare resolvt dy earst lokaal. By lokale resolúsje mislearret in namme dy't allinnich yntern is foardat hokker tunnel dan ek oanrekke wurdt, en de flater jout de proxy de skuld fan wat eins in DNS-beslissing wie.

In VPN nimt de tredde wei troch de partikuliere resolver en it sykdomein njonken de rûtes te ynstallearjen. Dat is handich, en it makket in fertroude yllúzje: in rûte dy't bestiet mei in resolver dy't net antwurdet liket krekt op in deade tunnel, ek al berikke pakketten de oare kant.

As it netwurk mar ien útgong tastean

In protte bedriuwsnetwurken tastean útgeande ferbiningen allinnich fia in autentisearre webproxy. OpenVPN en SSH kinne beide dêr wurkje: de earste troch syn eigen transport troch de proxy te tunneljen en de twadde troch in proxy-opdracht dy't in lytse CONNECT-helpers draait.

Tunnels boud op TCP oerlibje dy beheining, en in VPN op UDP-basis net, wat in protte konfiguraasjes ferklearret dy't thús wurkje en op kantoar mislearje. In twadde priis is maklik te missen: in TCP-tunnel droegen yn in TCP-ferbining fia in proxy hat no twa lagen dy't opnij stjoere, en ûnder ferlies rint dat pear fêst op in manier dy't gjin inkele laach allinnich makket.

Intermediêrs keatlingje is in oare fraach as in laach kieze. In twadde proxy of Tor tafoegje feroaret wa't wat observearret, en de posysje yn 'e keatling beslút hokker hop de syfertekst sjocht.

Oarder is wichtiger as it oantal hops. In bûtenhop sjocht in fersifere stream wylst in binnenhop de iepen tekst sjocht dy't er draacht, dus in keatling is mar sa privee as syn minst soarchfâldige skeakel. Protokollen oer hops minge ferbetteret dat net automatysk. It makket benammen de flatermodi dreger om oer te riddenearjen.

In ferfalske adres is net ien fan de opsjes

Pakketten meitsje mei it boarne-adres fan immen oars berikt neat nuttichs: antwurden reizgje nei de echte eigner, en de measte netwurken smite it ferkear gewoan fuort. In intermediêr is krekt nedich om't de boarne net betocht wurde kin, en dat is de earlike rjochtfeardiging foar alle trije ûntwerpen.

It beheint ek wat elk fan harren beweare mei. Lykje as kaam it fan in beskaat adres is in fraach oer wêr't dat adres legaal tawiisd is en wa't it routearje mei, net oer hokker ark in kop ferfalskje kin. As in ûntwerp oars ferûnderstelt, mislearret de oanname by de earste oanbieder dy't it filteret. Skriuw de oanname op sadat de flater werkenber is as er komt.

Beslis op protokollen en nammen

Kies in proxy as ien webkliïnt ien weptsjinst nedich hat en proxy-ynstellingen hat. Kies in SSH-tunnel as in hânfol bekende TCP-tsjinsten genôch is en SSH tagong al bestiet. Kies in VPN as ferskate applikaasjes, net-TCP-ferkear, partikuliere DNS of in werbrûkber paad part fan 'e ferplichting binne.

Ferifiearje dan mei de echte kliïnt en de echte namme. In side lade fia in proxy leart dy neat oer UDP, en ien ark oer SOCKS wurkje litte leart dy neat oer de systeemresolver. Lês hokker lokaal adres it proses bûn hat en hokker resolver antwurde. Dat is it ferskil tusken in paad dat wurket en ien dat ien kear tafallich wurke hat.