Julkiset DNS-palvelut

  • Keskustelun aloittaja Keskustelun aloittaja east
  • Aloitettu Aloitettu
  • Avainsanat Avainsanat
    dns
Satuin juttelemaan tästä DNSSEC / DNS / DoH / DoT asiasta täällä toisaalla tietoturva aiheisessa langassa.

Niin tuli vaan mieleen, että tämä lanka olisi paljon oikeampi paikka.

Samalla itsekseni totesin, että tuo selaimem DoH / DoT tuki muuten voi rikkoa jotain järjestelmiä, koska DNS kyselyihin ei tule enää odotettuja vastauksia. mm. DNS tietueet jotka on konfiguroitu vain organisaation sisäiseen DNS proxyyn.

Toisaalta, mikään ei estä ajamasta organisaation sisäistä DNS proxyä DoH / DoT protokollatuella, sekä sisäisesti, että ulkoisesti. Sehän tuossa onkin kätevää, että kun laittaa organisaation DNS proxyn käyttämään DoH / DoT:ia, niin silloin kyselyt menee eteenpäin salattuna, eikä konfiguraatiota tarvitse tehdä kuin yhteen koneeseen tai kahteen, jos haluaa hieman redundanssia.

Samalla oli tapetilla tuo että DNSSEC recordit voi tietysti validoida paikallisesti. Jos DNS resolveri koittaakin väärentää niitä välissä, vaikka DoH / DoT:nkin yli, niin silloinkin tuo paikallinen DNSSEC validoindi hylkää ne.

Viimeisenä kysymyksenä tästä DoH / DoT tuesta tulee se, että mikä on uhka mitä vastaan sillä oikeasti suojaudutaan. Millaistan uhkamallinnusta vastaan tarve on todettu? Aika samanlainen kysymys kuin se, että ratkaiseeko VPN netin tietoturvaongelmat.
 
Vaihdoin DNS:n 1.1.1.1:een. Tein nopeustestit ennen ja jälkeen muutoksen.
Cached name: ei muutosta (edelleen 0)
Uncached name: -3 ms
DotCom lookup: -12 ms

Tuntuvat aika vähäisiltä muutoksilta, mutta näin hitaassa yhteydessä on paras käyttää pienimmätkin mahdollisuudet nopeuden nostoon.
 
JKAVS sanoi:
Vaihdoin DNS:n 1.1.1.1:een. Tein nopeustestit ennen ja jälkeen muutoksen.
Cached name: ei muutosta (edelleen 0)
Uncached name: -3 ms
DotCom lookup: -12 ms

Tuntuvat aika vähäisiltä muutoksilta, mutta näin hitaassa yhteydessä on paras käyttää pienimmätkin mahdollisuudet nopeuden nostoon.
Napsauta laajentaaksesi...

Oliko sulla aikasemmin ISP:n omat DNS:t?
 
U.S. Congress Thinks DNS Over HTTPS Is Anticompetitive

The Wall Street Journal published an unverified report that said that the U.S. House is investigating Google’s use of a new user privacy and security feature called DNS over HTTPS (DOH).
Napsauta laajentaaksesi...

Privacy Feature As Anticompetitive Tool?
According to WSJ’s report, the House investigators asked Google in a September 13 letter whether or not they intend to implement and promote DOH, as well as whether or not Google intends to use the data that would pass through its own servers once the feature is enabled for commercial purposes.

After Facebook’s Cambridge Analytica scandal and other recent privacy scandals, the U.S. government seems more interested in preventing similar abuses of data collection in the future. However, this recent criticism may have been primarily raised by internet service providers (ISPs), who would be cut off from tracking their users’ browsing behavior.

Google stated that it won’t enable its own DOH servers by default for its users:

"Google has no plans to centralize or change people's DNS providers to Google by default. Any claim that we are trying to become the centralized encrypted DNS provider is inaccurate."

Over the past few months, House Judiciary Committee members have been investigating some of the largest technology companies over anti-competitive misconduct, not all of it related to privacy issues, including Amazon, Apple, Google, and Facebook.
Napsauta laajentaaksesi...
 
Mitä DNSCrypt (tai DNS-over-TLS tai DNS-over-HTTPS) ohjelmaa ihmiset suosittelevat (Win64) ja mitä palvelimia?

Itselle tuo on uusi maailma ja koitan hieman kiihdyttää oppimiskäyrää :-)
 
On tässä huonotkin puolensa että käyttää DNSSEC:iä. mm. reittiopas.fi ei toimi. Huoh. api.digitransit.fi RRsigit failaa.

Kääntäen, jos reittiopas on toiminut, on DNS konfiguraatiosi puutteellinen, eikä DNSSEC toimi.

Päästään siis juuri siihen mistä olen kirjoittanut lukemattomia kertoja, kukaan ei halua turvallisia järjestelmiä, eikä IPv6:sta, kun niistä on vaan "pelkkää haittaa" normaaleille uunoille jotka ei välitä mistään muutenkaan mitään, kuin että asiat toimii.

Edit jatkot:

