Dotaz: Připojení k samba serveru na verejne IP

[Rozik]

Dobrý den, nevim, jak je to mozne, ale nemohu se dostat pres internet na sambaserver, ktery je na verejne IP. Podotykam, ze cca pred mesicem vse fungovalo. Od te doby jsem "snad" nic nemenil. Na sambaserver neni mozno se pripojit, ani kdyz uplne vypnu firewall. V pripade zapleho firewallu je IP sambaclient samozrejme povolena. Polozky host allow a deny jsou v smb.conf zakomentovane, smb server funguje na vsech interface. Je vubec chyba na moji strane?

Za kazdou radu budu rad a predem dekuji vsem zucasnenym.

TCPDUMP (port 2222 je ssh - presunul jsem si jej kvuli utokum):

# tcpdump -i eth1 net sambaclient and not tcp port 2222
tcpdump: listening on eth1
11:43:50.815338 sambaclient > sambaserver: icmp: echo request
11:43:50.815444 sambaserver > sambaclient: icmp: echo reply
11:43:50.861587 sambaclient.1323 > sambaserver.microsoft-ds: S 746992172:746992172(0) win 65535 < mss 1460,nop,nop,sackOK> (DF)
11:43:50.861708 sambaserver.microsoft-ds > sambaclient.1323: S 2367632437:2367632437(0) ack 746992173 win 5840 < mss 1460,nop,nop,sackOK> (DF)
11:43:53.787775 sambaclient.1323 > sambaserver.microsoft-ds: S 746992172:746992172(0) win 65535 < mss 1460,nop,nop,sackOK> (DF)
11:43:53.787853 sambaserver.microsoft-ds > sambaclient.1323: S 2367632437:2367632437(0) ack 746992173 win 5840 < mss 1460,nop,nop,sackOK> (DF)
11:43:54.734420 sambaserver.microsoft-ds > sambaclient.1323: S 2367632437:2367632437(0) ack 746992173 win 5840 < mss 1460,nop,nop,sackOK> (DF)
11:43:57.598136 sambaclient > sambaserver: icmp: echo request
11:43:57.598240 sambaserver > sambaclient: icmp: echo reply
11:43:57.642759 sambaclient.netbios-ns > sambaserver.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; UNICAST
11:43:57.643585 sambaserver.netbios-ns > sambaclient.netbios-ns: NBT UDP PACKET(137): QUERY; POSITIVE; RESPONSE; UNICAST (DF)
11:43:59.134431 sambaserver.microsoft-ds > sambaclient.1321: S 2322887621:2322887621(0) ack 2967232728 win 5840 < mss 1460,nop,nop,sackOK> (DF)
11:43:59.153863 sambaclient.netbios-ns > sambaserver.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; UNICAST
11:43:59.154573 sambaserver.netbios-ns > sambaclient.netbios-ns: NBT UDP PACKET(137): QUERY; POSITIVE; RESPONSE; UNICAST (DF)
11:43:59.790192 sambaclient.1323 > sambaserver.microsoft-ds: S 746992172:746992172(0) win 65535 < mss 1460,nop,nop,sackOK> (DF)
11:43:59.790264 sambaserver.microsoft-ds > sambaclient.1323: S 2367632437:2367632437(0) ack 746992173 win 5840 < mss 1460,nop,nop,sackOK> (DF)
11:44:00.657917 sambaclient.netbios-ns > sambaserver.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; UNICAST
11:44:00.658637 sambaserver.netbios-ns > sambaclient.netbios-ns: NBT UDP PACKET(137): QUERY; POSITIVE; RESPONSE; UNICAST (DF)
11:44:00.734424 sambaserver.microsoft-ds > sambaclient.1323: S 2367632437:2367632437(0) ack 746992173 win 5840 < mss 1460,nop,nop,sackOK> (DF)
11:44:12.734430 sambaserver.microsoft-ds > sambaclient.1323: S 2367632437:2367632437(0) ack 746992173 win 5840 < mss 1460,nop,nop,sackOK> (DF)
11:44:13.734420 sambaserver.microsoft-ds > sambaclient.1317: S 2291006476:2291006476(0) ack 2481571528 win 5840 < mss 1460,nop,nop,sackOK> (DF)

