IPv6 Suomessa

[Marquette]

Ei kyse ole siitä että annetaan ziljoonia ositteita. Se IPv6 kun on 128-bittinen osoite niin

Juu hyvä pointti tajuan tämän, mutta aavistelen tai arvailen mihin kehitys menisi ehkä. Ripen standardit muuttuvat yhdellä nuijan kopautuksella.

 

[JiiPee]

Juu hyvä pointti tajuan tämän, mutta aavistelen tai arvailen mihin kehitys menisi ehkä. Ripen standardit muuttuvat yhdellä nuijan kopautuksella.

Toki niitä voidaan muuttaa mutta on noita stantardeja kuitenkin mietitty jo aika pitkään. Itsekin peuhannu IPv6 kanssa ihan 2000 luvun alusta tunnelien kanssa silloin kun oli vielä testit käynnissä ja oliko se nyt 3ffe:: netwörkistä jaeltiin osoitteita.
Ihan helpolla tuota SLAAC ei kyllä lähetä rikkomaan. Ennemminkin ensin tullaan kirraamaan tuota /56 prefix suositusta, sehän mahdollistaa nyt 256 netwörkkiä per asiakas. Kuin moni oikeesti tarttee 256kpl /64 prefixin netwörkkiä? Siis kotikäyttäjä? Tuon kun kirraa vaikka /57 eli 128 netwwörkkiin niin johan vapautui läjä netwörkkejä taas jaeltavaksi.

 

[jad]

Eli kun se IPv6 osoite on esim. 1234:1234:1234:1234:abcd:abcd:abcd:abcd niin toi 1234:1234:1234:1234 osuus eli 64-bit on sitä mitä operaattoreille jaetaan ja abcd:abcd:abcd:abcd on varattua SLAAC käyttöön. Voidaan niitä käsinkin coffata tai dhcp6:lla, mutta se slaac on suositeltu tapa. Näille kahdelle 64-bit lohkolle on olemassa myös ihan jotkut hienot viralliset nimensä, mutta en nyt tietenkään niitä muista ulkoa.

Aikanaan on tullut pelehdittyä ip4 verkkojen kanssa enemmänkin, ne on hallussa, mutta ipv6 on tuttu lähinnä teoriatasolla, kun ei ole tarvinnut työn puolesta enää noiden kanssa puuhastella. Enkä ole vielä nähnyt tarpeelliseksi viritellä ipv6:tta kotikäyttöön.

Mutta tuota olen aina ihmetellyt, että mikä hemmetin kuningasidea tuo SLAAC on aikanaan ollut kun ipv6 standardia on kehitelty. Jotain hienoa sen takana varmaan on.

Jos nyt esimerkiksi minulla on kotiverkossa serveri-a ja serveri-b, jaan näille ip4-osoitteet sitten dhcp:llä tai manuaalisesti, niin voin olla varma, että ip pysyy samana ja voin vaikka lisätä näiden ip4 osoitteet serveri-c:n hosts tiedostoon ja saan aina ssh yhteyden oikealle koneelle host-nimellä.

Nyt jos kotiverkko olisikin ipv6, niin operaattoria vaihtaessa prefix vaihtuu ja serveri-c:n hosts tiedosto ei enää ole ajantasalla. Tai jos vaihdan serveri-a:n verkkokortin ja SLAAC generoi osoitteen mac-osoitteesta, taas menee serveri-c:n hosts tiedosto epäkurantiksi.

Jos nyt pysytään yksinkertisuudessa samalla tasola, eikä aleta asentelemaan mitään dhcp6 ja nat6 virityksiä, niin onko ipv6:ssa jokin tapa, jolla sisäverkko edelleen toimisi 'heittämällä' suoraan host-nimen perusteella kuten ylläolevassa ipv4 esimerkissä ?

 

[JiiPee]

Aikanaan on tullut pelehdittyä ip4 verkkojen kanssa enemmänkin, ne on hallussa, mutta ipv6 on tuttu lähinnä teoriatasolla, kun ei ole tarvinnut työn puolesta enää noiden kanssa puuhastella. Enkä ole vielä nähnyt tarpeelliseksi viritellä ipv6:tta kotikäyttöön.

Mutta tuota olen aina ihmetellyt, että mikä hemmetin kuningasidea tuo SLAAC on aikanaan ollut kun ipv6 standardia on kehitelty. Jotain hienoa sen takana varmaan on.

Jos nyt esimerkiksi minulla on kotiverkossa serveri-a ja serveri-b, jaan näille ip4-osoitteet sitten dhcp:llä tai manuaalisesti, niin voin olla varma, että ip pysyy samana ja voin vaikka lisätä näiden ip4 osoitteet serveri-c:n hosts tiedostoon ja saan aina ssh yhteyden oikealle koneelle host-nimellä.

Nyt jos kotiverkko olisikin ipv6, niin operaattoria vaihtaessa prefix vaihtuu ja serveri-c:n hosts tiedosto ei enää ole ajantasalla. Tai jos vaihdan serveri-a:n verkkokortin ja SLAAC generoi osoitteen mac-osoitteesta, taas menee serveri-c:n hosts tiedosto epäkurantiksi.

Jos nyt pysytään yksinkertisuudessa samalla tasola, eikä aleta asentelemaan mitään dhcp6 ja nat6 virityksiä, niin onko ipv6:ssa jokin tapa, jolla sisäverkko edelleen toimisi 'heittämällä' suoraan host-nimen perusteella kuten ylläolevassa ipv4 esimerkissä ?

Siis ei sen SLAAC:n käyttö mikään pakollinen ole mutta gateway:n kanssa voi mennä aika säätämiseksi kuluttaja liittymissä jos ei halua SLAAC käyttää. Yrityspuolella on sitten ihan eri homma kun sulle routataan tietty ipv6 prefix niin voit sitten jaella niitä osoitteita ihan miten itte hyvältä tuntuu.
Ja nat6 joo on olemassa mutta se on aika hiton iso ei ei. Se rikkoo ihan kaikkia ipv6 speksejä, sitä ei missään tapauksessa tulisi käyttää missään. Jossain vaan on pakko jos meinaa saada palvelut pelaamaan ipv6:lla. Esim. OVH hosting on niin mölli VPS palveluntarjoa että ne antaa sulle ihan tasan yhden /128 prefixin ipv6 osoitteen mikä myös rikkoo räikeästi speksejä.

SLAAC:n ideahan on sen helppous. Eihän se täydellinen ole, mutta mikä sitten olis?

Mutta siis tuohon kysymykseesi ja host määritelmiin, niin ainahan voi käyttää sisäverkon puolella link-local ipv6 osoitteita. Eli fe80::/10 soitteita taikka virittelee julkisen verkon rinnalle priva ip verkon fd00::/8

 

[jessenic]

Mobiili verkossa standardista poikkeavaa tehdään lähinnä sen vuoksi koska Android ei tue DHCPv6:tta eikä taida tukea kyllä iOS myöskään.
Tarina ei tosiaan sano mitä IPv6 osoitteet tulee jatkossa maksamaan mutta tällä hetkellä niitä ainakin saa vähä jokapuolelta puoli ilmaiseksi, ainakin siis operaattorina.