Näyttäisi siltä, että osa DNS resolvereista hyväksyy näköjään vanhentuneet signaturet, jos tiedot on muuten oikein. Mielenkiintoinen valinta sinänsä. Eli signature on muuten validi, mutta se on vanhentunut. - Ohjeistuksen mukaan noin ei saisi toimia, koska se mahdollistaa mm. replay hyökkäykset käyttäen vahentuneita tietoja.

Edit Edit, vielä parin tykkäyksen jälkeen:

Ilmeisesti domainila on DNSSEC käytössä, mutta tuota kyseiseltä recordilta puuttuu DS signature, vaikka sillä on NSEC3 ja RRsig tietueet. Jos Resolved konfiguraatiossa on DNSSEC=yes optiolla käytössä, on seurauksena se, että tuo failaa validoinnin.

HSL-DEV tiimi on todennäköisesti korjaamassa asiaa. ;)
 
Viimeksi muokattu:
Nyt on harjoteltu yötäpäivää tämän kanssa. Dns osoitteina on Cloudfare jolla on käytössä dnssec ja toimiikin testin mukaan. Os tasolla on dnsmasq käytössä sekä dnscrypt.

Vaikuttaako noista jokin negatiivisesti vpn käyttöön ? Onko jotain muuta mitä pitäs vielä tsekata ?

E: Otin tuon dnsmasqin pois käytöstä kuitenkin, en taida tehdä sillä tehdä mitään.
Eli ehkä cloudfaren tarjoama dnssec+dnscrypt on iha riittävä asetus jatkossa ? Edelleen mietin vaikuttaako noista jokin negatiivisesti vpn käyttöön ?
 
Viimeksi muokattu:
runboy93 sanoi:
Yleensä korjaavat suht nopeasti, mutta nyt näyttää olevan ongelma vähän isompi.
Napsauta laajentaaksesi...

Joo, mä ihmettelin ihan samaa, kun valvonnasta on tullut latenssivaroituksia. Mulla liikenne meni vähän operaattorista riippuen Amsterdamiin (Elisa), Tallinnaan (Telia), Dusseldorffiin (Dna).

Edit, jatkot: näköjään dns liikenne menee Telialla nyt Moskovaan. Kai ne käyttää jotain dynaamista load balancingia.
 
Viimeksi muokattu:
Asensin käyttöjärjestelmäksi Manjaron, reitittimessä on dns asetuksena tällä hetkellä 9.9.9.9 quad9 osoitteet jonka pitäis tukea dottia. Tuo DoT on tarkoitus toteuttaa stubbylla. Manjaron pakettilähteistä saa asennettua suoraan ilman aur tukea stubbyn.

Pari kysymystä nyt alkuun. tcpdump näyttää liikennettä kuitenkin yhtäaikaisesti portissa 443 sekä 53 sekä 80 portissa kun surffaan esimerkiksi io-techin sivulla, miksi näin ? sudo tcpdump -n -v -c 60 dst port 443

Tulostaa mm. tälläistä (stubbya ei siis tässä vaiheessa ole vielä käytössä, kun tahdon ensin selvittää miksi tämä menee näin)
17:23:04.064647 IP (tos 0x0, ttl 64, id 44562, offset 0, flags [DF], proto TCP (6), length 52)
192.168.x.x.x > 17x.21x.23x.1x.443: Flags [.], cksum 0xd5d6 (incorrect -> 0x23d8), ack 95649, win 24568, options [nop,nop,TS val 2616209253 ecr 2690428283], length 0

53 portissa taas näkyy se määritetty dns eli 9.9.9.9 , eli 53 porttiko on dns liikenteelle ja 80 sekä 443 vain liittyvät tuohon surffailuun ?
Onko tämä siis ihan normaalia liikennöintiä yhtäaikaisesti eri porteissa ? Stubby käyttää oletusarvona 53 porttia joten minkä pitäisi muuttua kun käynnistän stubbyn ? sudo tcpdump -n -v -c 60 dst port 53
Tulostaa :
17:43:30.557943 IP (tos 0x0, ttl 64, id 16765, offset 0, flags [DF], proto UDP (17), length 75)
192.168.x.x. > 9.9.9.9.53: 57589+ AAAA? 5.cloudfront.net. (47)

Pitäisikö stubbyn siis salata nuo 53 portissa tapahtuva liikenne ? Mutta portissa 80 & 443 pysyy ennallaan eikä niistä tarvitse välittää..?
systemctl enable stubby.service = koneen käynnistyessä käynnistyy myös stubby.service
systemctl start stubby.service = käynnistää stubbyn

Config file löytyy etc/stubby/stubby.yml
Tuolta ei ilmeisesti tarvitse muutella mitään, stubbyn pitäisi nyt toimia ja portissa 53 ?
config tiedostossa sanotaan näin : It will listen on port 53 by default.

systemctl status stubby.service
● stubby.service - stubby DNS resolver
Loaded: loaded (/usr/lib/systemd/system/stubby.service; enabled; vendor preset: disabled)
Active: active (running) since Sun 2020-03-01 17:52:05 EET; 8s ago
Main PID: 11500 (stubby)
Tasks: 1 (limit: 4915)
Memory: 1.9M
CGroup: /system.slice/stubby.service
└─11500 /usr/bin/stubby

