VM - nastavení sítě a firewallu #284
Labels
No Label
app-basic
app-ckan
app-crisiscleanup
app-cts
app-decidim
app-dhis2
app-frontlinesms
app-gnuhealth
app-kanboard
app-mifosx
app-motech
app-odoo
app-opendatakit
app-pandora
app-sahana
app-seeddms
app-sigmah
app-taarifa
app-ushahidi
critical
CZ
documentation
Doing
enhancement
GMaps
info
Mapbox
needinfo
new-app
OSM
performance
QGIS
regression
suggestion
To Do
upstream
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Disassembler/Spotter-VM#284
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Pokouším se tedy spustit VM ve Virtualboxu.
Vesměs chápu postup, ale teď si nedokážu ověřit, jestli síťové nastavení Virtualboxu je takové, že je dostupný internet
Použitý je bridge, bohužel v okně VM neni promt abych na něco pingnul.
Zkoušel jsem i další nastavení jako NAT a NAT síť, ale bez úspěchu.
nyní je toto:
v administračním rozhraní tedy končím na hlášce
Moje aktuální dispozice jsou že používám wifi. Ve Virtualboxu jsem nijak zvlášt nic nenastavoval, pokud jde o firewall a síť.
do rozhraní se tedy dá dostat na IP adrese https://192.168.1.183 ale pochopitelně, že aplikace jsou běžící jen přes doménu.
Tu mám přesměrovanou na IP, ale zatím prostě nemůžu zvnějšku na VM.
changed the description
To je docela zajímavé. Režim "síťový most" je v pořádku. To znamená, že VM bude k síti připojena topologicky paralelně se zařízením na kterém běží a adresu dostane přímo z routeru, což je předpokládám ona 192.168.1.183.
Zjištění dostupnosti HTTP a HTTPS probíhá tak, že VM pošle parametrizovaný požadavek na můj server v internetu (toto později změníme, ať chodí k Vám na cloud) a tam sedí skript, který parametry přečte a pokusí se zpátky z internetu dosáhnout na aplikace jedoucí na Vaší VM. To se buď podaří a vše je OK nebo se to nepodaří a tím pádem máte špatně nastavení firewallu nebo NAT. Vy ale dostáváte ještě třetí stav, při kterém onen odchozí požadavek nikdy nedojde na můj server anebo nedostane odpověď a vytimeoutuje.
Koukám do přístupového logu na serveru a vidím tu hromádku požadavků příchozích ze 193.179.141.156 dnes po 11:30, což si troufám odhadnout jako Vaši vnější IP (ať žije GDPR :P ). Problém tedy bude nejspíše v pingacím skriptu u mě, takže jej jdu zkontrolovat.
Oukej, tak ten hlavní problém je stejně u Vás.
Skript funguje tak, že klientská část (tedy VM) na odpověď čeká jen 5 sekund a pak to prohlásí za timeout a vyhodí tu hlášku, kterou dostáváte. Ale serverová část žádný timeout nemá a v případě, že se připojuje někam, kde nikdo neposlouchá, odřízne ji až timeout nastavený operačním systémem, který je daleko vyšší než 5 sekund. Takže jsem přidal timeout i na stranu serveru.
Problém je nicméně ten, že Vaše VM požaduje kontrolu služeb na portu, který z internetu není vůbec dostupný. Nejspíše proto, že nemáte nastavený NAT na Vašem routeru. To se dá udělat někde v rozhraní toho routeru. Hledejte hesla jako Network address translation (NAT), Port forwarding nebo Virtual server. Tam pak nastavíte, že porty, které jste si zvolil ve VM (ve výchozím stavu 80 a 443) budou nasměrovány na stejné porty na adrese vaší VM (192.168.1.183).
Nastavení forwardingu není podmínkou k tomu, aby VM fungovala, nicméně některé aplikace vyžadují validní TLS certifikát a jednou z cest, jak jej získat, je právě nastavení toho forwardingu. Alternativou by bylo nastavit lokální překlady ve vašem /etc/hosts, získat certifikát ověřením DNS a pak jej nahrát jako manuální do VM. I to mi ale pro laika připadá jako nadlidský úkol.
no, to začíná být vtipné... moje aktuální dispozice je ta, že jsem v Galerii v Českém krumlově, kde se připojuji k nějakém u místnímu APčku, od kterého vím akorát wifi heslo. Těžko asi získám nějaký přístup k jeho nastavení. Jeden člověk který je toho pánem ví sice hovno, zato je právě na Islandu pod stanem v nějaké sopce.
Druhá situace mého připojování nastane v Praze v mém bydlišti. Tam je taktéž jakési domácí APčko, od kterého má heslo apolubydlící a jak ho znám, tak bude časově náročné ho vůbec potkat a pak bude dělat nějaké ofuky s jeho nastavením.
prosím chápejte to tak, že moje testovací fáze bude asi plná těchto dementnícch stavů a mě je jasné že bez aktivní činnosti u mne to nepůjde. Takže některé věci prostě budou složitější.
Aha. Tak v tom případě prosím znovu přehodnoťme zamýšlený model funkce a distribuce. Máme hromadu serverových aplikací, každý pes jiná ves, s nichž některé očekávají, že budou provozovány na plnohodnotném serveru. A některé zase, že se k nim budou připojovat mobilní klienti očekávájící platné doménové názvy a TLS certifikáty.
Má-li být možno provozovat VM i v podobně ztížených podmínkách, jako máte vy (tj. bez přístupu k síťovým prvkům), pak připadají v úvahu dva scénáře při kterých může VM fungovat i bez přístupu z internetu.
Opět povolíme použití selfsigned certifikátů. To je velice pohodlné pro administrátora, protože nemusí na VM nastavovat nic jiného než hostname a port, ale přestanou nám fungovat někteří mobilní klienti a zboří se nám celý systém důvěryhodnosti, protože bude možno VM provozovat na selfsigned certifikátech i v produkci.
Přidáme možnost získání Let's Encrypt certifikátů přes DNS ověření přímo ve VM. To naopak bude pro administrátora docela drbačka, protože bude muset nastavit hromadu doplňkových DNS záznamů a v případě delší životnosti takové VM je každé tři měsíce měnit, nicméně nám zůstane zachována bezpečnost.
V obou případech kdy VM nebude dostupná z internetu, ale pouze z místní sítě, bude zapotřebí, aby si klient nastavil vlastní překlad DNS názvů, nejlépe asi pomocí souboru hosts. Z toho, že máme aplikace rozházené na jednotlivé subdomény slevit nemůžeme, protože by nám přestala fungovat izolace. To je opět problém u mobilních klientů, protože smartphony něco takového obvykle neumožňují. Teoreticky existuje možnost jak toto obejít tak, že na VM poběží i DNS server a klient si jej nastaví místo svého stávajícího, ale to je jednak pochybné jako kráva (osobně bych si něco takové odmítl nastavit) a jednak to může kolidovat s již existujícím nastavením např. v podnikových sítích.
aha, jasný. No já bych tuhle momentální situaci začal také brát v úvahu. Sám netuším jaké situace můžou nastat.
A kdyby to bylo možné, tak prosím abyste umožnil všechny 3 varianty s tím, že je na poučeném adminovi a jeho konkrétní síťové situaci, kterou zvolí.
Výběr samozřejmě má zásadní vliv na běh a použití některých aplikací. Takže s klidným srdcem pak lze říct, že Aplikaci A, B, C nebudou fungovat mobilní klienti, nebo nebudou běžet vůbec. Nebo jim nebudou běžet vnější služby jako mapy atd. Prostě to je jasné a férové konstatování.
Vůbec bych se nedivil ani situaci opačné, tj. že VM by někomu spokojeně běžela na veřejné URL a pak by cosi hapalo a tím by hapala i práce s VM, lhostejno že ona žádný problém nemá. To by bylo dost trapný... A proto by mělo být možné i nějaké "krizové běžení" s menším komfortem. Admin by si to přenastavil a dostal by se alespoň k něčemu.
Doufám že ta varianta self.signed by Vás moc nevytížila. Nevím jak to v kódu a rozhraní doplnit, nechal bych na Vás.
Vlastní DNS jste mi před víc jako rokem rozmlouval, takže teď na něm netrvám, určitě ne jen kvůli této situaci. :)
Bylo by tedy možné nabídnout na začátku nějaké "adminovské rozhodnutí" kterou variantu zvolit? s vědomím většího drbání s nastavením?
Variantu se selfsigned certifikáty jsme už v minulosti měli, takže akorát opráším staré commity a myslím, že většina práce bude hotová. Vím, že s tím byl problém u CKANu, který jsem určitě vyřešil a ostatní aplikace ještě zkontroluji.
Variantu s ověřením pomocí DNS přidám tedy taky. Tam bude asi nejtěžší vymyslet, jak to inteligentně naservírovat skrze to webové rozhraní. Samotný proces vyžádání a ověření skrze DNS už náš Let's Encrypt klient umí. Takže tohle plus ten selfigned certifikát akorát znamená dvě volby v roletce u certifikátů navíc.
A napadá mě i jak ověřovat ty lokální překlady pomocí hosts. Tam nám to akorát za chvíli začne kazit Firefox, který má od příštího vydání změnit způsob překladu doménových jmen a lokální překlady bude ignorovat (skvělá věc, zkurví to překlady i ve všech firmách používajících lokální DNS, už jsem kvůli tomu dva týdny nasranej, protože mám takových firem asi 15). Ale i k tomu tam můžu přidat nějakou noticku. Akorát mám strach, že ty bloky textu pak nebude nikdo číst.
Jinak teda ta Vaše VM funguje se selfsigned certifikátem i teď. Pokud jste již změnil název z výchozího spotter.vm, tak si můžete nastavit tu IP 192.168.1.183 do souboru hosts (Windows =
C:\Windows\System32\drivers\etc\hosts, Mac =/private/etc/hosts, Linux =/etc/hosts) pro všechny ty názvy vypsané v kroku DNS záznamy a pak už se na ně dostanete. Prohlížeč Vám bude vyhazovat bezpečnostní výjimky, ale to je daň za selfsigned.Super. děkuji!
No, tak došlo k mé druhé hlášené konektivitě - doma. A z toho vznikla tato situace:
Bootuje VM a po zadání hesla mi to oznamuje, že přístup je dostupný na doméně, která zůstala nastavená a VM si ji pamatuje.
Což ovšem není pravda, protože moje doména je sice stejná, ale změnila se IP na kterou směruje. tak se přes URL nedostanu na admin rozhraní. (nehledě na to, že i zde bude problém s povolenými porty).
Takže by bylo fajn pro tyto případy, aby první přihlašování po bootu bylo možné a zjevně napsané jak na doménu (pokud bude nastavená a použitelná), tak na IP jako při prvním setupu, pokud nebude z libovolného důvodu doména fungovat. Prostě počítat s nějakou krajně špatnou situací pro spuštění.
pokoušel jsem se do hosts zapsat IP 192.168.1.183, restartoval jsem, ale obávám se, že se tim nic nevylepšilo a na admina jsem se nedostal
(jak říkám... nasimulovat dementní situace mi nedělá problém)
mluvil jsem se spolubydlícím ohledně domácího APčka a ohledně povolení portů pro přístup z vnějšku, řekl že si nemyslí, že by to něčemu pomohlo, protože prý naše AP nemá přidělenou pevnou IP. takže by bylo přinejmenším nutné požádat o totéž poskytovatele o povolení stejných portů u jejich routeru, aby to u nás dávalo smysl.
Kontaktovat našeho ISP s touto prosbou je taktéž komplikované, protože reálně zřejmě asi ani neexistuje nějaký formální vztah a naše konektivita je čerpána jaksi "zdarma" a možná i bez vědomí některých osob :)) Tahle situace je celé dlouhé roky "výhodná" protože za net neplatíme a ikdyž při dnešních cenách konektivit by mohl být pro někoho pakatel, ne však pro nás sociální případy :D ... takže dílčí závěr této situace je, že povolit porty 80 a 443 jednoduše nelze. Prosím nesmějte se mi nahlas.
Z toho vyplývá, že po vás u mého lokálního spouštění nemůžu chtít tu variantu s TLS certifikáty. :)
Spolubydlící říkal něco v podobném duchu jak vy, že on pro případy SW vývoje a vlastního testování musí používat vlastní self-signed certifikáty, které pak na ostrém provozu zamění za ty validní. Tak to dělá i u mobilních klientů... (pokud to ovšem ta appka nebo Android umí) Ještě navrhoval VPNku pro vyřešení, na což jsem nedokázal nějak konkrétněji reagovat.
Prosím tedy, až budete připravovat další testovací build VM, budu to zkoušet nanejvýš s těmi variantami co lokálně dokážu, bez certifikátů... I kdyby fungovalo jen něco, ostatní ne.
Až bychom se dobrali k novému hostingu, tak si tam můžeme vyzkoušet ostřejší test nainstalované VM...
Jasně. Se self-signed certifikáty počítám. Už jsem implementoval i mechanismus, který je vnutí do úložiště důvěryhodných certifikátů, takže pak nebudou potřeba žádné zásahy v aplikacích nebo jejich nastavení. Takže v tomhle směru máme hotovo.
Teď tu vymýšlím (resp. implementuji, protože vymyšleno už je) systém té modularizace. Docker nám v tomhle hrubě háže klacky pod nohy, takže jsem kontejnery přestavěl na LXC a konečně se cítím, že nad nimi mám plnou kontrolu a že vidím, co se kde vlastně děje, aniž bych tam měl patnáct vrstev abstrakce. Počítám, že tento týden bych mohl mít nějaký funkční model a během příštího jej vyšperkuji k dokonalosti.
changed milestone to %3
closed