Ja mobiiliverkossa ei muutenkaan ole edes DHCP käytössä, vaan osoitteet jaetaan mobiiliverkon signaloinnin mukana APN:n perusteella. Tämä asettaa omat rajoitteensa.

 

[kryptonian]

Ja mobiiliverkossa ei muutenkaan ole edes DHCP käytössä, vaan osoitteet jaetaan mobiiliverkon signaloinnin mukana APN:n perusteella. Tämä asettaa omat rajoitteensa.

Mistä ohjelmasta noi kuva kaappaukset on?

 

[jessenic]

Mistä ohjelmasta noi kuva kaappaukset on?

Network Signal Guru. Vaatii rootin ja tuetun modeemin.

 

[kryptonian]

Network Signal Guru. Vaatii rootin ja tuetun modeemin.

Tuettu modeemi => Qualcomm ainoastaan näköjään eli suurinosa OnePlus laitteista taitaa toimia?

 

[jessenic]

Tuettu modeemi => Qualcomm ainoastaan näköjään eli suurinosa OnePlus laitteista taitaa toimia?

Qualcomm tosiaan helpoin, nykyään on tukea muillekin, mutta vaativat enemmän ja vähemmän säätämistä. Ja jep, OnePlus pitäisi toimia hyvin.

 

[pulatunnus]

Vähän nyt nyppään irti kontekstista, mutta eikö tässä ole juuri tuon ipv6 siirtymän kannalta suurin (tietoturva)ongelma. Jos operaattori jakaa /56 blokin ja Tauno Tavallisen kaikki kotihärvelit sattuu olemaan ipv6 kelpoisia, niin tämähän tarkoittaa käytännössä sitä, että defaulttiasetuksilla oleva vanha operaattorilta hankittu modeemi päästää kaiken ipv6 liikenteen suoraan näille härveleille.
Nykyisessä ipv4 setupissa sentään modeemit on oletuksena konffittu nattaamaan liikenne ja kotihärvelit ovat suorilta porttiskannauksilta kohtuullisen hyvin suojassa.

Maallikkona.
Siitä kai pitäisi lähteä että kuluttajareittimissä on jonkinlainen palomuuri.

Ja se kai ajatus että jaetaan /64, jos tuota /56 pidit riskinä haasteellisena.

Nykyisessä ipv4 setupissa sentään modeemit on oletuksena konffittu nattaamaan liikenne ja kotihärvelit ovat suorilta porttiskannauksilta kohtuullisen hyvin suojassa.

Jos ei pelkästä 5Gstä puhuta, niin vähän yleistäen.
Operaattori jakaa kuluttajille joko pelkkiä modeemeita / mediamuuntimia / kytkimiä, joiden yhteydessä korostetaan että asiakkaan pitää hankkia se palomuuri.

tai vaihtoehtoisesti tarjoavat niitä palomuuri reittimiä, tai modeemireittimiä joissa palomuuri.

nat on se takia että kuluttajille yhteyksissä tarjotaan rajallinen määrä julkisia IP osoitteita, jos vain pelkkä NAT niin sitä ei saisi kutsua palomuuriksi.

Kuluttajaliittymissä on myös operaattoreilla jotain suojakerroksia, joiden toivoisi tarttuva jos siellä aletaan porttiskannaan ziljoonaa IP osoitteita .

Ipv4ssa , jos NATattu, niin julkisesta nettiin helpompi löytää ja jos se rupunen älylaite on sen portin avannut

 

[pulatunnus]

Ja mobiiliverkossa ei muutenkaan ole edes DHCP käytössä, vaan osoitteet jaetaan mobiiliverkon signaloinnin mukana APN:n perusteella. Tämä asettaa omat rajoitteensa.

5G ketjussa tästä ilmeisesti juttua.

Maalikolle,

Onko siinä jotain käytännön rajoituksia ? IPv4lla ilmeisesti se ettei montaa julkista IPt (vai onko tämä väärinkäsitys), mutta se ei IPv6 normaalisti ongelma ?

 

[jessenic]

5G ketjussa tästä ilmeisesti juttua.

Maalikolle,

Onko siinä jotain käytännön rajoituksia ? IPv4lla ilmeisesti se ettei montaa julkista IPt (vai onko tämä väärinkäsitys), mutta se ei IPv6 normaalisti ongelma ?

IPv6:n kanssa on myös rajattu määrä ja toiminnallisuus, mutta minä en tarkemmin sen osalta tiedä.

 

[JiiPee]

5G ketjussa tästä ilmeisesti juttua.

Maalikolle,

Onko siinä jotain käytännön rajoituksia ? IPv4lla ilmeisesti se ettei montaa julkista IPt (vai onko tämä väärinkäsitys), mutta se ei IPv6 normaalisti ongelma ?

IPv4 osalta ongelma on käsittääkseni siinä että käytetään ikivanhoja protokollia jotka on suunniteltu aikana jolloin se mobiili netti käsitettiin laitekohtaiseksi. Ja se että ne IPv4 on loppu, niitä ei voi jakaa niin että lampaat söisi.

IPv6:n kanssa on myös rajattu määrä ja toiminnallisuus, mutta minä en tarkemmin sen osalta tiedä.

Ei siinä IPv6 kohdalla mielestäni mitään sen kummoisempia rajoituksia ole. Jos sulle reititetään /64 prefixi, niin kyllä sitä voi edelleen jakaa mobiilissa ihan samoin kuin kuidussa. Pitää vaan olla sellainen purkki keulilla josta löytyy esim radvd.
Hyvin ainakin DNA:n mobiililla kaikki härvelit sai toimivan IPv6:n omalla kohdalla. Pitkään en kuitenkaan näin ajellut kun purkin palomuuriominaisuudet oli niin surkeat että olis tarttenu joka härvelin kohdalla erikseen säätää itkumuurien kanssa, joten poistin käytöstä IPv6. Olen viritellyt nyt yhteen vanhaan Telewell TW-4G (LTE) wifi reititinpurkkiin openwrt tukea joka olis tarkoitus ottaa kohta käyttöön, jospa sen kanssa saisi toimivan palomuurin toteutettua niin että ei tartte joka härvelillä erikseen konffailla. Ei uskalla tuollaista purkkia keulille laittaa kun kerneli on joku aataminaikainen 2.6.13 tai jotain.

 

[jad]

Ja nat6 joo on olemassa mutta se on aika hiton iso ei ei. Se rikkoo ihan kaikkia ipv6 speksejä, sitä ei missään tapauksessa tulisi käyttää missään.
---snip---
SLAAC:n ideahan on sen helppous. Eihän se täydellinen ole, mutta mikä sitten olis?

Vanhana ipv4 pieruna tässä kohtaa tulee mieleen, että ratkaistiinko tässä ipv6:n kohdalla SLAAC:lla ja NAT:n 'poistamisella' taas kerran jotain ongelmaa, jota ei oikeasti ollutkaan.

