Poslední příspěvky

Stran: [1] 2 3 ... 10
1
Sítě / Re:Firewall s whitelistem při často měnící se ip adrese
« Poslední příspěvek od Michal Šmucr kdy 16. 10. 2024, 23:57:02 »
Opakuji, že VPN mám, tohle je záložní řešení, když by vpn spadla spolu se serverem. VPN běží jako obyčejný virtuál takže se ho výpadek může týkat stejně jako jakékoli jiné služby. Stačí když bude fungovat tohle nebo VPN, nebo nějaká další ip adresa která se nemění. Pokud jeden fyzický stroj spadne, potřebuji pak nahodit virtuály co tam běžely na jiném stroji a tam se potřebuji co nejrychleji a nejednodušeji dostat.  Dynamickým whitelistem vpn možnost neruším ani neruším možnost udělat to z ip adres, které se nemění.
Že by teoreticky mohlo hádat heslo několik set náhodných BFU lidí z ČR mne nijak netrápí. Jsou tam stejně klíče, přihlášení heslem zakázané. Firewall je tam hlavně proto, aby do něj nebušili útočníci co náhodně skenují internet a zkouší otravovat.

Nejdřív píšete, že to je i pro kolegy a ti mají zakázáno se z domova připojovat přes WG a používají to jen z venku, z toho mi to vycházelo spíš jako primární řešení.
Teď to zas vypadá, že jste si vymyslel tuhle konstrukci s dynamickou DNSkou, abyste si pro sebe (počítám jako primární admin) ušetřil za pevnou adresu bez CGNATu, která se prostě z mnoha důvodů beztak hodí, a tohle má být tedy záloha pro váš SSH přístup.
K tomu nahazujete za mě dost nesmyslné scénáře, kterými si chcete obhájit systém konfigurace s mnoha veřejně přístupnými servery s lokálními firewally a hromadou generovaných pravidel místo standardní klientské VPN brány (případně druhé záložní s jednoduše replikovanou, ale identickou konfigurací). Což opravdu nechápu, nebo resp. chápu, protože jsem podobné věci dělal v 90. letech (pod rootem běžící lokální generátory incoming pravidel pro IPFW ve freebsd, které jsem psal v perlu, opičárny na dial up a tak.), ale dnes mi opravdu přijde, že se tohle poměřně přežilo.

S redund. bránami bych měl jediné body, kde můžu filtrovat, sledovat provoz, logovat přístupy, upravovat konfiguraci, přidávat a odebírat uživatele, revokovat atp. Když se bude něco opravdu nehezkého dít, můžu to prostě bloknout najednou, bez toho abych lezl po dvaceti lokálních fw.
Funguje to pak odevšud stejně, ať už se někdo připojuje z domova, nebo třeba z mobilu v Albánii. Je to také i mnohem lepší pokud by tam pak mimo SSH byly i služby, které nejsou samy o sobě tak zabezpečené. Ten VPN tunel je totiž bez dalšího přičinění uživatele typicky jen virt. interface na jeho počítači, oproti whitelistování jeho veřejné adresy, kdy zpřístupníte služby nejen jeho počítači, ale celé jeho LAN za NATem.
Jakmile tam jsou ještě po normální uživatele nějaké jiné přímé přístupy mimo VPNku (co kdyby náhodou), tak tohle celé trochu padá.

I kdybych pak chtěl nějakou další, svou administrační zálohu, nezávislou na těch zmíněných bránách (resp. třeba hypervizorech, nebo co tam máte), tak jsem přesvědčený, že tam bude dalších x možností jak to řešit čistěji a líp i s  dynamickou veřejnou adresou odkud bych se případně připojoval, a zároveň i tak aby mi to fungovalo odevšud, ne jen z domova.