maalis 01 17:52:05 x systemd[1]: Started stubby DNS resolver.
maalis 01 17:52:05 x stubby[11500]: [15:52:05.325142] STUBBY: Read config from file /etc/stubby/stubby.yml
maalis 01 17:52:05 x stubby[11500]: [15:52:05.325827] STUBBY: DNSSEC Validation is OFF
maalis 01 17:52:05 x stubby[11500]: [15:52:05.325838] STUBBY: Transport list is:
maalis 01 17:52:05 x stubby[11500]: [15:52:05.325841] STUBBY: - TLS
maalis 01 17:52:05 x stubby[11500]: [15:52:05.325844] STUBBY: Privacy Usage Profile is Strict (Authentication required)
maalis 01 17:52:05 x stubby[11500]: [15:52:05.325847] STUBBY: (NOTE a Strict Profile only applies when TLS is the ONLY transport!!)
maalis 01 17:52:05 x stubby[11500]: [15:52:05.325851] STUBBY: Starting DAEMON....

sudo tcpdump -n -v -c 60 dst port 53

Surffaan dnsleaktest,com niin tcpdump tulostaa vain näin :
17:54:52.x IP (tos 0x0, ttl 64, id 2447, offset 0, flags [DF], proto UDP (17), length 103)
192.168.x.x.> 9.9.9.9.53: 41240+ A? test.dnsleaktest.com. (75)
Eli ei kuitenkaan toimi koko stubby ? Dnsleaktest antaa sen dns osoitteen minkä reitittimeen olen määrittäny. Mikä tuossa nyt menee metsään ? Tai mitä tässä täytyy nyt vielä konfiguroida ?

Modify resolv.conf

After selecting a resolver, modify the resolv.conf file and replace the current set of resolver addresses with address for localhost:

/etc/resolv.conf
nameserver ::1
nameserver 127.0.0.1

Tein tuonkin, mutta tcpdump ei silti huomaa portissa 53 mitään muutosta. Stubby - ArchWiki

hmm. resolv.conf tiedosto bootin yhteydessä ylikirjoitettiin automaattisesti, joten yritän nyt tällä komennolla estää tuon automaattisen ylikirjoituksen # chattr +i /etc/resolv.conf

Lisäksi lisäsin etc/chcpcd.conf tiedostoon vielä nohook resolv.conf

Nyt oman ymmärtymykseni mukaan tuon stubbyn täytyy toimia oikein. resolv.conf tiedostossa on nameserver 127.0.0.1 ja porttina ilmeiseti tuo 53. Kun laitan tuon komennon päätteessa : sudo tcpdump -n -v -c 60 dst port 53 niin tämä ei tulosta enää mitään tekstiä, ennkä missään kohtaa ole vaihtanu porttiakaan eli oletan että toimii. Kun laitan vpn ohjelman päälle resolv conf se ylikirjoitetaan ja vpn toimii. Kun sammutan vpn ohjelman resolv conf muuttuu jälleen 127.0.0.1 eikä 53 portissa näy liikennettä mihinkään.

Lisäksi dnsleaktest.com testillä on vaihtunu 9.9.9.9 osoite pois, jonka oletan nyt näkyvän sen mikä on etc/stubby/stubby.yml conf tiedostossa määritettynä. Ajattelin sieltä kyllä vaihtaa tuon 9.9.9.9 takaisin en nyt tiedä vielä.

Mutta tämmöinen projekti sunnuntaina.

Mikä näistä kolmesta nyt on uusinta uutta teknolokiaa kun netistä en löytäny tietoa, dnscrypt / dns over https / dns over tls ? Dnssec ainakin testin mukaan myös näyttää toimivan.

Mitäs ajatuksia tämä nyt herättää teissä ? Onko tämä hyvä idea pitää ja toteuttaa vai käyttäisittekö jotain muuta ? Näyttääkö siltä että stubby on oikein konffattu ?
 
DoT pitäisi olla portissa 853 tuolla Quad9:ssä, eli tcpdumpilla voit tarkkailla dst port 853. Ja tcpdumpin ei silloin pitäisi näyttää nimikyselyjä, koska liikenne on salattu.
 
kaakau<"'\\/> sanoi:
DoT pitäisi olla portissa 853 tuolla Quad9:ssä, eli tcpdumpilla voit tarkkailla dst port 853. Ja tcpdumpin ei silloin pitäisi näyttää nimikyselyjä, koska liikenne on salattu.
Napsauta laajentaaksesi...

Kiitos ! Näinhän se meneekin. Portti 53 näyttää tyhjää ja vaikka sen piti olla defaulttina mutta jostain syystä liikenne löytyy tuosta mainitsemastasi portista 853.

portti 53 tyhjää täynnä
portti 853 16:10:45 IP (tos 0x0, ttl 64, id 1, offset 0, flags [DF], proto TCP (6), length 0)
x.local.0 > getdnsapi.org.domain-s: Flags [.], cksum 0
(incorrect -> 0), ack 0, win 0, options [nop,nop,TS val 0 ecr 0], length 0