Mutta siis tuohon kysymykseesi ja host määritelmiin, niin ainahan voi käyttää sisäverkon puolella link-local ipv6 osoitteita. Eli fe80::/10 soitteita taikka virittelee julkisen verkon rinnalle priva ip verkon fd00::/8

Totta, näin toki voi tehdä, mutta 'kauhean' monimutkaista. Eikös tässä käy niin, että ipv4:n kaltaista sisäverkkoa ei periaatteesa 'pysty' ipv6:lla toteuttamaan. Jos sisäverkon laitteilla haluaa liikennöidä ulkomaailmaan, niin ne vaatii tuon julkisen ipv6-ositteen. Vai olenko taas missannut jotain ?

 

[samim]

Vanhana ipv4 pieruna tässä kohtaa tulee mieleen, että ratkaistiinko tässä ipv6:n kohdalla SLAAC:lla ja NAT:n 'poistamisella' taas kerran jotain ongelmaa, jota ei oikeasti ollutkaan.

No ei, mutta ei IPv6 ole täydellinen. Se on lisäksi yli toistakymmentä vuotta vanha.

IPv6 on korjaus IPv4-osoiteavaruuden pienuuteen nykyisessä käytössä. Privaattiverkkoja on, mutta jos kaksi yritystä joutuu liikennöimään paljon keskenään puhumattakaan, että yritykset yhdistyvät, niin kaikenlaista kikkailua tarvitaan, kun käytössä on päällekkäistä osoitteistoa. Julkisia osotteita käytettäessä tätä ongelmaa ei ole.

Internet on lähtökohtaisesti ollut verkko, jossa mistä tahansa osoitteesta on päässyt liikennöimään mihin tahansa osoitteeseen. NAT rikkoi tämän.

IPv6n suunnittelussa haluttiin käyttöön osoitteen automaattinen allokointi ilman mitään DHCPtä tai vastaavaa, jonka johdosta on tehty mm. SLAAC. Jokin idea oli hyödyntää verkkokortin MAC-osoitetta osoitteen muodostamiseen, mutta silloin ei ehkä nähty asiaa ihan joka näkökulmasta.

Kokonaan huomaamatta on jäänyt tässä keskustelussa, että IP-lohkosta jätettiin pois tarkastussummat, joita IPv4-paketille on pitänyt laskea uudelleen ja uudelleen, ja se on tarvinnut turhaa laskentatehoa.

 

[samim]

Jos sisäverkon laitteilla haluaa liikennöidä ulkomaailmaan, niin ne vaatii tuon julkisen ipv6-ositteen.

Kyllä. Ja noita osotteita on saatavilla joka organisaatiolle niin paljon kuin tarvetta on. Ongelmana Suomessa vaan ovat teleoperaattorit, jotka turhaan hidastavat IPv6n käyttöönottoa reguloinnin puuttuessa.
vilkaise www.google.fi/ipv6 ja katso, miten paljon liikennettä tulee isolta osin suomalaisista mobiililaitteista googleen jo nyt.

 

[JiiPee]

Vanhana ipv4 pieruna tässä kohtaa tulee mieleen, että ratkaistiinko tässä ipv6:n kohdalla SLAAC:lla ja NAT:n 'poistamisella' taas kerran jotain ongelmaa, jota ei oikeasti ollutkaan.

Niin noh ainahan voidaan asiasta kinastella että onko ipv4 natti myöskään niin erityisen upea härveli. Itte olen siitä kyllä tykännyt kun se yksinkertaistaa itkumuurin virittämistä todella paljon vaikka nattia ei palomuuriksi saisikaan kutsua, niin jos ei ole mitään automaattista porttien ohjailu viritystä niin kyllähän se varsin tehokkaasti itkumuurin virkaa hoitaa kun blokkaa käytännössä kaiken sisääntulevan liikenteen jota ei ole sisältä ensin avattu.

Totta, näin toki voi tehdä, mutta 'kauhean' monimutkaista. Eikös tässä käy niin, että ipv4:n kaltaista sisäverkkoa ei periaatteesa 'pysty' ipv6:lla toteuttamaan. Jos sisäverkon laitteilla haluaa liikennöidä ulkomaailmaan, niin ne vaatii tuon julkisen ipv6-ositteen. Vai olenko taas missannut jotain ?

No siis jos sisäverkon laitteissa on ipv6 aktivoituna vaikka eivät mitään osoitetta saisikaan, niin sinulla on jo tuon link-localin kautta todennäköisesti ipv6 sisäverkossasi käytössä. Ittellä ainakin windows monesti tykkää samba palvelimelle liikennöidä tuolla ipv6 link-local osoitteella eikä ipv4 osoitteella.

Jos sisäverkon laitteilla halutaan ulkomaailmaan liikennöidä ipv6:lla niin silloin sisäverkon härvelillä tarttee olla siitä julkisesta prefixistä jaettu ip, tai sitten tosiaan pitää viritellä jotain nat6 joka ei todellakaan ole suositeltavaa nykyaikana.

 

[jad]

Kyllä. Ja noita osotteita on saatavilla joka organisaatiolle niin paljon kuin tarvetta on. Ongelmana Suomessa vaan ovat teleoperaattorit, jotka turhaan hidastavat IPv6n käyttöönottoa reguloinnin puuttuessa.

Jos sisäverkon laitteilla halutaan ulkomaailmaan liikennöidä ipv6:lla niin silloin sisäverkon härvelillä tarttee olla siitä julkisesta prefixistä jaettu ip, tai sitten tosiaan pitää viritellä jotain nat6 joka ei todellakaan ole suositeltavaa nykyaikana.

Kyllähän ipv6 avaruudessa osoitteita riittää, se ei ole ongelma. Itseäni tässä vain hiertää se, että ipv6:n myötä se kotiverkko ei enää ole täysin omassa hallinnassa, vaan mukaan tulee tuo operaattorin tarjoama prefixi, joka vaihtuu viimeistään operaattorin vaihdon yhteydessä. Ja prefixin vaihtuminen taas tarkoittaa lisätyötä kaikenmaailman palomuurisääntöjen yms. kanssa. Toki ipv6 selviä parannuksia mukanaan tuo, mutta mukana tulee näitä pikku lisäsäätöjä verrattuna ipv4-nat sisäverkkoon.

Lähinnä teoreettista nillitystähän tämä on. Tällä vauhdilla ipv4:stä ei tulla minun elinaikanani luopumaan

 

[JiiPee]

Kyllähän ipv6 avaruudessa osoitteita riittää, se ei ole ongelma. Itseäni tässä vain hiertää se, että ipv6:n myötä se kotiverkko ei enää ole täysin omassa hallinnassa, vaan mukaan tulee tuo operaattorin tarjoama prefixi, joka vaihtuu viimeistään operaattorin vaihdon yhteydessä. Ja prefixin vaihtuminen taas tarkoittaa lisätyötä kaikenmaailman palomuurisääntöjen yms. kanssa. Toki ipv6 selviä parannuksia mukanaan tuo, mutta mukana tulee näitä pikku lisäsäätöjä verrattuna ipv4-nat sisäverkkoon.