Ale beru, už jste se rozhodl, jste s tím takhle evidentně spokojený. Já jsem své napsal, svým způsobem i proto, že kdyby někdo ten dyndns whitelist chtěl replikovat, aby si to případně mohl zasadil i do nějakého jiného kontextu.
2
Sítě / Re:Pokročilé dotazy na (nexthop+) (multi)routing
« Poslední příspěvek od Karmelos kdy 16. 10. 2024, 23:39:29 »
Ehm Nedostávám se tím nějak nad možnosti statického routingu? . Hlavní vlastnost statického routingu je podle mého názoru ehm to, že je tak nějak statický. To co požaduješ ty je, opět podle mého názoru, routing dynamický. Proto bych být tebou hledal termit "Dynamický routing", ale jestli je to to, co chceš dělat, ví bůch.
3
/dev/null / Jak anonyme nahlasit a zverejnit kriminalni cinnost. Urady neresi.
« Poslední příspěvek od blbyknezik kdy 16. 10. 2024, 23:05:01 »
V severskych zemich, v malem meste je jeden stary knez, zije a pracuje tam docela dlouho. Ostatni ho maji radi.

Poradne ale nikdo nevi, co ten knez udelal v dobe Covidove. Spratelil se s jednou farmou na odlehlem miste (samota, nikde nic kolem), a kdyz byly hranice za Covidu zavrene, tak toho vyuzil a na tuto farmu posilal pracovat cizince zadarno, 12 hodin denne. Udelal to velmi vychytrale, ze ani neumoznil cizincum kontaktovat okoli. Prej, pojedene na vylet zitra dopoledne.

Zatim to nikdo z oficialnich kruhu neresil, i prez opakovane podmety. Asi si moc cizincu nevazi, nebrali to vazne nebo nevim. Svedci moc nejsou. Nicmene. Napadl me napad, jak dat jeho pocinani vedet do sirokeho okoli (urady, policie, noviny, mesto kde zije, prace - cirkev).

Takze na benzince, kde udelam nedaleko zastavku na prenocovani nebo v restauraci, kde pojedu kolem - plan je takovy:

Zalozim pod jeho jmenem email, ucet na facebooku, twitteru. Mam i jeho fotku, jiz ziskanou z FB, i podrobne info o nem. Po te v Anglictine napisu (text si dopredu predpripravim, nej pojedu na misto), co vsechno ten knez delal a jak s lidma manipuloval (s cizinci, co neznaji prostredi). Pak to prozenu prez google prekladac do lokalniho jazyka a prelozeny text do lokalniho jazyka rozeslu na policii, magistrat, cirkev, do vsech ruznych skupin na facebooku, twitteru, se kterymi ma neco spolecneho (dost techto skupin uz znam). Vse bude pod jeho jmenem s jeho profilovou fotkou a v lokalnim strojove prelozenem jazyce. Text rovnez vlozim na vice mist do dizkuzi a pod, aby se po smazani profilu (profil kneze samozrejme bude brzo nahlasen jako falesny a smazan - od pratel v jeho lokalite) nahodou neztratil. Ono tech profilu bude vic, tak to stejne tak rychle nezmizi.

S knezem ani s farmou jsem mesice neudrzoval zadny kontakt a tak tento nahly utok na vice mistech najednou bude doufan prekvapeni.

Jeste me napadlo par vylepseni planu.

Benzinku s pripojenim Wifi (znam heslo), kde pojedu kolem (dlouha cesta sever-jih) uz mam vytipovanou. Kamery na benzince samozrejme jsou, ale to mi nevadi. Wifi chytnu i venku a notebook ma baterku s dobrou vydrzi. Samozrejme, v noci se muzu k benzince priblizit lesem, aby nebyl zaznamenan prujezd meho vozidla. Cca 3 km od benzinky (ale na jine silnici) je parkoviste bez kamer. Bude v noci tma a Wifi chytnu jeste mezi stromy, mimo dosah kamer. Dokonce tam je i lavicka a stul u reky. Nasledne nasednu do auta a odjedu, budu pokracovat v ceste (po jine silnici, nez kolem benzinky).