x.local.shaperai > 145.100.185.16.domain-s: Flags [.], cksum 0 (incorrect -> 0), ack 0, win 0, options [nop,nop,TS val 0 ecr 0], length 0

Elikkäs, on siinä joku muutos tullu nyt kun tuon täytyy olla dns liikennettä. Alemmassa tcpdump näytteessa tuo ip numero sarja vastaa juuri samaa mitä dnsleaktest antaa tulokseksi ja nimenomaan portissa 853.

stubby config filussa on siis nämä käytössä jotka vastaa täysin portin 853 liikennettä :
# The Surfnet/Sinodun servers
- address_data: 145.100.185.15

# The getdnsapi.net server
- address_data: 185.49.141.37

Voidaanko nyt siis todeta oikein configuroiduksi ja toimivaksi ?

quad9 on myös tuola config tiedostossa valmiina sen kuin vain uncommaa # , <- tuon merkin kun ottaa pois parilta riviltä ja tekee noille ylläoleville päinvastoin eli lisää # merkin eteen niin homman pitäis toimia moitteettomasti....ehkä...
 
Pah0lain3 sanoi:
Asensin käyttöjärjestelmäksi Manjaron, reitittimessä on dns asetuksena tällä hetkellä 9.9.9.9 quad9 osoitteet jonka pitäis tukea dottia. Tuo DoT on tarkoitus toteuttaa stubbylla. Manjaron pakettilähteistä saa asennettua suoraan ilman aur tukea stubbyn.

Pari kysymystä nyt alkuun. tcpdump näyttää liikennettä kuitenkin yhtäaikaisesti portissa 443 sekä 53 sekä 80 portissa kun surffaan esimerkiksi io-techin sivulla, miksi näin ? sudo tcpdump -n -v -c 60 dst port 443
Napsauta laajentaaksesi...
Tästä pitkästä kerronnasta ei käy mielestäni ilmi sellainen perusasia, että puhutaanko yhdestä vai kahdesta laitteesta.

tcpdump on mielekäs tässä tapauksessa silloin, kun sillä tutkitaan yhtä interfacea kerrallaan. Esim. reitittimen/DNS resolverin WAN-interfacessa ei näy liikennettä remote-servujen porttiin 53 vaan 853. Ja että LAN-interfacessa voi näkyä molempia, jos reititin vastaa sekä DNS- että DoT-kyselyihin läheverkossa. LAN:ista internettiin DST-portti 53 voi olla jopa blokattu, jolloin ainoastaan DoT on sallittu.
 
Pahoittelut. Ihan yhden laitteen projektista kyse. Tavallisesta perhe/koti käyttöisestä tietokoneesta.
 
Mites dnscrypt tai DoT on toteutettavissa tietokoneella missä on windows 10 järjestelmä ?
Simple DNSCrypt ohjelmalla vai jollain muulla tapaa ? Onko joku kokeillu ?
 
Eikö se ois helpompaa asettaa reititin tekemään noi DNS-kyselyt nettiin päin DoT/DoH:nä ja muut sisäverkon laitteet kyselemään reitittimeltä? Näin ne DNS-kyselyt menee suojattuna nettiin, ainoostaan sisäverkko on avoin.
 
Kyllä Simple DNSCryptiä voi suositella ja todellakin se kannattaa ottaa käyttoon jos ei "pääkoneessa" pelkästään, niin jopa DNS palvelimena jos omassa verkossa on kone mikä on päällä 24/7.

Ollut itsellä ajossa vuosikausia ja sen jälkeen kun cloudflaren 1.1.1.1 syntyi maailman kartalle, niin eipä ole ollut yhtään katkoa palvelussa mitä muistaisin. Toki kyseessä on jenkkifirma, mutta logituspolitiikka pitäisi olla aika minimissä ja ainakaan se ei sensuroi domaineja, kuten suomioperaattorit.

En siis itse konffaisi Simple DNScryptiä automaatiasetuksille vaan valitsisin Cloudflaren ja backupiksi jonkun toisen palvelimen läheltä Suomea. Lisäksi DNS cache kannattaa laittaa päälle. Ainakaan itse en ole huomannut mitään eroa netin nopeudessa vs. operaattorin oma DNS.
 
A Lake Elk sanoi:
Eikö se ois helpompaa asettaa reititin tekemään noi DNS-kyselyt nettiin päin DoT/DoH:nä ja muut sisäverkon laitteet kyselemään reitittimeltä? Näin ne DNS-kyselyt menee suojattuna nettiin, ainoostaan sisäverkko on avoin.
Napsauta laajentaaksesi...

Olis mukavampi ratkaisu huomattavasti. Rikoin jo äskettäin yhden reitittimen typeryyksissäni joten nyt mennään vähä eri kaavaa. Toki jos ei asentaiskaan tuohon windows koneeseen enää mitään vaan voisi yrittää nyt suoraan kokeilla saada edgerouteriin dns over tls. Eiköhän tässä Manjarossa ollu harjoitetta riittävästi jos kokeiltais nyt tuohon edgerouteriin.