Lähinnä teoreettista nillitystähän tämä on. Tällä vauhdilla ipv4:stä ei tulla minun elinaikanani luopumaan

Ja tuossa on juurikin se syy miksi ittellä ei vielä ole ipv6 kotiverkossa käytössä koska edellisen reitittimen palomuuri ei kyennyt hommaa kunnolla hoitamaan vaan joka vehkeelle olis erikseen pitäny muuri conffata.
Nyt olen tosiaan OpenWRT:tä virittänyt toimimaan yhteen telewellin purkkiin, on pull request myös openwrt:lle siitä, mutta purkki ei vielä ole "tuotannossa" kun noiden pull requestien kanssa tuppaa olemaan melkosta säätöä että hyväksytään, niin pitää aina ehdotetut muutokset firmikseen testata että ne toimii.

 

[pulatunnus]

Vanhana ipv4 pieruna tässä kohtaa tulee mieleen, että ratkaistiinko tässä ipv6:n kohdalla SLAAC:lla ja NAT:n 'poistamisella' taas kerran jotain ongelmaa, jota ei oikeasti ollutkaan.

NATista (yksi moneen) eroon pääsy yksinään jo valtava juttu.

Ongelma varmaan se että vanhat koti harrastajat on tuon kanssa jotenkin tottuneet pärjäämään jopa niitä pinttyneesti että ajatukset jumahtaneet siihen mailmaan.

Toinen ongelma että huonosti sellaista Suomi materiaalia millä siviilikin sisäistäisi IPv6 mailman, huomioiden sen että moni IP4 Nat kotipuuhastelia ei sinänsä ole sitä vanhaakaan mailmaa opiskellut (eikä ethernet). Jolloin sen kirjallisuuden ei pitäisi vaatia aiempaa tietämystä. (tällä meinaan sitä että erikotikäyttäjillä se osaaminen ja termit voivat olla kirjavaa ja toisistaan poikkeavaa).

Kirjallisuudella tarkoitain sellaista yhden teoksen kotiraamattua, enkä mitään hajautettua tilkkutäkkiä.

 

[pulatunnus]

Ei siinä IPv6 kohdalla mielestäni mitään sen kummoisempia rajoituksia ole. Jos sulle reititetään /64 prefixi, niin kyllä sitä voi edelleen jakaa mobiilissa ihan samoin kuin kuidussa. Pitää vaan olla sellainen purkki keulilla josta löytyy esim radvd.

"radvd" ensimmäinen nettihaku osuma, "avoimenkoodin ohjelma" ? sekin googlen suomentama, muuten jotain keskustelusivujen osumia.

Mutta ilmeisesti tarkoitat sitä että modeemin pitää hanskata asia niin että reitittimelle se näkyy DHCP palvelimena joka jakaa sille ymmärettävästi mobiiliverkon signaloinin mukana jaetut IPt ym.

Modeemi keskusteluketjuissa tätä kai kutsutaan "siltaavaksi" tilaksi, termi juontaa kupariverkojen reitinmodeemeista.

 

[Boromir]

En tiedä meneekö oikeaan ketjuun, mutta eikö kukaan ole törmännyt IPv6:n haasteisiin palomuuriavauksien osalta? Vaikuttaa siltä, että edes pfSensessä (puhumattakaan muista kuluttajatason reitittimistä) tuntuu olevan mahdotonta tehdä järkeviä IPv6-palomuuriavauksia.

Eli jos pyöritän esim ihan yksinkertaista web-palvelinta kotona ja avaan portin tiettyyn IPv6-osoitteeseen joudun määrittämään koko ip-osoitteen prefiksin mukaan lukien. Hieno homma siihen asti kunnes operaattori sattumalta vaihtaa /56 prefixiä ja kaikki IPv6 säännöt lakkaavat toimimasta ja joutuu käsin tunkkaamaan kaikki avaukset uusiksi.

Olen yrittänyt pfSensellä saada tätä toimimaan, mutta näemmä edes aliaksilla tämä ei onnnistu. Avoimen feature-requestin tosin löysin mutta tuskin tämä koskaan pääsee työstöön: Feature #12190: Add ability to reference ipv6 prefix in firewall rules and aliases - pfSense - pfSense bugtracker

Teenkö siis jotain väärin vai onko reitittimien/palomuurien ominaisuudet edelleenkin ihan alkeelliset IPv6:n osalta? Vai onko dynaamiset /56 -prefiksit joku "vain suomessa" -tyyppinen ratkaisu?

 

[Pakana]

Käyttäjää kiinnostaa että on että ne IoT laitteet ovat yhdessä tai useammassa omassa kuplassa, kodin viihde verkko omassa, vierasverkko omassa ja joillain myös (etä)työ verkko omassa kuplassa. + oma juttut.

Eihän se pelkkä aliverkko sitä omaan kuplaansa tee, ainakaan siinä mielessä että sillä tietoturva olisi kunnossa. Jos IOT laitteet ja tietokoneet yms on samassa verkossa, niin ei se pelkkä osoiteavaruus siitä turvallista tee, vaan pakkohan se on palomuurillä eristää se IOT puoli, vaikka se olisikin omassa aliverkossaan..

Sinänsä se on kyllä selvä että ipv4 osoitteet on paljon selkeämpiä, ovathan ne paljon lyhyempiä.

Ios tukisi tämän mukaan mutta Android ei.

Comparison of IPv6 support in operating systems - Wikipedia

en.wikipedia.org

Tuossa listassa on Android versio 4.2 (ja 4.0 version nimi). Ei taida olla kovin säntillisesti ylläpidetty tuo lista.

Eli jos pyöritän esim ihan yksinkertaista web-palvelinta kotona ja avaan portin tiettyyn IPv6-osoitteeseen joudun määrittämään koko ip-osoitteen prefiksin mukaan lukien. Hieno homma siihen asti kunnes operaattori sattumalta vaihtaa /56 prefixiä ja kaikki IPv6 säännöt lakkaavat toimimasta ja joutuu käsin tunkkaamaan kaikki avaukset uusiksi.

Eikö tuo sama ongelma ole myös ipv4:ssä jos operaattori vaihtaa sitä asiakkaan ip osoitetta jonka takaa se yhteys natattuna tulee?

Sinänsä olisi kätevää jos palomuurisäännöt voisi tehdä joillain dyndns tyyppisillä osoitteilla.

 

[Prodec]

Eikö tuo sama ongelma ole myös ipv4:ssä jos operaattori vaihtaa sitä asiakkaan ip osoitetta jonka takaa se yhteys natattuna tulee?

Ei ole, koska se palvelimen lähiverkon ip pysyy NAT:n vuoksi samana, ainoastaan julkinen ip vaihtuu. Ipv6:ssa taas ei ole NAT:ia, joten palvelimelta tulevilla paketeilla on sourcena palvelimen julkinen ip, jonka alkuosa siis vaihtuu kun prefix vaihtuu.

 