Jedna se o konkretni pripad, ale je to i pomerne obecny navod, jak vice-mene anonyme zverejnit, pokud se nekdo dopousti neceho nekaleho a okoli o tom nevi. A samozrejme, MAC adresa se da jednorazove menit. A jsou zde i dalsi napady na vylepseni planu.

Co si o tom myslite, jak nekomu takto prekazit zakernou cinnost. Lokalni jazyk neumim, proto ten google prekladac.
4
Sítě / Pokročilé dotazy na (nexthop+) (multi)routing
« Poslední příspěvek od mikesznovu kdy 16. 10. 2024, 22:42:02 »
Mám na mysli příkaz ip v linuxu, asi konkrétně podpříkaz route(ale třeba to ,co hledám je v jiných subech) a IPv4. Možná dojde i na asymetrický tok. man ip-route jsem studoval,... NH, NHFLAGS...


1. Existuje něco jako dočasné zakázaní route? Něco jako set down, nebo disable, mask? v man jsem našel jsem  disable/enable ,ale pro ttl-propagate. Protože když se smaže, musí se pak přidat se všemi svými parametry, kdyžto toggle by bylo (pro lidi) jednodušší.
+ Existuje něco jako komenřát u routy? podobně jako u iptables a nebo dokonce i ipset řádků-

2. Jak je možné, že se objevily 2 default routy ? ( tím spíš dvě routy se stejným target - lišily se v dev) šlo o Mubuntu s tím lepším Newtorkmanagerem  (umožňující přidat WG, vybírat pásmo u wifi, ale hotspot jsem tam neviděl) . šlo o počítač, s plně automatickou konfigurací připojenám současně k 2  sítím zároveň.. Je to nějaká novinka? Na 5.10 mi to při pokusu přidat píše RTLINKFILEEXISTS

3. existuje něco jako icmp update gateway paket?  Pro klienty. Modelový příklad: změní se default brána  (síť zůstává stejná), ale klient nedostal informaci že si má změnit gateway z 192.168.1.1 na 192.168.1.2 . S tím, že 192.168.1.1 si to zařídí (tím, že default gateway dá na nexthop 192.168.1.2)

Další se týká multi-homingu a dokonce, kdy se druhé spojení nenechází na jiném rozhraní, ale rovnou na jiném hostovi v síti. :
Kód: [Vybrat]
# ip route
default
        nexthop via 10.0.0.1 dev eth3 weight 1 onlink
        nexthop via 192.168.1.2 dev eth4 weight 4
172.16............
a
default
        nexthop via 10.0.0.1 dev eth3 weight 1 onlink dead linkdown
        nexthop via 192.168.1.2 dev eth4 weight 4
172.16............

5.Nenašel jsem nic jako prioritu, preferenci routy u multi-route (ip route add default nexthop via 192.168.1.2  weight 3 nexthop 10.0.0.3 dev eth4 onlink weight N) Weight nefunguje tak jak chci, nezohledňuje to aktuální situaci (když spojení přes danou cestu nejde). a nijak to nereaguje pružně. Nebo se to jmenuje jinak? Preference, pref, metric? asi to není to co chci. Ale metrika je pro celou routu, já hledám elegentní řešení,pokud je cesta použít tu multiroutu, tak tam se musí pro jednotlivé nexthopy, což je weight(jsem si myslel). Pak je nějaké pref(erence), ale mi hlásilo chybu syntaxe. (Je možné že syntaxe pro multi routu má jiné povolené sady parametrů v NH, ačkoliv podle BNF notace se NH opakuje v INFO_SPEC dvakrát  a například weight se ignoruje u routy bez nexthopů a  naopak asi něco nejde použít v nexthopech -viz man ip-route -hledat  "own syntax")