Noita ohjeita oon lueskellu niin moneen otteeseen mutta rohkeus ei vaan riitä. Jos täältä löytäis vähä apuja niin ehkä sitten.

Kiitos myös @mikajh & @aiwan

Tälläisen ohjeen mm. olen löytäny

DNS-over-TLS on the EdgeRouter Lite · Chameth.com

chameth.com chameth.com
En tiedä tuon toimivuudesta, mutta seuraava ohje myös tämäkin liittyy tähän samaan hässäkkään
help.ubnt.com

EdgeRouter - Add Debian Packages to EdgeOS

Overview Readers will learn how to add other/custom Debian packages to EdgeOS using the Debian repositories. NOTES & REQUIREMENTS: Applicable to the ...
help.ubnt.com help.ubnt.com
Ubiquitin sivulla ohjeistetaan lataamaan oikeat debianin repositoryt eli pakettilähteet ? Mutta tässä on nyt ensimmäinen ongelma.

Currently running EdgeOSv2.0.8 on tällä hetkellä
help.ubnt.com

EdgeRouter - Add Debian Packages to EdgeOS

Overview Readers will learn how to add other/custom Debian packages to EdgeOS using the Debian repositories. NOTES & REQUIREMENTS: Applicable to the ...
help.ubnt.com help.ubnt.com
Add Debian Packages to EdgeOS v2.0.0 and Newer Versions
Se on tuo sitten varmaan mikä on oikea sivu alkaa tähän projektiin...Asensin Manjaroon juuri myös Puttyn, eli jos joku osaa sanoa onko tuo linkkaamani ohje toimiva dns over tls saamiseksi edgerouteriin niin voisi aloittaa pienen kokeilun.

Kyllä, olen huomioinu että sudo apt-get upgrade EI saa komentaa puttylla koska saattaa rikkoa jotain.
WARNING: Do not use the apt-get upgrade command as it can break the customized Debian packages used in EdgeOS.

@mikajh ilmeisesti suosittelee dnscryptiä, mutta sen ohje edgerouteriin jokapaikassa näyttää niin sekavalta että tuo dns over tls saattaa olla helpompi ratkaisu minun tilanteessa ?

Tämähän olis kyllä hienoin ja kerrassaan loistava ratkaisu tosiaan ratkoa tämä jo reititin tasolla niin ei tarvitsisi jokaista laitetta konfiguroida erikseen. Osaisko joku vahvistaa tähän astisen että kannattaako tätä lähteä toteuttamaan ?

Tuo chametin ohje vain tuottaa vain erittäin paljon vaikeuksia kohdissa joissa konffataan nuo asetukset tarkemmin, kun minulla on nyt konffeissa palomuurisääntöjä kahdelle eri verkolle enkä osaa kääntää tuota ohjetta ip osoitteineen itselle sopivaksi.
 
Viimeksi muokattu:
Kokeilin tätä DNSCrypt :iä pfSenseen: DNSCrypt/dnscrypt-proxy
DNS Resolver -asetuksissa oli pientä viilausta eli clearasin tämän ruksin, koska se ei ollut yhteensopiva eikä tarpeellinen DNSCryptin Custom options:n kanssa:
Koodi: 
DNS Query Forwarding  [_] Enable Forwarding Mode
diff /usr/local/etc/dnscrypt-proxy/dnscrypt-proxy.toml /usr/local/etc/dnscrypt-proxy/dnscrypt-proxy_org.toml
37c37
< listen_addresses = ['127.0.0.1:5353', '[::1]:5353']
---
> listen_addresses = ['127.0.0.1:53']
59c59
< ipv6_servers = true
---
> ipv6_servers = false
65c65
< doh_servers = false
---
> doh_servers = true
71c71
< require_dnssec = true
---
> require_dnssec = false
228c228
< netprobe_address = '1.1.1.1:80'
---
> netprobe_address = '9.9.9.9:53'
 
Tuolla on ihan "ok" ohje myös edgeOs;lle (edgerouter er-x)
github.com

Installation on EdgeOS

dnscrypt-proxy 2 - A flexible DNS proxy, with support for encrypted DNS protocols. - DNSCrypt/dnscrypt-proxy
github.com github.com

Ainut mitä mietin niin ongelma tulee itsellä noiden kahden edgerouterin verkon kanssa kun pitäisi syöttää seuraavat komennot.
Koodi: 
delete service dns forwarding system 
set service dns forwarding options 'server=127.0.0.1#5353'

Verkot on näin
eth0=wan
eth1=192.168.10.1
eth2=192.168.20.1
switch0=eth2,eth3 & eth4

Vaikuttaako tuo dnscrypt konffaus nyt sitten kaikkiin verkkoihin automaattisesti vai täytyykö tuo dnscrypt jotenkin vielä eri loitsulla kytkeä eth1 & eth2 verkkoihin ? Tuossa on se suurin ongelma nyt itsellä. Osaatko sanoa miten tuo menee ?
 
Meni puihin heti alkuunsa. Yritin asentaa dnsutils paketteja niin putty sanoo näin :