[mikajh]

Olen yrittänyt pfSensellä saada tätä toimimaan, mutta näemmä edes aliaksilla tämä ei onnnistu

Ainakin itsellä onnistuu aliaksella IPv6-prefixillä matchays esim. source-osoitteeseen

 

[Pakana]

Ei ole, koska se palvelimen lähiverkon ip pysyy NAT:n vuoksi samana, ainoastaan julkinen ip vaihtuu. Ipv6:ssa taas ei ole NAT:ia, joten palvelimelta tulevilla paketeilla on sourcena palvelimen julkinen ip, jonka alkuosa siis vaihtuu kun prefix vaihtuu.

Niin jos se palvelin on siellä palomuurin sisäpuolella... Eikö sitä sääntöä voi tehdä niinpäin että ip osoitteen alkuosa on jokerina?

 

[pulatunnus]

Eihän se pelkkä aliverkko sitä omaan kuplaansa tee, ainakaan siinä mielessä että sillä tietoturva olisi kunnossa. Jos IOT laitteet ja tietokoneet yms on samassa verkossa, niin ei se pelkkä osoiteavaruus siitä turvallista tee, vaan pakkohan se on palomuurillä eristää se IOT puoli, vaikka se olisikin omassa aliverkossaan..

Ei tee. Kuten ei tee nelosessakaan.
Pitää pitää huoli että ovat muutekin erillään ja jos haluaa noiden välillä liikennöidä niin muuri välille.

Käytännössä kai jos käyttää yhteistä rautaa, niin omissa virtuaalilaneissa ja pitää olla tarkkana sitten kytmienkin kanssa.

 

[pulatunnus]

Ei ole, koska se palvelimen lähiverkon ip pysyy NAT:n vuoksi samana, ainoastaan julkinen ip vaihtuu. Ipv6:ssa taas ei ole NAT:ia, joten palvelimelta tulevilla paketeilla on sourcena palvelimen julkinen ip, jonka alkuosa siis vaihtuu kun prefix vaihtuu.

Dynaaminen nimipalvelu, senhan myös sen muutavan IP nelosenkin kanssa tarvinnut.

 

[JiiPee]

Dynaaminen nimipalvelu, senhan myös sen muutavan IP nelosenkin kanssa tarvinnut.

Ei se dynaaminen nimipalvelu mitään auta jos itkumuuriin ei pysty sääntöjä tekemään wildcardin kanssa.

jos sulla on yhtenä hetkenä ip 1111:2222:3333:0001:aaaa:bbbb:cccc:dddd eli netwörkki 1111:2222:3333:0001::/64 ja sitten se muuttuukin 1111:2222:3333:0002::/64 niin vanha sääntö ei enää toimi.
Se sääntö pitäs saada määritelty jollain wildcard tyylillä esim 1111:2222:3333:*:aaaa:bbbb:cccc:dddd jos tietää että se operaattori jakaa niitä 64 netwörkkejä yhdestä /48 prefixistä.
Tai sitten wildcardina koko alkupuolisko.

En ole vielä asiaan perehtynyt kun ei ole vielä ajankohtainen, mutta viimeeksi kun esim. iptablesin kanssa on tullu pelehdittyä, niin noi säännöt on melko staattisia. Eli mitään automaattista tunnistusta sille että prefix on vaihtunut ei tietääkseni ole ollut. Ehkä nykyisin on.

 

[mikajh]

jos sulla on yhtenä hetkenä ip 1111:2222:3333:0001:aaaa:bbbb:cccc:dddd eli netwörkki 1111:2222:3333:0001::/64 ja sitten se muuttuukin 1111:2222:3333:0002::/64 niin vanha sääntö ei enää toimi

Tuo voidaan hoitaa NPt:llä Network Address Translation — IPv6 Network Prefix Translation (NPt) | pfSense Documentation

 

[JiiPee]

Tuo voidaan hoitaa NPt:llä Network Address Translation — IPv6 Network Prefix Translation (NPt) | pfSense Documentation

En nyt täysin vakuuttunut ole että tuo purisi kyseiseen ongelmaan, pikemminkin vaikuttaisi ipv6 nati viritykseltä jolloin sisäverkon laitteille ei tarttis julkista ipv6 osoitetta ollenkaan vaan voitaisiin tuon kanssa puljata noilla priva osoitteilla. En ainakaan nopeasti tutkimalla huomannut että siinä olisi mitään automaagista hommaa joka muuttaa sääntöihin oikean prefixin kun se muuttuu, päin vastoin havainnekuvasta sain sen käsityksen että tää on staattisia säätöjä varten kun sinne pitää koko prefix naputella.

 

[Pakana]

@JiiPee Siis pitääkö siihen palvelimeen päästä nyt käsiksi internetistä vai sisäverkosta?

Jos vaan sisäverkosta, niin silloinhan tuo privaattiavaruuden ip aja asiansa hyvin, noita ipv6 osoitteitahan on muutenkin yleensä useampi yhtä aikaa. Jos internetistä, niin vosiko ratkaisu olla rakentaa reitittimeen yksi portti joka ei ole palomuurilla suojattu mitenkään ja tehdä palvelimeen itseensä palomuuri?

 

[SupremeBug]

jos sulla on yhtenä hetkenä ip 1111:2222:3333:0001:aaaa:bbbb:cccc:dddd eli netwörkki 1111:2222:3333:0001::/64 ja sitten se muuttuukin 1111:2222:3333:0002::/64 niin vanha sääntö ei enää toimi.
Se sääntö pitäs saada määritelty jollain wildcard tyylillä esim 1111:2222:3333:*:aaaa:bbbb:cccc:dddd jos tietää että se operaattori jakaa niitä 64 netwörkkejä yhdestä /48 prefixistä.
Tai sitten wildcardina koko alkupuolisko.

[OpenWrt Wiki] IPv6 firewall examples

openwrt.org

Auttaisiko tämä?

Lisäys: Linkki on väliotsikkoon "Dynamic prefix forwarding", mikä kertoo hieman enemmän ennen linkin avaamista.
Lisäys2: Kokeilin sääntöä OpenWrt:ssä sen verran, että siitä syntyi ihan validin näköinen wildcard mask ip6tables-säännölle. Liikennetestiä en pysty nyt tekemään.

 

[JiiPee]

@JiiPee Siis pitääkö siihen palvelimeen päästä nyt käsiksi internetistä vai sisäverkosta?

Jos vaan sisäverkosta, niin silloinhan tuo privaattiavaruuden ip aja asiansa hyvin, noita ipv6 osoitteitahan on muutenkin yleensä useampi yhtä aikaa. Jos internetistä, niin vosiko ratkaisu olla rakentaa reitittimeen yksi portti joka ei ole palomuurilla suojattu mitenkään ja tehdä palvelimeen itseensä palomuuri?

Sisäverkko ei ole ongelma vaan ulkoverkosta sisään ryömiminen kun on prefixi vaihtuu ISP:n toimesta.

[OpenWrt Wiki] IPv6 firewall examples