6. Navíc jsem zjistil, že tam je nějaké hysterze. změním default routu (na jedno nebo druhé nebo multiroutu s oběma nexthopy - těžko říct asi, tip bych mtu multiroutu) a z telefonu mi to prostě na jednoho hosta nešlo a problémy byl přímo v tom routeru - příkaz ip route get daný_host vracel starý záznam z té multirouty, ale pro jinou IP ip route get 16.10.20.24 to vrátilo už tu správnou ???
+ Zafungovala nějaká route cache? Jak ji flushnout? Existuje nějaké nastavení timeutu nebo ttl té route cache nebo pooling interval pro kontrolu správnosti/dostupnosti
+EDIT : možná to funguje úplně na principu náhody při stejném weight ( i když druhá je neprůchodná ),  >:(

7. JEDNOU jsem u té multi routy  u jendoho nexthop řádku viděl dead linkdown suffix. Nevím jak se to stalo. Ale nikdy jindy to nezafungovalo. Kde k tomu najdu info?

6. Zaznamenal jsem asi rozdíl ve verzi v linuxu, kdy pro vložení (default ?-asi nezáleží)route přes hosta, je onlink, ale není v rozsahu subnetu sítě (třeba že má přiřazenu masku /32) se musí routa vložit přes 2 příkazy - první pro hosta/32 a druhá via host onlink, zatímco v iném systému jde rovnou vložit ip route add default via 1.2.3.4 dev eth8 onlink bez předchozí známosti 1.2.3.4 v jednom příkazu

7.  na odlehčení: Fungují (hodně vágní analogie) routy  a nexthopy v linuxu  jako  CASCADE constraint v SQL? (dotaz asi jen pro ty ,kteří ví co je to zač)

8. Existuje nějaké nastavení režimu té multirouty? Například jako bonding/teaming má režimy failover, bond, round-robint, hash podle src/dst mac.... Souvisí s pětkou trochu, například další režim, když obě routy fungují, tak rozvažovat traffic poměrně podle weight u jednotlivých nexthopů . souvisí s trochu bodem 6+.



0. Nedostávám se tím nějak nad možnosti statického routingu? Jde to pořád takhle řešit (aspoň ta jediná věc, aby  ten router použil ten správný nexthop z té default multi-routy) . Nebo bych to měl spíš řešit na linkové vrstvě? Ale nedokážu si to představit, když druhý pc (druhá gateway) je v síti a je připojen přes stejný switch k routeru. Nebo se "vracet" k cronu, hook scriptům a pre-up.sh atd ? (což si stejně ale nedokážu představit, protože to by se ten vystrčený 2 .gateway musel připojit přes ssh na router a dát ip route del ...)..

Jak na to? Zkrátka jsem si myslel, že zaměním default via 10.0.0.1 za default nexthop via nexthop via (+ s hypotetickým per-nexthop parametrem weight, timeout, priority, check-interval a per-route parametrem režimem failover/round-robin/weighted/best-latendy) že to bude fungovat out of box.. Jo a neřeším žádný peeringový uzel v silicon valley ale síť na domácí žvýkání.
5
Sítě / Re:Firewall s whitelistem při často měnící se ip adrese
« Poslední příspěvek od messagebus kdy 16. 10. 2024, 21:51:40 »
A nejhorsi ze vseho jsou kotporatci... Vsude vlezou a desne rychle se mnozej.

Az (a pokud) ti jednou dojde, cos tady vykladal, budes se za sebe stydet :)
6
Hardware / Re:Nákup nového serveru s limitem do 50 tisíc Kč
« Poslední příspěvek od messagebus kdy 16. 10. 2024, 21:36:18 »
Ja bych to s tim hardwarem neprehanel, koupil bych to nejlevnejsi z bazaru, holkam Mon Cheri od stankaru a zbytek vrazil do sveho herniho PC, ktery je cca 3 minuty pesky a je nejuzitecnejsim strojem siroko daleko.
7
Sítě / Re:Firewall s whitelistem při často měnící se ip adrese
« Poslední příspěvek od xsouku04 kdy 16. 10. 2024, 21:34:51 »
V korporátech jsou asi moderní ty VPN, protože to jinak jejich myšlení zjevně nedovoluje a hůře by se hlídalo, že v tom firewallu nezůstanou díry.  Ale my nejsme korporát a tak si to můžeme dělat i jinak a bez dalšího speciálního hardware navíc.
Je to nasazené a vypadá to OK.
Že si nějaký korporatec myslí, že to není nejlepší, mne nijak netrápí. Možná se to bude hodit někomu dalšímu.
8
Hardware / Re:Nákup nového serveru s limitem do 50 tisíc Kč
« Poslední příspěvek od Mart1n kdy 16. 10. 2024, 21:00:15 »
Jj bude tam RAID, ale obnovovat se bude jen cca 100GB maximálně do 200GB. Víc tam ani na těch virtuálech není. Původně jsem myslel, že jsou tam dva sloty s PCIe 5, ale on je jen jeden!, ten druhý je 4kový... Takže budou asi dva 4kový, ještě nevím, zkušenost s tím nemám.