# sudo apt-get install -y dnsutils
Reading package lists... Done
Building dependency tree... Done
The following additional packages will be installed:
geoip-database libbind9-140 libdns162 libgeoip1 libisc160 libisccc140 libisccfg140 liblwres141
Suggested packages:
rblcheck geoip-bin
The following NEW packages will be installed:
dnsutils geoip-database libbind9-140 libdns162 libgeoip1 libisc160 libisccc140 libisccfg140 liblwres141
0 upgraded, 9 newly installed, 0 to remove and 13 not upgraded.
Need to get 4565 kB of archives.
After this operation, 14.5 MB of additional disk space will be used.
E: You don't have enough free space in /var/cache/apt/archives/.
[edit]

Eli ei taida edgerouter er-x:ssä olla tilaa tämmöiselle ...
 
Pah0lain3 sanoi:
Tuolla on ihan "ok" ohje myös edgeOs;lle (edgerouter er-x)
github.com

Installation on EdgeOS

dnscrypt-proxy 2 - A flexible DNS proxy, with support for encrypted DNS protocols. - DNSCrypt/dnscrypt-proxy
github.com github.com
:
Vaikuttaako tuo dnscrypt konffaus nyt sitten kaikkiin verkkoihin automaattisesti vai täytyykö tuo dnscrypt jotenkin vielä eri loitsulla kytkeä eth1 & eth2 verkkoihin ? Tuossa on se suurin ongelma nyt itsellä. Osaatko sanoa miten tuo menee ?
Napsauta laajentaaksesi...
EdgeOS-ohjeen kohdan "If all went well, configure router settings and redirect queries to dnscrypt-proxy:" perusteella mitään muita muutoksia ei tarvita.
Samoin kuin pfSense:ssä, jossa oletuksena unbound DNS Resolverina, sen sijaan että se lähettää suoraa internetiin DoT-kyselyitä, se lähettääkin ne localhostissa (itse pfSense) pyörivälle DNSCrypt-proxylle.
 
Pah0lain3 sanoi:
Meni puihin heti alkuunsa. Yritin asentaa dnsutils paketteja niin putty sanoo näin :

The following additional packages will be installed:
geoip-database libbind9-140 libdns162 libgeoip1 libisc160 libisccc140 libisccfg140 liblwres141
Napsauta laajentaaksesi...
En tiedä miksi geoip-database on leivottu tuonne riippuvuudeksi. Muut paketit vaikuttavat pakollisilta.

Toisaalta vaadittu lisätila on aika pieni. Poistitko kaikki ylimääräiset DNSCrypt-tiedostot kuten dnscrypt-proxy.tar.gz:n? Kuinkahan paljon ER-X:ssä on normaalisti vapaata flashia. Oliko kokonaismäärä peräti 256 MB? Sehän on paljon, kun OpenWRT toimii hyvin jo 16 MB:llä

EDIT: Tuossa EdgeOS-ohjeessa oli myös tärkeä alkudisclaimer: "Following instruction was tested on ERLite-3 running 1.10.x EdgeOS."
ERLite-3:ssa on 2 GB flässiä. Jos EdgeOS huitelee nyt versiossa 2.x, niin sinnekin lienee kertynyt lisää läskiä.

Eli ER-X:ssä voi olla ongelma tallennustilan kanssa, jos se on normaalistikin melkein tapissa (256 MB). Ehkä UI-ketjusta tai Googlamaalla löytyy vastauksia
 
Viimeksi muokattu:
Kokeilin vielä käynnistää edgen uudelleen ja toistaa samat jutut, niin samaan herjaukseen päätyi siltikin toinenkin kokeilu.

Näkisinkö mistään mitenkään onko tuonne jääny johonkin muistiin joku päivitys tai jos siellä ylimääräisiä img tiedostoja tai jotain ? Vois kokeilla poistaa jos siellä on jotain ylimääräistä mutta linux taidot loppui vaan tähän kun ei tiedä yhtään mitä etsiä eikä viitsi sokkonakaan huidella menemään. Mutta vaikuttais nyt siltä että tuo tila ei riitä mikä oli vähä kurja juttu.

Edit: Sanooko tällä df -h komennolla mitään @mikajh sulle
Filesystem Size Used Available Use% Mounted on
ubi0_0 214.9M 214.7M 0 100% /root.dev
overlay 214.9M 214.7M 0 100% /
devtmpfs 123.0M 0 123.0M 0% /dev
tmpfs 123.6M 0 123.6M 0% /dev/shm
tmpfs 123.6M 2.3M 121.3M 2% /run
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 123.6M 0 123.6M 0% /sys/fs/cgroup
tmpfs 123.6M 4.0K 123.6M 0% /tmp
tmpfs 123.6M 0 123.6M 0% /run/shm
tmpfs 123.6M 92.0K 123.5M 0% /var/log
tmpfs 123.6M 0 123.6M 0% /lib/init/rw
none 123.6M 608.0K 123.0M 0% /opt/vyatta/config
overlay 123.6M 4.0K 123.6M 0% /opt/vyatta/config/tmp/new_config_355cd296577c4a7f82fe8d57b3417f5f
tmpfs 24.7M 0 24.7M 0% /run/user/1000
 
