Dotaz: Jak přes NAT

[t3mpu5]

Dobrý den, chtěl bych se zeptat, jak by se dal vyřešit tento problém: Mám dva PC, oba dva za NATem, každý v síti jiného poskytovatele, na jedom WinXP na druhém Kubuntu. Tedy asi takto:

PC-WinXP----NAT_01--...--internet--...--NAT_02----PC-Kubuntu

. Potřeboval bych tedy vytvořit stabilní spojení mezi těmito počítači. Když jsem hledal, narazil jsem na program nat-traverse, je to program psaný v perlu. Překompiloval jsem ho tedy do *.exe kvůli spuštění pod windows (nemůžu si dovolit spouštět přímo perlový skript, protože PC-WinXP se mění, a tak bych nemohl na každý nahazovat perl. Zkompilovaný program se zdá, že funguje (tedy soudě podle toho, že kompilace nevyhodila žádnou chybu a program nabídne nápovědu k parametrům apod, víc se mi ho věrohodně odzkoušet zatím nepovedlo)(Kompiloval jsem ho programem ActiveState Perl Dev Kit 7.0 Deployment resp. programem PerlApp.exe, jež byl jeho součástí., pokud byste si chtěli ověřit, zda je dobře nakompilovaný, "exáč" je tady http://uloz.to/181333/nat-traverse.exe)

Když se pak snažím vytvořit stabilní spojení mezi těmito PC podle tohoto článku na rootu (http://www.root.cz/clanky/prelez-preskoc-a-podlez-nat/) spojení skončí hláškou:

> Creating socket localhost:PORT <-> IP:PORT... done.

> Sending 10 initial packets... .......... done.

> Waiting for ACK (timeout: 10s)... .Couldn't read from socket: Unknown error

Napadá Vás, jak by se to dalo vyřešit, popř. jak ověřit, že tento je opravdu dobře zkompilovaný a chyba není v něm (BTW pogram je v příloze)? Popř. znáte nějaký jiný program? Děkuji.

PS. Myslíte, že by to zjednodušilo problém, kdybych měl namapované nějaké porty z NAT-01 na PC-WinXP (to je totiž jediné, jak bych to teoreticky mohl zjednodušit, přístup k NAT-01 nemám, takže o namapování na tento můžu požádat admina, ale to je jediné zjednodušení, které mě napadá, jinak obecně nemám přístup na žádný z těch NATů)

Odpovědi

[Filip Jirsák]

Pokud můžete z NAT-01 namapovat nějaké porty na PC za ním, máte vyhráno. Nechte si nějaký port namapovat, na tom PC s WinXP rozběhněte nějaký SSH server (můžete zkusit třeba SSHWindows – ale jenom jsem to našel přes Google, osobní zkušenost s tím nemám), a z druhého PC už můžete navázat ssh spojení a vytvořit si tunel.

[michal]

možná je to hloupost, ale zkoušel jsi program hamachi? Vytvoří to virtuální LAN síť přes internet a existuje jak win verze, tak linux (hamachi, quamachi). Jenom si nejsem jistý jaký práva to potřebuje na tom XP (jestli nebudeš potřebovat admin práva)

[t3mpu5]

... a z druhého PC už můžete navázat ssh spojení a vytvořit si tunel.

Jak z PC-WINXP navázat ssh spojení vím, ale jak vytvořit tunel to už ne . Na Winech používám program FreeSSHd, šlape mi dobře, ale asi jsem to napsal špatně, trochu to tedy pozměním: mám možnost napamovat porty z NAT-02 na PC-Kubuntu, ze kterého by se mělo ve většině případů přistupovat na PC-WinXP schované za NAT-01. Snažím si napsat nějaký takový skript aby byl se dal spustit na Winu, který by mi vytvořil po spuštění na PC-WINXP stabilní spojení s PC-Kubuntu, ze kterého bych pak na něj přistupoval. Skript si volá nějaké systémové programy, a vytvoří server, který naslouchá na určitém portu na příchozí spojení. Jenže zatím funguje pouze na PC s veřejnou IP a to se mi pro moje potřeby, kdy potřebuju přistupovat na oba PC z nichž jsou oba dva schované za natem nehodí. (i když ve skutečnosti ten, ze kterého nejčastěji přistupuju (PC-Kubuntu) může mít namapované nějaké porty na svůj NAT-02). Tak jsem do toho skriptu chtěl napsat, aby si pro vytvoření serveru čekajícího na spojení vyvolal ten nat-traverse, který by přesměroval pakety z NAT-01 na PC-WinXP do toho otevřeného terminálu, jenže s tím mi to nějak nejede (nevím jestli špatnou kompilací perlového skriptu do .exe, nebo špatným užitím příkazů). V každém případě, pokud byste věděli o jiném programu než nat-traverse, který se dá volat z shellu (bez GUI) k vytvoření stabilního spojení mezi dvěma PC schovanými za NATem, byl bych moc rád. Děkuji.

[Filip Jirsák]

Z Linuxu můžete navázat ssh spojení i přesměrování portů příkazem ssh, na Windows k obojímu můžete použít Putty. Pokud můžete spojení navázat jen z jedné strany, ale potřebujete jej přístupný kdykoli, nechte jej aktivní pořád.

Pokud můžete namapovat nějaké porty na PC Linuxem, namapujte si port 22 nebo nějaký jiný na sshd na Linuxu. Pak na Windows spustíte PuTTY nebo Plink ze skriptu, čímž si buď nastavíte přesměrování portů (buď lokálních, nebo ze serveru), nebo tam můžete rovnou udělat Socks5 proxy.

[t3mpu5]

Moc děkuji. Zkoušel jsem ten plink, ale asi něco zadávám špatně, nebo tomu pořádně nerozumím. Dejme tomu, že situace bude vypadat takto:

[PC-01_xxx.xxx.xxx.xxx:p01]-----[p02:NAT-01_yyy.yyy.yyy.yyy:p03]-----...inte-

rnet...-----[p04:NAT-02_zzz.zzz.zzz.zzz:p05]-----[p06:PC-02_qqq.qqq.qqq.qqq]

A když bude chtít třeba strýc sedící u [PC-01:xxx.xxx.xxx.xxx] něco spravit, tak já mu pošlu ten svůj skript, ten by na něj poklikal, a skript by mu třeba spustil netcat naslouchající třeba na p11. portu jeho mašiny. A teď by měl ten plink (jestli jsem vůbec pochopil jeho funkci) vytvořit stabilní spojení, mezi PC-02 přes NAT-02 do internetu pak na NAT-01 a ten ho přesměruje na naslouchající terminál netcatu na [PC-01_xxx.xxx.xxx.xxx:11]. Pak bych si tedy otevřel putty k připojení na ten terminál naslouchajícího netcatu.

Ten plink spouštím já na svém PC-02, nebo ho mám zabudovat do toho skriptu, aby se spouštěl zároveň se naslouchajícím netcatem na strejdově PC-01?. Jak by pak měla vypadat syntaxe toho plinku?

Děkuji.

[Filip Jirsák]

Moc se nevyznám v tom, co je PC-01, p02 a kde kdo sedí… Po píšu to obecně. Tam, kd máte možnost přesměrování portu z NATu na vaše PC budete mít sshd nebo jiný ssh server. Na druhé straně je ssh klient – např. ssh z OpenSSH (pokud jde o Linux), nebo Plink/PuTTY, pokud jde o Windows. Spojení navazujete vždy z klienta (tedy ssh nebo Plink). Spojením můžete zároveň přesměrovat port – buď lokální, nebo vzdálený.

Přesměrování lokálního portu znamená, že tam, kde je klient, se otevře pro naslouchání port, dejme tomu 8080. Určíte, že se má přesměrovat třeba na www.google.com:80. Když se teď na lokálním počítači připojíte na localhost:8080, pakety projdou tunelem vytvořeným ssh/Plinkem, a ze serveru se normálně odešlou na www.google.com:80. Odpověď se pošle tunelem zase zpátky.

Přesměrování vzdáleného portu funguje opačně – port k naslouchání se otevře na serveru, a komunikace je přesměrována na klienta.

Pokud byste chtěl přesměrovávat něco jiného, než tcp, nebo chtěl těch spojení navazovat hodně, bude lepší OpenVPN.

Pokud tedy PC, kde máte přesměrování portu z NATu a sshd server je vaše, a potřebujete se dostat na strýcovo PC, pustí Plink strýc, tam bude mít nastaveno přesměrování portu např. 3389 na jeho PC na port 3389, a když vy se připojíte na serveru na port 3389, připojíte se na strýcovo PC na port 3389.

[t3mpu5]

Nějak se mi to nedaří ... Můžu se zeptat, jak by pak měla vypadat syntaxe příkazu plink pro tento účel, kterou by měl strejda spouštět na PC?

[Filip Jirsák]

Např.

plink -N -R 3389:localhost:3389 user@server.example.com

Přesměruje port 3389 na vzdáleném serveru na port 3389 na lokálním počítači (port 3389 je, jestli se nepletu, Remote Desktop Protokol, takže vhodný pro přenos GUI). Pokud byste se chtěl připojovat na ssh server na strýcově PC, bylo by to asi -R 2222:localhost:22 – připojil byste se na port 2222 na vzdáleném serveru, a protunelovalo by vás to na port 22 na strýcově PC.

[t3mpu5]

Paráda, moc děkuju. Teď mám zrovna mimo provoz notebook, tak to v tuto chvíli nemůžu vyzkoušet, ale raději se ujistím: vzdálený server - server.example.com - je můj NAT, ze kterého mám namapované porty na sebe a user je přihlašovací jméno na můj třeba ssh server, který naslouchá na jednom z těch namapovaných portů, ju?

Dejme třeba tomu, že strejdovi bude naslouchat netcat s otevřeným příkazovým řádkem na portu 4001 na příchozí spojení a já mám z mého NATu namapovaný port 5003 na sebe, kde bude naslouchat třeba ssh server kde má účet uzivatel Pokus.

Pak si tedy strejda spustí plink v tomto tvaru:

plink -N -R 5003:localhost:4001 pokus@IP-MEHO-NATU

a strejdu to pak zjevně požádá o heslo uživatele pokus

Až ho zadá tak já bych pak spustil třeba

telnet IP-MEHO-NATU 5003

a to by mě přesměrovalo na strejdovo pc za jeho natem, kde mu naslouchá netcat na portu 4001

Nebo to chápu úplně blbě? *UNSURE* Jestli ano, děkuji za trpělivost.

[Filip Jirsák]

Ano, je to tak, až na jeden detail – na straně toho NATu potřebujete dva porty – jeden, na kterém bude naslouchat sshd server a na který se připojí strýc (ve vašem případě by to byl port 22, protože v řádku s plinkem nemáte žádný port uvedený, použije se tedy default). Druhý port je ten 5003, který budete mít jenom rezervovaný, a naslouchat na něm začne „něco“ až v okamžiku, kdy strýc spustí ten příkaz a připojí se na server. Ten druhý port ale nemusíte mít převedený skrz NAT, „tunel“ může naslouchat na localhost:5003 (před prvním portem u plinku lze uvést i IP adresu), vy byste se pak připojil sshčkem také na ten server a na něm byste se připojil už lokálně telnetem na localhost:5003

[t3mpu5]

Takže malý upgrade:

strejda zadá:

plink IP-MEHO-NATU -ssh -p6005 -l pokus -pw heslo-k-uctu-pokus -R MOJE-INTERNI-IP:5003:localhost:4001

a já zadám

ssh -p 6005 pokus@MOJE-INTERNI-IP

a v takto přihlášeném terminálu:

telnet localhost 5003

kde z mého natu musím mít určitě namapovaný port 6005, ale 5003 už může být libovolný. Ano?

[Filip Jirsák]

Ano, myslím, že by to takhle mělo fungovat.

[t3mpu5]

Super. Moc děkuji za trpělivost se mnou. Pokusím se to co nejdřív vyzkoušet. Ještě jednou díky.

[t3mpu5]

Tak to jede. Požádal jsem kamaráda, co je na linuxu s veřejnou IP, aby hrál "moji roli" (což myslím, pokud mám namapované porty z našeho NATu bude později, až se budu připojovat já na strejdu, to samé, ssh nechám běžet na namapovaném portu) a já jako osoba za natem jsem si spustil takto ten plink a netcat k naslouchání a perfekt. Fungovalo to, kamarád se "protuneloval" až ke mně. Tak super. Moc Vám (všem) děkuji za pomoc.

[t3mpu5]

Dobrý den, tak jsem to zatím zkoušel jen s kamarády a funguje to, ale jenom z části. Pokud má ten SSH server, na který se plink připojuje veřejnou IP, pak vše jede v pořádku. Pokud je ale za NATem jako ten můj a má přitom na sebe namapované porty, tak plink se na ten ssh server připojí, nicméně k přesměrování vzdáleného portu nedojde a to i když všechny porty použité v příkazech (viz výše) jsou namapované z mého NATu - soudě podle toho, že když se plink připojí na můj ssh server a já se na něj lokálně připojím také a pak v něm zadám nc localhost port (popř. telnet localhost port), tak tento příkaz zůstane bez odezvy (v případě nc) nebo s hláškou, že se nepodařilo spojit na daném portu (telnet). Z PC s veřejnou IP (os lnx) to jede, ale protože mám notebook v servisu, tak zatím ssh servery za natem, na které se plink připojoval jely jen na windows. Napadá Vás, kde by mohl být problém? Děkuji.

[vodic]

V tom ptipade tam evidentne mate nejakou chybu v uvaze :) Ja bych to zkusil debugovat tak, ze bych si na obou stranach spustil wireshark a pak se pokusil spojit. Tam pak uvidite, jestli vice zaNatovana strana opravdu pouziva jen ty presmerovane porty nebo jestli jste v necem neudelal chybu a nektera spojeni se nesnazite delat jinudy. Take na sshd strane uvidite, jestli pakety dorazily a jestli je treba nezahazujete az tam kvuli spatne konfiguraci.

[Filip Jirsák]

Vypište si na vzdáleném serveru netstat -nlt, abyste viděl, zda na serveru vznikla naslouchající strana tunelu. Pokud ne, je problém tam, pokud ano, je problém v tom, že se není kam připojit na klientovi s plinkem – tunel asi nekončí v nějakém naslouchajícím portu, ale „nikde“.

[t3mpu5]

Užití toho skriptu by mělo být asi takové: Např. Jsem doma na PC-Kubuntu za NAT-02 a strejda mi napíše, že mu něco nejede na PC. Tak místo toho, abych mu vysvětloval, kde najít jaký ssh server pro winy, jak ho nakonfigurovat a spustit, tak bych mu poslal ten svůj skrip, on by na něj poklikal a tím by vytvoři stabilní spojení mezi mnou a sebou na PC-WinXP za NAT-01 naslouchající s otevřeným terminálem na nějakém portu, na který bych se už pak připojil. Skript už mám vcelku napsaný, jen jak jsem psal, funguje na PC s veřejnou IP a to bych právě potřeboval nějak pořešit a jediné, na co jsem zatím přišel, byl právě ten perlový nat-traverse, který jede asi jen pod linuxem.

[t3mpu5]

Možná by se to dalo ošéfovat vědomým užitím nějakého méně známého trojana, jenže to mi v otázce bezpečnosti nepřijde moc vhodné a navíc nevím, jestli by se na něj dalo přistupovat z lnx.

[hafieror]

Nečetl jsem to úplně podrobně, ale pokud máte možnost si přesměrovat port na straně PC-Kubuntu, tak si rozjeďte openvpn.

[pavel]

Strýc spustí tento skript:

#!/bin/bash
#Pokud to chces bez hesla, pouzij prihlasovani pomoci klicu
xterm -e\
'ssh tvoje_jmeno@tvuj_nat2:presmerovany_port -R5000:localhost:22'

Ty na svém počítači:

ssh -p 5000 localhost

[pavel]

Nebo zkus HAMACHI, nebo TeamViewer. TeamViewer je pro Win, ale pěkně funguje i pod WINE.

[t3mpu5]

Nevím, jestli chcu něco co vlastně ani nejde, ale řešil jsem tento problém. Sem tam mi někdo řekne, že má nějaký problém na PC a nejlépší řešení by většinou bylo přihlásit se do příkazového řádku daného uživatele, spravit to a hotovo. Protože by bylo na dlouho říkat tomu dotyčnému, kde stáhnout jaký ssh server, jak ho nakonfigurovat, požádat ho o heslo k přístupu, popř. dělat to samé přes vzdálenou plochu, tak jsem si řekl, že bych si napsal nějaký DOSový skript, ke kterému by byly přiložené nějaké shellové programy, které by si podle potřeby tahal. Tyto programy by měly mít i své "linuxové dvojče", protože jsem střídavě na obou systémech. Zatím jsem takový skript napsal, ale funguje jen v interní síti, kde každé pc "vidí" přímo na druhé. Základem toho skriptu je program netcat, který si volá. Tento program spuštěný s parametry "nc.exe -L -pPORT -d -e cmd.exe" začne poslouchat na zadaném portu a když se k němu připojíte nějakým klientem např. telnet IP PORT, tak vám předá shell právě přihlášeného uživatele. Vše jde bez hesla, zkrátka dotyčný poklepe na ten skript a já se vzápětí připojím na otevřený terminál jím vytvořený. Problém ale samozřejmě nastal, když se jeden nebo oba z daných PC dostaly ven z interní sítě. Nejjednoduší by tedy asi bylo, zeptat se dotyčného na externí a interní IP a spustit nějaký program, který snad vytvořil ?tunel?, kterým by mě "přenesl" z mojí interní ip přes moji externí a jeho externí až k jeho interní ip a tam by se připojil právě na ten naslouchající netcat. Pravda, že to bez hesla všechno není zrovna asi nejbezpečnější, ale na "tu chvíli". Pokud by existovalo nějaké lepší řešení a hlavně časově vědomostně nenáročné pro dotyčné uživatele, nebo alespoň nějaké, kde by se mohli vyhnout instalování a konfigurování nějakého serveru, ke kterému bych se připojilv a zároveň se též vyhnout sdělování si přístupových hesel do systému, byla by to paráda.

[Josef Kufner]

Nejjednodušší by bylo rozběhat si někde openvpn server a nechat tam všechny lidičky permanentně připojené. Je to bezpečné a všichni se uvidí i kdyby za sedmero naty byli.

[xxl]

Inspirujte se zde http://en.wikipedia.org/wiki/UDP_hole_punching

[t3mpu5]

Jestli jsem tomu porozuměl, tak klienti A a B pošlou pakety serveru se veřejnou IP, ten si zapamatuje odkud a z jakého portu přišli a předá je protistraně. Něco trochu podobného jsem zkoušel přes nat-traverse, jen s tím rozdílem, že to nejde přes třetí stranu, A pošle něco na nat B a ten to zahodí, protože se nejedná o probíhající komunikaci. Ve stejnou chvíli také B vyšle paktety na nat A, ale ten už se domnívá, že jde o odpověď z natu B a tak ji předá klientovi A a ten zase pošle nějaké pakety na nat B, který už si také myslí, že jde o odpověď z předchozí komunikace, tak je předá klientovi B za svým natem. Jen mě pořádně nenapadá jak se v tím v praxi nechat inspirovat, UDP-hole-punching využívá podle článku hamachi, jenže to je program s GUI a nutnou instalací. Stejně tak i s překompilovaným perlovým skriptem nat-traverse jsem daleko nedošel. Zkusím ještě pohledat nějaké shellové programy využívající UDP-hole-punching. Třeba něco najdu. Děkuji.

[xxl]

Tak si nakonfigurujte OpenVPN na UDP. Klienti za NATy budou mít jako protistranu zapsanou veřejnou adresu NATovacího serveru protistrany. První pakety z jedné strany se budou zahazovat na serveru protistrany do té doby, než začne své pakety posílat protistrana. Pak si oba NATovací servery budou myslet, že se jedná o jedno spojení a bude to fungovat. Jenom to chce, aby NATovací servery neměnily odesílající porty.

[xm]

Tady je řešení, které sám spokojeně používám na několika místech:

Žádný nat-traverse, chownat ani jiný program pro UDP hole punching nepotřebuješ. OpenVPN totiž UDP hole punching zvládá automaticky sama (je to prostě dáno už její podstatou, že používá UDP). Stačí standardní point-to-point konfigurace OpenVPN, s tím že jako remote stranu v konfiguráku nastavíš adresu protějšího NATu. Ještě je také potřeba nastavit volby persist-tun, persist-key a ping, aby se OpenVPN o to spojení snažila i když jí druhá strana neodpovídá a neukončila se.

Tady je moje nastavení OpenVPN:

# Basic settings
dev tap
proto udp
remote nat.adresa.cz
ifconfig 192.168.1.1 255.255.255.0
port 5010
comp-lzo
secret muj_klic.key

# Ping settings
ping 15
ping-restart 45
ping-timer-rem
persist-tun
persist-key
resolv-retry 5

# Logging
verb 3
mute 5

# System user
user nobody
group nobody

Nastavení je na obou stranách stejné, jenom to co jsem vyznačil tučně je třeba změnit (vždycky musí být nastavena adresa protějšího NATu a samozřejmě vnitřní IP adresy se musí lišit).

[xm]

Jinak nemusí to fungovat nutně u všech typů NATů, ale ještě jsem nenarazil na případ, kdy by mi to nefungovalo.

Jo a pokud je tu možnost, že by se měnila vnější IP adresa některého z těch NATů, pak je dobré to kombinovat s nějakým dynamickým DNS (třeba DynDNS).

[xxl]

A tady píšu co?

http://www.abclinuxu.cz/forum/show/213786#23

[xm]

Aha, váš příspěvek jsem nějak přehlédl. Na tenhle dotaz jsem narazil náhodou při vyhledávání. No každopádně alespoň jsem k tomu přidal i konkrétní konfigurák, tak to bude mít dotyčný jednodušší...