Z některých IP se nepřipojím k serveru

[flack]

Tak, a teď podojit ovce, doplnit hladinu bryndzy a hybat do hajan.

A inak jednu by si si fakt vysluzil, privela si dovolujes na ludi.

[Reklama]

[JardaP .]

Pocuvaj ty čurino chovas sa ako pako. Vzdy a vsade uz by ti to mal niekto povedat.

Představ si, že když budu mít na OBOU stranách veřejnou IP a na obou stranách LAN nebo DMZ třeba v oblíbeném subnetu 192.168.1.0/24, a zkusím mezi tím vytvořit VPN, tak - světe div se - ono to nebude fungovat. Hmmm, divný, co?

Tak mi jaksi unika, jak to souvisi s pripojenim na ssh. A kdyby ten server mel nekde za devatero horami, devatero doly a devatero NATy, tak bych predpokladal, ze se na nej nedostane nikdy a z zadne site, ne jen z nekterych siti.

[samohyb]

jarda66:
a) Distribuce?
b) Proc je tvuj soubor hosts.allow tak tajny, ze ho nam nechces ukazat?
c) hosts.allow a hosts.deny nejsou vselek - treba udp vubec neovlivnuji, takze bych doporucoval vratit tam originaly a ochranu resit pres iptables nebo nadstavbu iptables, pokud tam nejakou mas.
d) Pokud jsou v systemu iptables, tak jsou vzdycky zkonfigurovane. Jde jen o to, jestli dobre nebo spatne

[PetrM]

Tak to napíšu ještě jednou pomalu pro ty, co neumí rychle číst.

1) Pokud má 1x veřejnou IP, LAN (nebo DMZ) za svým NATem, potřebuje na tom NATu mít privátní rozsah adres. Řekněme, že server bude na 10.1.1.5
2) Pokud leze z veřejné sítě na svou IP adresu s pomocí VPN, normálně se připojí do svojí sítě a komunikuje z 10.1.1.5, jako by se nechumelilo.
3) Pokud tam leze z cizí NATované sítě, jede to úplně stejně.
4) S výjimkou toho, kdy ta cizí NATovaná síť používá 10.1.1.0/255.255.255.0. Potom se spojení na server zkouší v té cizí síti a požadavek neproleze ani do internetu, natož na jeho veřejnou IP adresu. Přímo viditelná IP má přednost před VPN.
5) Ani nemusí vědět, že leze skrz síť se stejnou IP, jako má jeho DMZ. CGNAT u ISP, který má 1024 adres pro 100k účastníků, maskovaný routerem s NATem v domácnosti kamaráda, od kterýho se pokouší připojit... na souseda, místo na svoje VPN. A při tom má přidělenou IP třeba 192.168.0.230. Klasika.
6) Ověřit se to dá jednoduše pomocí tracert na jeho veřejnou IP. Pokud se tam objeví IP adresa z rozsahu jeho DMZ, je to jasný.

Řešení: GOTO IPv6 (nebo nastavit adresu DMZ tak, aby se nikdo nemohl do jeho rozsahu trefit ani s NATem, ani s CGNATem. A to prakticky nejde). Ona ani ta veřejná IPv4 totiž už dneska není žádná záruka připojení

[Jenda]

2) Pokud leze z veřejné sítě na svou IP adresu s pomocí VPN, normálně se připojí do svojí sítě a komunikuje z 10.1.1.5, jako by se nechumelilo.
3) Pokud tam leze z cizí NATované sítě, jede to úplně stejně.

Já to pochopil tak, že má port forward. Kdyby měl VPN, tak by to snad do dotazu napsal (a např. by napsal, že VPN se připojí, ale SSH pak už ne, nebo že se nepřipojí ani VPN).

[Reklama]

[PetrM]

Psal

"Sry jsem začátečník. Ale evidentně se to netýká jen ssh, ale všech připojení . Ještě mě napadá, že ten stroj do internetu je strčený pres router kde mám nastaveno DMZ ip adresu toho linuxového serveru ."

Z toho jsem pochopil, že se patrně jedná o cosi za NATem. A po SSH se dá přistupovat i v rámci VPN.

Ale je fakt, že ještě může mít blokovaný standardní port pro SSH u některých ISP. Co kdyby se jim někdo pokusil nakonfigurovat některý jejich zařízení? Asi je pro ně nepřekonatelný problém si to zabezpečit certifikátem místo hesla 1234 a změnit port pro management... :Q

[vyseptaly luminofor]

Tak to napíšu ještě jednou pomalu pro ty, co neumí rychle číst.

Jestli je tazatel hornak nebo dolnak jsi taky z jeho dotazu schopen zjistit?
Co kdyz proste ma natovaci krabicku s moznosti nastavit urcitou vnitrni adresu jako "DMZ" (co neprichazi zvenci jako soucast odchozich spojeni se preposila na tuto ip adresu)?
Vic bych za tim nehledal.

[vyseptaly luminofor]

Pro tazatele: taky se muze stat, ze problem s preposilanim portu 22 (ssh) ma ta tvoje krabicka, protoze sama port 22 pouziva. Hod si na svem serveru ssh na nejaky vysoky port. A jinak bych sel cestou vychozich nastaveni hosts.* a ochrany pomoci iptables.

[jeniceek]

Hlavně si na SSH nedávej port knocking, ve všech zkušenostech, které s tím mám to nedělá problém útočníkovi, ale tobě, když se snažíš vzpomenout si na heslo/vybrat správný klíč.
Jinak v dnešní době si dá SSH na port 22 na veřejnou IPv4 jenom totální blázen, stejně tak není moc dobrý nápad umožnit přihlášení na roota a na normální uživatelský účet heslem.
Za relativně bezpečné osobně považuji klíče, pokud občas potřebuješ dát přístup k serveru někomu jinému, tak podepsané klíče s omezenou časovou platností (absolutně výborná featura, pokud útočník nemá možnost podvrhnout NTP server)

[Cek]

[4) S výjimkou toho, kdy ta cizí NATovaná síť používá 10.1.1.0/255.255.255.0. Potom se spojení na server zkouší v té cizí síti a požadavek neproleze ani do internetu, natož na jeho veřejnou IP adresu. Přímo viditelná IP má přednost před VPN.

No to ale samozrejme nemusi byt pravda, pokud v konfiguraci te VPN nastavis, ze veskery provoz potece skrz ni. Popravde bez toho bych do firmy přes VPN třeba ja nikoho nepustil.....

[JardaP .]

Co mate furt s tim VPN? Mluvil tazatel nekde o VPN? Sakra, za chvili tady nekdo odvodi, ze mu to nechodi proto, ze se pripojuje z Argentiny na VPN v Cine a z nej na ten svuj server a problemy dela Velky cinsky firewall.

[uncle Screwdriver]

Ahoj prosím o radu ,
netuším proč to z určitých IP adres nejde , můžete prosím poradit ?
Sry jsem začátečník.

 atd. atd.
...

Když na to nemáš, vybodni se na to a dělej radši něco jiného. Sbírej známky, začni chlastat nebo tak něco...