Viimeksi muokattu:
kaakau<"'\\/> sanoi:
sudo apt-get clean pitäisi tyhjentää turvallisesti tuon kansion.
Napsauta laajentaaksesi...
Löysin kanssa tämmöisen kohdan ubiquitin foorumilta kuin :

You can try
"delete system image"
It will delete the "backup" system image, which will give you about 70-100MB free space.

But you will have problems in the future trying to update your firmware, since your device will not have sufficient space.

Eli jos kokeilen tuota, ja saisinkin vahingossa tilaa jjolloinka voisin saada dnscryptin asennettua mutta sitten tuossa varoitetaan että jatkossa firmiksen päivitys voi olla ongelmallista ?

ER-X SFP: no space left on device | Ubiquiti Community

since I upgraded my ER-X SFP to 1.8.0 I have problems while installing additional packages trough apt-get.for example: root@erx01:~# apt-get install wget
community.ui.com community.ui.com

Edit : Alkaa viittaamaan nämä kommentitkin jo siihen suuntaan että er-x:ssä ei ole vaan ole tilaa ylimääräisille jutuille.
"
You shouldnt install anything on your ERX, doesnt matter if you installed "almost nothing additional", theres no enough memory to use.
Like said before, if you need space, go ER-Lite or higher."


Er-x
www.jimms.fi

Ubiquiti EdgeRouter X -reititin, 5 x Gigabit RJ-45, musta - 71,00€

Ominaisuudet : - Hienostuneet reititysominaisuudet - Kehittynyt turvallisuus, monitorointi ja hallinta - Suorituskykyiset Gigabit -portit Tekn
www.jimms.fi www.jimms.fi

EdgeRouter Lite
www.jimms.fi

Ubiquiti EdgeRouter Lite -reititin, 3 x Gigabit RJ-45, musta - 142,00€

Ominaisuudet : - Hienostuneet reititysominaisuudet - Kehittynyt turvallisuus, monitorointi ja hallinta - Suorituskykyiset Gigabit -portit (3 kpl) - Hiljainen, tuulettimeton käy
www.jimms.fi www.jimms.fi

Menee jo sen verran kalliiksi tuo lite että tämmöiseen epävarmaan kokeiluun ei viitsi ihan noin kallista ostaa.
 
Viimeksi muokattu:
mikajh sanoi:
Vähän näyttäisi sille, että / on mountattu read onlynä normitilassa. Mitä näyttää komento, jos tiedosto on olemassa
cat /etc/fstab
Napsauta laajentaaksesi...

x:~$ cat /etc/fstab

proc /proc proc defaults 0 0
sysfs /sys sysfs defaults 0 0
tmpfs /lib/init/rw tmpfs mode=0755,nosuid 0 0
tmpfs /run tmpfs mode=0755,nosuid 0 0
tmpfs /var/log tmpfs mode=0755,nodev,noexec,nosuid 0 0
tmpfs /run/shm tmpfs nosuid,nodev 0 0
none /dev/pts devpts noexec,nosuid,gid=5,mode=620 0 0
tmpfs /tmp tmpfs defaults,nr_inodes=300000 0 0

Tuommoista.
 
mikajh sanoi:
Entäs vielä x:~$ mount
Napsauta laajentaaksesi...

x:~$ mount

ubi0_0 on /root.dev type ubifs (rw,relatime,ubi=0,vol=0)
overlay on / type overlay (rw,noatime,lowerdir=/root.loop,upperdir=/root.dev/w,workdir=/root.dev/work)
devtmpfs on /dev type devtmpfs (rw,relatime,size=125928k,nr_inodes=31482,mode=755)
sysfs on /sys type sysfs (rw,relatime)
proc on /proc type proc (rw,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,mode=755)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
mqueue on /dev/mqueue type mqueue (rw,relatime)
tmpfs on /tmp type tmpfs (rw,relatime,nr_inodes=300000)
tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,relatime)
tmpfs on /var/log type tmpfs (rw,nosuid,nodev,noexec,relatime,mode=755)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,relatime,mode=755)
none on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
none on /opt/vyatta/config type tmpfs (rw,nosuid,nodev,relatime,nr_inodes=300000,mode=775)
overlay on /opt/vyatta/config/tmp/new_config_56c70f8bc34e4c9e8ef8cfde6e3dbb18 type overlay (rw,relatime,lowerdir=/opt/vyatta/config/active,upperdir=/tmp/changes_only_56c70f8bc34e4c9e8ef8cfde6e3dbb18,workdir=/tmp/changes_only_56c70f8bc34e4c9e8ef8cfde6e3dbb18_w)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=25320k,mode=700,uid=1000,gid=100)

Semmosta, nuo ei mulle kerro yhtään mitään. Kyllä se varmaan niin on että joudutaan luovuttamaan edgen osalta. Mutta, vielä mulla on tuo pihole projekti ylimääräisen läppärin kanssa kesken, pystyiskö sitä hyödyntämään tässä hommassa ?
 
Pah0lain3 sanoi:
x:~$ mount