21 packets received by filter
0 packets dropped by kernel

Odpovědi

[#Tom]

Samba mi z nějakého důvodu nefungovala mezi podsítěmi. Vždy jsem použil SSH tunel asi nějak takto:

ssh server -N -f -L 33333:localhost:445
smbmount -o port=33333 //localhost/něco

Navíc jde o bezpečnější řešení.

[#Tom]

Oprava:

mount -o port=33333 //localhost/něco /kam

[Rozik]

To by bylo mozne reseni pro Linux, ale ja bych se potreboval spojit zrovna z tech fuj oken...

[#Tom]

Ten tunel uděláte pod Windows stejně snadno, jako pod Linuxem. (Třeba v PuTTY.) Horší je, že ten port musí být nutně 445 či 139. A to by se asi tlouklo s woknama - můžete to vyzkoušet. Je ale ještě jedna možnost, ta pojede na 100%. Zkuste nějakou virtuální privátní síť, třeba OpenVPN.

[Rozik]

OpenVPN volba byla dalsi v poradi, pokud se prima moznost nezadari. Diky za rady.

[Jiří Veselský]

Co se týče protokolu microsoft-ds, provoz od klienta k serveru zjevně dorazí - klient poslal SYN, server mu odpověděl SYN/ACK a klient nic. Následně klient posílá úplně nový SYN, server odpovídá ještě dvěma SYN/ACKy k tomu prvnímu SYNu a tak dál. Takže buď je někde něčím omezen odchozí provoz od serveru ke klientovi, anebo je nějaký rozdupaný ten klient. Neomezuje vám provoz na microsoft-ds například váš ISP? Ona je to totiž služba, která v 99,999% případů slouží výhradně k šíření virů, takže ji spousta lidí bez skurpulí filtruje.

No a u netbios-ns platí to samé v bleděmodrém. Server přijal request, poslal na něj response a dál už nic.

Čili to vypadá, že samotnému serveru nic není, ani na úrovni firewallu, ani na úrovni samby. Osobně to tipuju na filtraci někde na tranzitu.

[Rozik]

Ted nevim, zda mam mit radost, ze chyba neni na moji strane, nebo plakat, ze si bez tunelu asi neporadim. Myslel jsem si, ze tomu tak bude, ale nebyl jsem si jist. Diky moc. Zacnu tedy resit tunel - nu coz, zase starost navic...

[Jiří Veselský]

Možná bude stačit se příslušného ISP či koho na tu filtraci poptat a eventuálně si ji nechat zrušit, ne? To záleží, s kým máte tu čest

[Rozik]

U jednoho ISP problem neni (tam mam pristupne veskere routery), zato s ISP u clienta nebude moc rec.

[Jiří Veselský]

Na druhé straně, buďte rád. Vystavit windowsoidní protokoly dostupně do Internetu, takovou odvahu bych v sobě nikdy nenašel. Samba sice není tak díravá jako originální implementace té parodie na protokoly, ale samotné protokoly jsou navrženy tak blbě, že je žádná implementace nespasí. Čili ten tunel bych považoval za bezpečnostní nutnost i v případě, že by to fungovalo.

[Rozik]

Dam na Vase doporuceni. Tunel jsem chtel udelat jiz davno, jenze na to nebyl cas a ty data tekouci pres sambu nebyl nijak cenne, tak to bylo rychle dostacujici reseni .

[Rozik]

Dam na Vase doporuceni. Tunel jsem chtel udelat jiz davno, jenze na to nebyl cas a ty data tekouci pres sambu nebyl nijak cenne, tak to bylo rychle dostacujici reseni .

[Rozik]

Dam na Vase doporuceni. Tunel jsem chtel udelat jiz davno, jenze na to nebyl cas a ty data tekouci pres sambu nebyl nijak cenne, tak to bylo rychle dostacujici reseni .