openwrt.org

Auttaisiko tämä?

Lisäys: Linkki on väliotsikkoon "Dynamic prefix forwarding", mikä kertoo hieman enemmän ennen linkin avaamista.
Lisäys2: Kokeilin sääntöä OpenWrt:ssä sen verran, että siitä syntyi ihan validin näköinen wildcard mask ip6tables-säännölle. Liikennetestiä en pysty nyt tekemään.

Pitää tuota tutkailla mutta hiukan näytti siltä että ei olis ihan sitä edellenkään jota kaipailen.

 

[ztec]

Nykyisessä ipv4 setupissa sentään modeemit on oletuksena konffittu nattaamaan liikenne ja kotihärvelit ovat suorilta porttiskannauksilta kohtuullisen hyvin suojassa.

Monet sekoittaa NATin ja palomuurin keskenään, niillä on eri funktiot.

 

[JiiPee]

Monet sekoittaa NATin ja palomuurin keskenään, niillä on eri funktiot.

NAT toimii ihan luonnostaan köyhänmiehen palomuurina. Hienosäätöihin vaaditaan sitten muutakin kuin pelkkä natti.

Ja se on aika monella iptables/nftables/mitänäitänyton joka hoitaa niin natin kuin ihan palomuurinkin hommat siellä hienon webguin taustalla.

 

[ztec]

Esim. OVH hosting on niin mölli VPS palveluntarjoa että ne antaa sulle ihan tasan yhden /128 prefixin ipv6 osoitteen mikä myös rikkoo räikeästi speksejä.

Eräs toinen palveluntarjoaja antaa vaikka kuinka monta IPv6 osoitetta, mutta jokainen niistä on /128.

 

[pulatunnus]

NAT toimii ihan luonnostaan köyhänmiehen palomuurina. Hienosäätöihin vaaditaan sitten muutakin kuin pelkkä natti.

Vuosikymmenet on korostettu että NAT ei ole palomuuri, ja sitä se ei ole, ei köyhänkään.
NAT, yhden moneen, toki vaikeuttaa netinkäyttöä josta mielikuva että toimii kuin palomuuri.

Taitaa niissä operaattorien kytkypurkeissakin olla jonkinlainen palomuuri.

 

[JiiPee]

Vuosikymmenet on korostettu että NAT ei ole palomuuri, ja sitä se ei ole, ei köyhänkään.
NAT, yhden moneen, toki vaikeuttaa netinkäyttöä josta mielikuva että toimii kuin palomuuri.

Taitaa niissä operaattorien kytkypurkeissakin olla jonkinlainen palomuuri.

Perus käyttäjälle riittää se että ulkoa ei pääse sisälle ja tämän asian NAT hoitaa siinä kuin palomuurikin. Se on yksinkertaisesti mahdotonta tulla sisään kun olet natin takana ellei sitten palomuurin kanssa tehdä aktiivisesti porttiohjauksia tai peräti automaattisesti upnp:n kanssa.

Mitä muuta tavan kuluttaja tarttee? Kun ei ne edes ymmärrä miten toi natti toimii? Saatikka että osaisivat jotain kehittyneempää filtteröintiä conffata. Se että sulla on joku itkumuuri koneella jossa pitää erikseen hyväksyä joka ikinen OHJELMA että pääseekö se nettiin vai ei, ei todellakaan palvele tavan kuluttajaa. Jopa windowsin oma itkumuuri on välillä hiukan turhan meluisa, puhumattakaan jostain kolmannen osapuolen itkuureista.

Ja jos sitten sattuu käymään niin että se sun kone korkataan, niin ne monesti korkkaa sitten sen muurinkin. Jolloin sellaisen rogue liikenteen ulospäin rajoittamiseen tarttetaan hiukan enemmän osaamista kuin sillä perus jormalla on.

Niissä operaattorin purkeissa on monesti iptablesilla toteutettu nat käytössä ja jos pistätä siltaan sen niin taitaa olla melko yleistä että sen jälkeen purkissa ei tehdä käytännössää mitään muuta filtteröintiä kuin se ettei siihen itse purkin käyttöliittymään pääse ryömimään ulkoverkosta sisään.
Näin se on ainakin noissa kymmenissä purkeissa ollut joita itte olen käyttänyt. Sen takia nyt onkin openwrt viritykset menossa, jospa sillä saisi sillattua liikennettä filteröityä ettei tartte itkumuuria joka koneelle erikseen kun IPv6 ottaa käyttöön.

 

[pulatunnus]

Perus käyttäjälle riittää se että ulkoa ei pääse sisälle ja tämän asian NAT hoitaa siinä kuin palomuurikin. Se on yksinkertaisesti mahdotonta tulla sisään kun olet natin takana ellei sitten palomuurin kanssa tehdä aktiivisesti porttiohjauksia tai peräti automaattisesti upnp:n kanssa.

Missä menee palomuurin ja NATin raja.
NAT rikkoo yhteksiä, mutta yrittää parhaansa mukaan ohjata paketit perille
Palomuuri yrittää suodata ei toivotut paketit.

NATtaavissa reititin palomuureissa toiminallisuuksia on integroitu.

Se miksi tästä kommentoi, johtuu ketjun otsikosta ja siitä että NATia on pidetty turvatekijänä.

Ilman NATia suoraviivaisesti ajatellen palomuurilla paremmat mahkut suoritua tehtävästä, palveluiden mahdollisuus toimia paremmin, vihamieliset parempi torjua.

Se on yksinkertaisesti mahdotonta tulla sisään kun olet natin takana ellei sitten palomuurin kanssa tehdä aktiivisesti porttiohjauksia tai peräti automaattisesti upnp:n kanssa.

Jos siellä ei ole palomuuria, niin se NAT yksinkertaisimillaan ohjaa kaikki paketit perille mitkä osaa/pystyy. "turvallisuuden" tunne tulee sitä että se ei välttämättä tiedä mihin, ei vaan tiedä, ei tiedä onko hyvä vai paha.

Jos siellä on palomuuri, niin kokonaisuus mietitään tarkemmin, onko tämä paketti ok, eli vaikka tietäisi mihin ohjata, niin voidaan tiputtaa.

Tuollainen palomuuritoiminnallisuus voidaan tehdä ilman NATiakin, eli sitä nattia ei tarvita palomuurin tekemiseen.


Edit:

Ei se natti ohjaa yhtään mitään paketteja sisään mitä ei ole pyydetty.

Silloin siinä on jo palomuurimaisia ominaisuuksia, eikä se NAT lisäarvoa siihen tuo, päinvastoin.

En ole tuomitsemassa nattia missä palomuuriominaisuuksia.

Se missä natti ja itkumuuri alkaa sitten erota on se että itkumuurilla voidaan dropata vaikka kaikki UDP liikenne niin sisään kuin ulos menevä. Ja voidaan ulospäin sallia vain tiettyihin portteihin ja osoitteisiin liikenne.

Kotikäytössä harvemmin on tarvetta alkaa noin järeään filtteröintiin paitsi jos on ropelihattu.