ubi0_0 on /root.dev type ubifs (rw,relatime,ubi=0,vol=0)
overlay on / type overlay (rw,noatime,lowerdir=/root.loop,upperdir=/root.dev/w,workdir=/root.dev/work)

Semmosta, nuo ei mulle kerro yhtään mitään. Kyllä se varmaan niin on että joudutaan luovuttamaan edgen osalta. Mutta, vielä mulla on tuo pihole projekti ylimääräisen läppärin kanssa kesken, pystyiskö sitä hyödyntämään tässä hommassa ?
Napsauta laajentaaksesi...
Kai noiden rw-tyyppisten mountien ja aiempien vapaan tilan määrien (about 0) on uskottava, että fläshiä ei ole juuri tavuakaan vapaana lisäpaketeille. ER-X logittaa ram-levylle pelkästään.

dnsscript-proxy:sta oli ARM-arkkitehtuureille kaikki variaatiot ja jopa Pi-Hole -ohjeet, joten sitä voisi käyttää paremmin kuin tuota ER-X:ää.
 
mikajh sanoi:
Kai noiden rw-tyyppisten mountien ja aiempien vapaan tilan määrien (about 0) on uskottava, että fläshiä ei ole juuri tavuakaan vapaana lisäpaketeille. ER-X logittaa ram-levylle pelkästään.

dnsscript-proxy:sta oli ARM-arkkitehtuureille kaikki variaatiot ja jopa Pi-Hole -ohjeet, joten sitä voisi käyttää paremmin kuin tuota ER-X:ää.
Napsauta laajentaaksesi...

Jaksatko käydä minun kanssa läpi jos kokeillaan saada läppärillä toimimaan tuo pihole ja dnscrypt ? Siinä on Manjaro myös asennettuna ja pihole mutta en ole saanu pihole käyttöliittymää vielä vaan avattua läppärillä enkä muullakaan. Kun saatais pihole oikein konffattua läppäriin siinä ois toviksi ihmeteltävää kyllä taas.

Siirrytäänkö toiseen ketjuun kun asia vaihtuu ?
 
Varmaan nopein tapa pystyttää pihole Linux/amd64/Intel-ympäristöön olisi Docker: Docker Hub
Sitten kun sen päälle lisää dnscrypt-proxyn, niin joutuu vähän tunkkaamaan lisää, ellei joku ole sitäkin tehnyt valmiiksi. Todennäköisesti on

EDIT: Laitoin Ubuntu serverin Dockeriin pyörimään itsetehdyn pihole-imagen. DNSCrypt-proxyä siinä ei vielä ole (vaan pfSensen palomuurissa, joka käyttää nyt piholea clientien DNS-palvelimenta, joka taas käyttää pfSensen DNSCryptiä DNS:nä)
 
Viimeksi muokattu:
Cloudflarelta olisi nyt saatavilla malware ja/tai lapsiturvallisella-suojalla varustetut "1.1.1.1" DNS:t

blog.cloudflare.com

Introducing 1.1.1.1 for Families

Introducing 1.1.1.1 for Families — the easiest way to add a layer of protection to your home network and protect it from malware and adult content. 1.1.1.1 for Families leverages Cloudflare's global network to ensure that it is fast and secure around the world.
blog.cloudflare.com blog.cloudflare.com

www.bleepingcomputer.com

Cloudflare Launches a DNS-Based Parental Control Service

Cloudflare introduced today '1.1.1.1 for Families,' a privacy-focused DNS resolver designed to help parents in their efforts to safeguard their children's online security and privacy by automatically filtering out bad sites.
www.bleepingcomputer.com www.bleepingcomputer.com
 
Tuo cloudflare vain kuulostaa niin liian hyvältä kaikkinensa palveluineen. Mietityttää kyllä kovasti mutta aika näyttää mitä tapahtuu.
 
Cloudflare meni minulla ainakin jäähylle toviksi, Ps4 pelien lataus hidasta tai sitten ei resolvaa niitä dns-osoitteita oikein.
9.9.9.9 toimii hienosti ja sisältää haitallisten sivujen blokkauksen
 
Onkos muilla ongelmia Cloudflaren kanssa, että jostain kumman syystä toi DNS reitittää USA kautta? Mulla näyttää dnsleak testi las vegasia tällä hetkellä.
 
pfSense + Cloudflare DDNS on kiukutellu kolme kertaa viimesen 2vk:n aikana. Jostain syystä Cloudflare puski DDNS:ssä päälle heidän proxyn, joka piti käydä pahimmassa tapauksessa 5 kertaa muuttamassa muotoon "DNS Only". Ja siittä ilmeisesti johtui oman domainin outo IP (muistaakseni joku 104.x.x.x), jonka takia en saanu OpenVPN-yhteyttä omaan verkkoon muodostettua.
 
Kirjaudu tai rekisteröidy kirjoittaaksesi tänne.

Uutiset

Uutisia lyhyesti

Uusimmat viestit

Statistiikka

Viestiketjuista
262 400
Viestejä
4 549 921
Jäsenet
74 984
Uusin jäsen
Tere

Hinta.fi

Back
Ylös Bottom