Že by tam případně byl jednu jednu noc výpadek nevadí. Jsou tam co hodinu zálohy, takže v případě obnovy RAIDu bych na jiné SSD natahal zálohy, abych měl jakous takous jistotu, že to druhý den pojede.

Tohle není Enterprise řešení s nutností 24/7.

Ty holky umí dát nohy na stůl, udělat si kafe, říct že mi to nejede, z Billy jim donesu Mon Chéri a budu se jen sarkasticky smát, že mi to nejde a budou moci jít domů. A když se zrovna budou řešit výplaty, natáhne se záloha na můj herní PC, který se od kanceláře nachází asi 3 minuty pěšky. A to už se tak jednou skutečně řešilo. Nikdo z nás se neptal, co si o tom místní diskutující myslí, jestli to je OK nebo ne. Bylo to funkční a bohužel si zároveň čichly k tomu, že to jede jako dělo. Proto se i tahle akce dělá.

Fakt mám ten luxus, že to nehoří zas až tak moc :) a takový hovado, abych tam neměl zálohu na jiný lokalitě a ještě jednu offline nejsem. Sice jsme malý a já obyč ajtík, co některým místním pracujícím v Enterprisu nesahá ani po kotníky. Jindy i měním žárovky a řeším zaseklé zámky a objednávám i papíry, taková ta KPV, ale jsem spoko. Navíc všechno fuguje, navzdory názorům, že by nemělo a asi by jsme to rovnou měli zabalit  ;D

Závěrem jen podotknu, že hořím vzrušením, až konečně zkusím o víkendu nahodit na test jednu databázi do toho linuxu, vašim názorům, že to nejde navzdory.


9
Sítě / Re:Firewall s whitelistem při často měnící se ip adrese
« Poslední příspěvek od rmrf kdy 16. 10. 2024, 20:54:48 »
Zaplatit dvě VPS, každou u jiného posktovatele. Z obou VPS zřídit VPN do firmy. Ve firmě zakázat přístupy na služby z jiných ip adres, než jsou ty dvě VPS. Klienti/zaměstnanci budou mít VPN na obě dvě VPS, použijí jednu z nich. Jinak se do práce nepřipojí. Když spadne jedna VPS, druhá poběží. Administrátor si pořídí nějaký další přístup. Nazdar bazar.
10
Sítě / Re:Firewall s whitelistem při často měnící se ip adrese
« Poslední příspěvek od messagebus kdy 16. 10. 2024, 20:23:27 »
Ja to vzdavam. Povazovat VPNku za neco, ceho se musim bat a chtit pro ni zvlastni virtualku, to je trochu moc.
Stran: [1] 2 3 ... 10