Palomuurin puolelle menee jos suodatetaan paketteja joiden oletetaan olevan ei toivottuja.

Ja hyvin toivottavaa ainakin tuon verran ominaisuuksia siinä kotireittimessä on. (siis ei tarvi olla NAT)

Vielä toivottavampaa että huomattavasti kehittyneempi palomuureja, jotka eivät vaadi käyttäjäosaamista.

Edit;
1-monta NAT on vain sen takia että kuluttajille ei ollut jakaa tarpeeksi isoja plokkeja ip osoitteita ja mailma alkoi siihen sopeutuun.

 

[JiiPee]

Jos siellä ei ole palomuuria, niin se NAT yksinkertaisimillaan ohjaa kaikki paketit perille mitkä osaa/pystyy. "turvallisuuden" tunne tulee sitä että se ei välttämättä tiedä mihin, ei vaan tiedä, ei tiedä onko hyvä vai paha.

Ei se natti ohjaa yhtään mitään paketteja sisään mitä ei ole pyydetty. Ei se itkumuurikaan tiedä mitään niiden pakettien sisällöstä mitä liikkuu kun nykyisin aika pitkälti kaikki liikenne on salattua joten ei se pysty mitenkään tietämään että onko se paketti hyvin vai pahis.
Se missä natti ja itkumuuri alkaa sitten erota on se että itkumuurilla voidaan dropata vaikka kaikki UDP liikenne niin sisään kuin ulos menevä. Ja voidaan ulospäin sallia vain tiettyihin portteihin ja osoitteisiin liikenne.

Kotikäytössä harvemmin on tarvetta alkaa noin järeään filtteröintiin paitsi jos on ropelihattu.

Mutta tässä ketjussa aiheesta aika turha jauhaa enempää koska IPv6 verkossa natin käyttöä ei todellakaan suositella yhtään missään paitsi docker käytössä ainakin vielä jokin aika sitten oli vähän pakko koska docker.

 

[pulatunnus]

Ei se natti ohjaa yhtään mitään paketteja sisään mitä ei ole pyydetty.

Silloin siinä on jo palomuurimaisia ominaisuuksia, eikä se NAT lisäarvoa siihen tuo, päinvastoin.

En ole tuomitsemassa nattia missä palomuuriominaisuuksia.

Edit, kopio siirsin aiemma viestin täydennyksesksi. Käyttäjä ei pysty täällä poistaan tai siirtään viestiä.

 

[Pakana]

Mä en oikein ymmärrä miksi tuota "NAT ei korvaa palomuuria" aina itketään. Sanokaapa jokin käytännön esimerkki jossa käytössä on vain NAT. Ehkä tuo olisi mahdollista jos itse vääntäisi reitittimen jostain vanhasta pc raudasta ja väkertäisi siihen pelkän NATin, mutta ei palomuuria. Käytännössä tuossakin tilanteessa se olisi se reitin joka olisi portit levällään internetiin, ja sisäverkko voisi saastua sen reitittimen saastumisen myötä.

Tän topikin kannalta tuo on kuitenkin epäolennaista, kun NATista on juuri päästy eroon.

 

[ztec]

Jos siellä ei ole palomuuria, niin se NAT yksinkertaisimillaan ohjaa kaikki paketit perille mitkä osaa/pystyy. "turvallisuuden" tunne tulee sitä että se ei välttämättä tiedä mihin, ei vaan tiedä, ei tiedä onko hyvä vai paha.

Jep, mulla on full cone ja 1:1 NATtia molempia käytössä ja kumpikaan ei kyllä tarjoa sitä suojaa mitä täysi stateful palomuuri tarjoaa. 1:1 nat vaihtaa vain IP osoitteen, sisään pääsee ihan suoraan. Full cone vaihtaa IPt ja porttinumerot, mutta samaa porttia pitkin pääsee toki myös takaisin päin, kun se on kerrna mapattu ulos päin. Joskus toki tämä on varsin toivottavaa, mm. pelatessa tai torrenttien kanssa, koska helpottaa olennaisesti yhdistämistä toisiin käyttäjiin.

 

[JiiPee]

Silloin siinä on jo palomuurimaisia ominaisuuksia, eikä se NAT lisäarvoa siihen tuo, päinvastoin.

NAT:n lisäarvo on sen helppous. Erittäin helppo tapa blokata kaikki ulkoa tuleva liikenne jota ei ole pyydetty.

 

[kryptonian]

NAT ei silti ole palomuuri, piste.

 

[pulatunnus]

NAT:n lisäarvo on sen helppous. Erittäin helppo tapa blokata kaikki ulkoa tuleva liikenne jota ei ole pyydetty.

Jos haluat yksikertaisest palomuurin väliin, niin laitat siihen sellaisen joka blokkaa ulkoatulevan liikenteen jota ei ole pyydetty. se helppoa ja yrittää ainakin tehdä sitä mitä haluat.

NAT ei sinänsä blokkaa sisääntulevaa liikenenttä, se blokkaamis käsitys perustuu siihen että se ei välttämättä osaa ohjata sitä liikenenttä oikeaan paikkaan. Se taasen on sen NATin ongelma näissä yksi julkinen, monta privaattia toteutuksissa.

Koska yleensä tarvitaan liikenenttä myös sisäänpäin, niin NAT sitten ohjaa sitä sisääntulevaa liikennettä sisäverkkoon parhaansa mukaan, yksinkertaisimillaan puuttumatta (suodattamatta) lainkaan sitä.

Jankkaan tätä amatöörinä, koska ollaan IPv6 ketjussa ja jotkut pitää sitä riskinä koska ei ole NATattu.

IPv6, jos siinä kotipalomuuri nat reittimessä on palomuuri joka päästää sisään vain pyydetyn ulkotulevan liikenteen, niin se on siinä ja turvalisempi kuin pelkkä NAT

IPv6 vs IPv4 yhden julkisen IPn NAT, niin se etu että IPv6 tuleva liikenne on menossa vain siihen yhteen, ei tarvi arpoa minne menossa, vaan se "onko pyydetty" voidaan päätellä sen yhden kohteen osalta. Koska osoitteita on ziljoonia, niin tämä yksi uniikki IP on ei ole yhtä laajalti tiedossa, lähinnä vain reitin ja niiden joiden kanssa yhteydessä.

yksi IPv4 ja NAT, niin jos yksi laite on yhteydessä vihamieliseen kohteeseen, niin siinä vuotaa julkinen IP minkä takana on muutkin kotiverkon laitteet, joilla portteja auki mailmalle. Jos siellä on sitä sälää joka on nettiin yhteydessä, niin portteja on auki, missä laittee kuuntelee.

Ja kun käytetään NAT lyhennettä, niin se yksinkertaismillaan on vain IP muunnossa joka ohjaa kaiken liikenteen perille, silloin se on kaikkein toimivin. Kotikäytöss lähinnä poikkeus.
Mutta muistettava, jotta NAT toimisi, niin niihin on rakenenttu ominaisuuksia millä NAT takana laite pystyy kertomaan sille mitä liikennettä tänne (toki palomuurikin tarvii tiedon mitä tarvii päästää)


