VNC pres NAT, teoreticky ANO, jak je to v praxi? - Kompletni popsani problemu

[Vlada Macek]

[Autor citovane zpravy: Dominik Škoda, cas odeslani: 20.08.2004 12:44]

> Dobra, napisu to tu kopletne snad srozumitelne:
>
> Jsem za NAT mam vnitrni IP, na NAT (router) nemam zadny pristup. ISP
> mi v tomto smeru nevyjde vstric. Mam nejakou moznost jak se *z
> venci/internetu* pripojit *na to PC za NATem*? IMHO ja myslim, ze ne.

V tom se mylite, moznosti je nepreberne. Pokud nebereme v uvahu chybu
firewallu nebo v NATovadla, tak to ale vzdy zahrnuje nutnost "pomoci
tomu zevnitr". To se tu uz psalo mnohokrat, mam ale dojem, ze i kdyz vam
lidi natukli, stejne vas to nedonutilo si o tom neco nastudovat vic. Na
vsech konferencich na svete se vam vetsinou nedostane nic vic nez
pocatecni natuknuti... s tim se musi zit.

Proste pokud mate jakykoli pristup do vnitrni chranene site (treba
fyzicky), mate obvykle tu moc, ze muzete selektivne proborit jeji
ochranu (povazujeme-li NAT za ochranu, je to sporne). Dostatecnym
prostredkem pro TCP protokol je obycejné ssh, nesmi to mit ale zakazano
a musi se mit kam pripojit zevnitr te chranene site.

man sshd_config:

     AllowTcpForwarding
             Specifies whether TCP forwarding is permitted.  The default is
             ``yes''.  Note that disabling TCP forwarding does not improve
             security unless users are also denied shell access, as they can
             always install their own forwarders.

     GatewayPorts
             Specifies whether remote hosts are allowed to connect to ports
             forwarded for the client.  By default, sshd binds remote port
             forwardings to the loopback address.  This prevents other
remote
             hosts from connecting to forwarded ports.  GatewayPorts can be
             used to specify that sshd should bind remote port
forwardings to
             the wildcard address, thus allowing remote hosts to connect to
             forwarded ports.  The argument must be ``yes'' or ``no''.  The
             default is ``no''.

> Ale uz mi tu několik lidi navrhovalo reseni:

> 1) tunel přes IPv6 od Dana Dan Ohnesorga

To je zrejme reseni, v dnesni dobe ale bohuzel stale nestandardni a pracne.

> 2) potom jsem sam navrhoval něco jako "VNC proxy" nekde na netu,
> která by zajistovala komunikaci, ale to asi neexistuje

Nechapu, proc sem stale pletete VNC, kdyz se ptate na obecnou sitarinu.
Asi jsem prehledl, jestli jste psal, proc to vlastne cele chcete delat.
Predpokladam tedy, ze vas nezajima nic jineho, nez se pres VNC dostat na
nejaky vnitrni pocitac.

> 3) potom tu je nejake reseni od Lubora Kaciana: ssh -R
> 5900:<IP-adresa-PC-v-praci>:5900 IP_mojho-PC-DOMA BTW:je to nejake
> zmatene, takze please ještě dovysvetlit.

man ssh!

     -R port:host:hostport
             Specifies that the given port on the remote (server) host is to
             be forwarded to the given host and port on the local side. 
This
             works by allocating a socket to listen to port on the remote
             side, and whenever a connection is made to this port, the
connec-
             tion is forwarded over the secure channel, and a connection is
             made to host port hostport from the local machine.  Port
forward-
             ings can also be specified in the configuration file. 
Privileged
             ports can be forwarded only when logging in as root on the
remote
             machine.  IPv6 addresses can be specified with an alternative
             syntax: port/host/hostport

5) VPN, napr. OpenVPN, ktere je velmi jednoduche na konfiguraci a bezi
po jedinem portu. To uz jsem v tomto vlaknu neprimo zminoval drive.
Jedna-li se o reseni, ktere ma byt stabilni a soucasti legalni
infrastruktury site, pak staticky VPN tunel je podle me reseni nejcistsi.

VM

------------- další část ---------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <http://www.linux.cz/pipermail/linux/attachments/20040820/16da38d2/attachment.sig>