NAT helppous kotikäyttäjälle perustuu muuttuvilla julkisilla IP osoitteilla siihen että kotiverkon(sisäverkon) IP:t voi tehdä privaateilla kiinteillä osoitteilla.

 

[JiiPee]

Jankkaan tätä amatöörinä, koska ollaan IPv6 ketjussa ja jotkut pitää sitä riskinä koska ei ole NATattu.

Eli jankkaat vaikkei ole kunnon tietoa?

Oli aika jolloin Win XP saastui jo asennusvaiheessa jos oli verkossa kiinni julkisella osoitteella. Mikäli oli NAT:n takana niin kyseistä saastumista ei tapahtunut.

Koita nyt jo uskoa että se NAT on ihan riittävä palomuuri suurelle osalle. Se NAT lähes poikkeuksetta myös toteutetaan sillä ihan samalla ohjelmalla kuin ne "paremmat" palomuuri fyytsörit. Linuksin tapauksessa se on netfilter.

Ja edelleen: oli kyseessä se ihan OIKEA palomuuri taikka NAT, niin ei ne kumpikaan tiedä niiden pakettien sisällöstä yhtään mitään koska se paketin sisältö on salattu nykyisin lähestulkoon kaikessa liikenteessä. Tai jos tietäävät, niin sitten salaukset on korkattu ja meillä on paljon isompi ongelma kuin onko NAT oikeasti palomuuri vaiko ei, koska kuka tahansa voi sönkiä kenen tahansa liikennettä mielinmäärin.

Voi sen NAT:n toki virittää YHDELLE koneelle niin että se laskee ihan kaiken läpitte, mutta mitä järkeä siinä on? Sama sitten laittaa suoraan julkisella osoitteella se pönttö verkkoon kiinni.
Ainut käyttökohde moiselle viritykselle olisi sellainen täysin korvaamaton purkki joka ei tunne termiä DHCP ja se pitäisi saada julkiseen verkkoon dynaamisella osoitteella.

Sitten joku meni keksimään että on hiton upee juttu kun laitetaan uPnP tuki siihen purkkiin jolloin se windows voi ihan automaagisesti aukoa portteja miten tahtoo. Veikkaan että toi on suurin syy siihen miksi NAT:lla on niin huono maine ja toki sen takia kun operaattorit kun tekee NAT:n niin siellä ei portteja aukaista että juuso pääsee turskaa seedaamaan.

Ja tottakai meillä on tietoturha ongelma kun noi monet purkit laskee IPv6 liikenteen suoraan läpitte. Tämä tuli itsekin havaittua parin purkin kanssa, sen takia poistin IPv6:n pois käytöstä ja tekeillä on openwrt purkki jolla homma pitäisi hoitua. Ei ole vaan vielä käytössä kun purkkiin ei ollut openwrt tukea, joten se piti itte tehä (Onneksi oli klooni purkki niin tuen sai suht pienellä vaivalla) ja nyt on PR vetämässä tuen saamiseksi ihan viralliseen julkaisuun ja välillä tarttenu jotain muutoksia kokeilla niin ei voi purkkia laittaa "tuotantoon".

Noita purkkien valmistajia ei monesti nappaa kovin pitkään tuotteitaan päivitellä. Tuossakin telewell purkissa kerneli 2.6.36 kun nykyisin mennään 5.15.x jotakin. Siinä on jo uutena ollut todella vanha kerneli.
Ilmeisesti joskus 2014/2015 on tuo purkki ollu ns. uusi tuote. Vastaavasti toi kerneli on vuodelta 2011. Onhan siihen todennäköisesti backportattu jotain kriittisiä juttuja, mutta viimeisin firmis on vuodelta 2015, eli ei ole juuri kiinnostanu tukea jatkaa.

Mutta joo. Koulukuntia on useampia ja jotkuu on tiukasti sitä mieltä että NAT ei tuo mitään turvaa, no ei tietenkään tuo jos se on väärin conffattu. Ihan samoin voidaan sanoa palomuurista, jos se on väärin conffattu, niin ei se mitään turvaa tuo.

Itte olen NAT:a käyttänyt vuosikymmeniä eikä minulla ole siitä mitään huonoa sanottavaa. Se toimii varsin loistavasti silloin kun se on conffattu oikein ja rauta joka sitä NAT:n virkaa hoitaa on riittävän tehokas. Oli aikoinaan VDSL2 purkki jossa rauta oli niin lussua että purkista itsestään kun laittoi NAT:n päälle niin nopeudet tippu 100Mbps johonkin 30Mbps.

 

[kryptonian]

Eli jankkaat vaikkei ole kunnon tietoa?

Jankkaatte kyllä molemmat...

Koita nyt jo uskoa että se NAT on ihan riittävä palomuuri suurelle osalle. Se NAT lähes poikkeuksetta myös toteutetaan sillä ihan samalla ohjelmalla kuin ne "paremmat" palomuuri fyytsörit. Linuksin tapauksessa se on netfilter.

Sä voisit uskoa, että NAT EI OLE eikä tule olemaan palomuuri, looppuis se disinformaation levitys.

 

[JiiPee]

Sä voisit uskoa, että NAT EI OLE eikä tule olemaan palomuuri, looppuis se disinformaation levitys.

9.0. Security Considerations

Many people view traditional NAT router as a one-way (session)
traffic filter, restricting sessions from external hosts into their
machines. In addition, when address assignment in NAT router is done
dynamically, that makes it harder for an attacker to point to any
specific host in the NAT domain. NAT routers may be used in
conjunction with firewalls to filter unwanted traffic.

RFC2663:sta joka on vuodelta 1999. Nykyisin NAT on HYVIN monesti osa palomuuria tai palomuuri on osa NAT:a ihan miten vaan.

Lisäksi

Below are some additional security considerations associated with NAT
routers.

1. UDP sessions are inherently unsafe. Responses to a datagram
could come from an address different from the target address
used by sender ([Ref 4]). As a result, an incoming UDP packet
might match the outbound session of a traditional NAT router
only in part (the destination address and UDP port number of
the packet match, but the source address and port number may
not). In such a case, there is a potential security compromise
for the NAT device in permitting inbound packets with partial
match. This UDP security issue is also inherent to firewalls.

Traditional NAT implementations that do not track datagrams on
a per-session basis but lump states of multiple UDP sessions
using the same address binding into a single unified session
could compromise the security even further. This is because,
the granularity of packet matching would be further limited to
just the destination address of the inbound UDP packets.

2. Multicast sessions (UDP based) are another source for security
weakness for traditional-NAT routers. Once again, firewalls face
the same security dilemma as the NAT routers.

Eliih... Samoja ongelmia oli sitten natti taikka firewall.. Eli tähän pätee se että mikä haisee ja maistuu paskalle, se on sillloin sitä itteään.

Mutta sovitaan nyt sitten sinun mieliksi että NAT ei ole palomuuri. Piste.