Useampi julkinen IP yhdestä tökkelistä kytkimellä?

  • Keskustelun aloittaja Keskustelun aloittaja jarif
  • Aloitettu Aloitettu
jarif

jarif

Liittynyt
01.01.2017
Viestejä
447
Mulla on Telian Inteno DG301AL reitittävänä Telian kuitu/VDSL2 -liittymässä. Yksi portti on sillattavissa, ja näin on tehty, ja siinä on OPNsense reititinkone.

Minulla on nyt siis kaksi julkista IP:tä tuossa liittymässä. Tuli vaan mieleen, että jos laitan siihen DMZ-porttiin kytkimen, ja sen kautta OPN-sensen multiport NICcin useamman sillatun kytkennän, niin toimiiko?

Haluaisin mielelläni niin monta julkista IP:tä kuin mahdollista, jotta ei tarvitsi niin paljon turvautua reverse proxyihin (kun on tarvetta erilaisille reverse proxy-softille).
 
Kysymyskö siis se että saadaanko kytkimen avulla siitä yhdestä reiästä pihalle useampi kuin yksi IP?
Kyllä, näinhän se pitäisi toimia.
Kuluttajaliittymissä yleensä se 5kpl dynaamista IP:tä joten jos Inteno pysyy reitittävänä niin se nappaa yhden, kaveriksi 5port tyhmä kytkin niin tästä sitten neljä muuta toosaa jotka on kiinni siinä kytkimessä saa sen julkisen IP:n itselleen.​

Kokeile ja raportoi toimiko.
 
jarif sanoi:
kytkimen, ja sen kautta OPN-sensen multiport NICcin useamman
Napsauta laajentaaksesi...
:confused:
Siiskö
Koodi: 
                _
               / nic1
modeemi--kytkin--nic2
               \_nic3
jossa kaikki kolme nic:iä ovat yhdessä OPNsense-koneessa?

Siinä on sitten kolme saman aliverkon IP:tä samassa koneessa. Mahdollista, mutta "mielenkiintoista".
Melkein yhtä helposti* laittaa yhteen nic:iin kolme IP:tä, jolloin kytkintä ei tarvita.


*Mikäli dynaamiset osoitteet ovat aidon dynaamisia, eli ne viisi IP:tä eivät ole täsmälleen sinulle, sitten kolmen IP:n asettaminen (staattisesti) samaan nic:iin ei toimi. (Oletan kuitenkin, että OPNsense osaa aliakset.)
 
Sitä en tiedä että osaako se OPNsense alias-osoitteita yhdelle NICille, mutta en ole havainnut siinä semmosta.

Tuo kytkin tulisi olemaan 8-porttinen hallittu kytkin, joten sen kanssa on aika lailla vapaus tehdä ihan mitä vaan eli ei ne välttis ole edes samassa subnetissa ne osoitteet.

Osoiteet on tosiaan aidosti Telian DHCPsta, joten en minä voi konffailla mitään kummia noille nikeille.

Kyllä tästä hyvä tulee, kunhan kerkiää viritellä. Pitää mennä harkiten kun talouden netti ei saa olla kumossa juurikaan, ja tuo OPNsense on nyt DHCP ja myös DNS-palvelin, ja joudun sen ajamaan alas jotta saan siihen 5 porttisen NICin jonka kesällä ostin mutta jota en ole vielä tarvinnut (koneessa on nyt 2 norminiccia).

DHCP:ta mulla ennen hoitu pari raspia (master/slave dhcpd) ja voin sen laittaa tulille koneen rassaamisen ajaksi ja DNS onnistuu myös hyvin olemassa olevilla värkeillä ilman OPNsensea.
 
jarif sanoi:
... ei ne välttis ole edes samassa subnetissa ne osoitteet.

Osoiteet on tosiaan aidosti Telian DHCPsta, joten en minä voi konffailla ...
Napsauta laajentaaksesi...
Kun Telian DHCP antaa osoitteet, Telia päättää ovatko ne samassa subnetissä. Veikkaan, että kyllä. Aika kumma suoritus, jos samaan asuntoon, saman piuhan kautta tarjoisivat monta verkkoa.

Kytkimen ja OPNsensen välillä voi tietenkin olla erillinen yhteys/aliverkko kytkimen hallintaa varten, josta Telia ei koskaan kuule.
 
keskiverto sanoi:
Kun Telian DHCP antaa osoitteet, Telia päättää ovatko ne samassa subnetissä. Veikkaan, että kyllä. Aika kumma suoritus, jos samaan asuntoon, saman piuhan kautta tarjoisivat monta verkkoa.

Kytkimen ja OPNsensen välillä voi tietenkin olla erillinen yhteys/aliverkko kytkimen hallintaa varten, josta Telia ei koskaan kuule.
Napsauta laajentaaksesi...
Jep, ilman muuta ne julkiset ipt on telian mielen mukaan ja samasta poolistahan se heidän DHCP ne jakaa.


Lähetetty minun Nexus 6P laitteesta Tapatalkilla
 
Nyt on rauta paikallaan, ja palomuuri tunnistaa portit. Vaan jos laittaa useamman portin dhcp:lle tuohon VLANiin konffattuun putkeen niin crash. fsck:ta se ajaa sitten bootin jälkeen, vai mikä se mahtaa ollakaan BSD:ssä. Kaikki portit on kyllä UP bootissakin, mutta DHCP-tappaa systeemin.

Pitää tutkia konffia, josko sen saisi olemaan laittamatta mitään ylimääräisiä automaattisia routeja noihin ettei sekoa. 1:n portin laitoin WANiksi ja se näytti toimivan kyllä.
 
Juu ei. Boot looppi siitä syntyi. Kun se bootissa yrittää konffata WAN2 -porttia niin crashaa. Bah.
 
FireExit sanoi:
Minkälainen kortti, mistä ostit ja paljonko tuli hintaa? Jos saa udella :D
Napsauta laajentaaksesi...

Huuto.NETistä ostin Se on joku Intel mutta en muista muuta kun Huutonettikään ei säilytä historiaa kaupoista näköjään...

PCi-Express kortti kumminkin ja 4 porttia siinä on.


t. jarif
 
HP:n Officeconnect kytkimissä olisi säätöjä joilla tuo voisi ehkä onnistua, mutta en nyt ala arvailemaan kun en kehittyneempää verkkotekniikkaa tunne, vaan odottelen ettö josko joku tietävä osaisi antaa vinkkejä...
 
Läksin kumminkin kokeilemaan, ei kai se siitä rikki mene.

Laitoin jokaisen portin joka tulee OPNsenseen kiinni kytkimestä (WANiin liittyvät siis) eri VLAN-tagilla. Konffasin samat VLAN-tagit myös OPNsensen, ja modeemille menevä kytkimen portti Tagged, muut untagged.

Ei se nyt kaadu tuo hässäkkä, mutta ei myöskään liiku mitään. Portit ei saa IP-osoitetta ISP:ltä eli ne vain ei näy.
 
Niin eikös se vaadi myös operaattorin päähän portin joka konffattu tagged modeen ja myös ne vlanit jotka sinulla on käytössä, operaattori tuskin lähtee sääteleen omia palveluitaan jos sitä ei ole tuotteistettu.
 
Joo sitä mietin että meneekö ne vlanit ihan sinne asti. Eikö se mun routeri (OPNsense) voisi hanskata homman ihan issekseen... Ilmeisesti ei.
 
Palautin asetuksen backupista yhteen WAN-porttiin ja ei mitään VLANeja.

Mutta hei! Ei se WAN nouse vieläkään. Voisiko olla että tämä mun neliporttinen verkkokorttikortti ei nousekaan FreeBSD:ssä ihan tuosta vaan tulille?

Tällainen: Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev. 0x004101

jarif@wellington:~ % pciconf -lv | grep -A8 -i broadcom
vendor = 'Broadcom Corporation'
device = 'NetXtreme BCM5721 Gigabit Ethernet PCI Express'
class = network
subclass = ethernet
xl0@pci0:8:1:0: class=0x020000 card=0x100010b7 chip=0x920010b7 rev=0x78 hdr=0x00
vendor = '3Com Corporation'
device = '3c905C-TX/TX-M [Tornado]'
class = network


Tolla 3Comin vanhalla satamegaisella se WAN kyllä toimi, mutta se ei nyt ole käytössä vaan letku on tossa Nextremessä...
 
Useampi IP yhdessä interfacessa ei sinällänsä ole mikään ihme juttu, mutta eipä taida onnistua DHCP:llä. En tiedä yhtään dhcp clientiä mikä hakisi useamman IP:n interfaclle enkä yhtään DHCP palvelinta mikä antaisi samalle MAC osoitteelle useamman IP:n.

En tietä miten ylensäkään palomuureissa on ajateltu edes mahdollisuutta pitää useampi interface dhcp:llä ja sen päälle reititys ja nattaus sääntöjen teko näiden päälle..
 
Obi-Lan sanoi:
Useampi IP yhdessä interfacessa ei sinällänsä ole mikään ihme juttu, mutta eipä taida onnistua DHCP:llä. En tiedä yhtään dhcp clientiä mikä hakisi useamman IP:n interfaclle enkä yhtään DHCP palvelinta mikä antaisi samalle MAC osoitteelle useamman IP:n.

En tietä miten ylensäkään palomuureissa on ajateltu edes mahdollisuutta pitää useampi interface dhcp:llä ja sen päälle reititys ja nattaus sääntöjen teko näiden päälle..
Napsauta laajentaaksesi...
Vaikkapa linuxin dhclient toimii kyllä, senkun lisäät eth0:virt1 ja eth0:virt2 devicet ja asetat niille eri mac-osoitteet ja requestaat ip:t.

Itselläni oli joskus muinoin opiskelijasolussa linux-boxi jakamassa nettiä juuri noin. Haettiin ulkoverkon kortille kolme eri ip:tä soneran bridgetetyn dsl:n yli ja kolmelle sisäverkon koneelle oli ns. Hard-nat ja täten ulkoinen ip käytössä, samalla kun kaikki toimivat kivasti myös sisäverkossa keskenään.
 
Obi-Lan sanoi:
Useampi IP yhdessä interfacessa ei sinällänsä ole mikään ihme juttu, mutta eipä taida onnistua DHCP:llä. En tiedä yhtään dhcp clientiä mikä hakisi useamman IP:n interfaclle enkä yhtään DHCP palvelinta mikä antaisi samalle MAC osoitteelle useamman IP:n.

En tietä miten ylensäkään palomuureissa on ajateltu edes mahdollisuutta pitää useampi interface dhcp:llä ja sen päälle reititys ja nattaus sääntöjen teko näiden päälle..
Napsauta laajentaaksesi...
Hei, tässä tavoitellaan 4 erillistä julkista Iptä 4 erilliselle kortille. Tämä yhden sillatun portin kautta, mutta sillallahan ei IPtä ole joten...


Lähetetty minun Nexus 6P laitteesta Tapatalkilla
 
Joskus testasin opiskeluaikaan Soneran liittymälä tuota et yhellä verkkokortilla että yritin saada useemmalle sub-if:lle eri osotteet mut en kyllä saanu muistaakseni toimimaan. Taitaa se DHCP-palvelin kattoa sitä hw MAC-osotetta vaan ja antaa yhen. Toki jos on useempi verkkokortti niin luulis niitä sit saavan sen rajan mitä liittymäkohtasesti optio82 sallii.
 
Obi-Lan sanoi:
Useampi IP yhdessä interfacessa ei sinällänsä ole mikään ihme juttu, mutta eipä taida onnistua DHCP:llä. En tiedä yhtään dhcp clientiä mikä hakisi useamman IP:n interfaclle enkä yhtään DHCP palvelinta mikä antaisi samalle MAC osoitteelle useamman IP:n.
Napsauta laajentaaksesi...

Ihan iloisestihan dhclient haki yhdeltä dhcpd:ltä toisenkin IP:n yhdelle interfacelle, kun vaan käski eri client-identifierillä hakemaan. Että miksipä ei onnistuisi geneerisesti..

Koodi: 
# dhclient -1 -d -v -C c4:85:08:12:34:56 wlp2s0
Internet Systems Consortium DHCP Client 4.3.5
Copyright 2004-2016 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/wlp2s0/c4:85:08:a6:5e:28
Sending on   LPF/wlp2s0/c4:85:08:a6:5e:28
Sending on   Socket/fallback
DHCPDISCOVER on wlp2s0 to 255.255.255.255 port 67 interval 6 (xid=0xe39eb1f9f)
DHCPREQUEST on wlp2s0 to 255.255.255.255 port 67 (xid=0xe39eb1f9f)
DHCPOFFER from 192.168.0.1
DHCPACK from 192.168.0.1 (xid=0xe39eb1f9f)
bound to 192.168.0.136 -- renewal in 16569 seconds.

$ ip a s wlp2s0
2: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether c4:85:08:a6:5e:28 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.130/24 brd 192.168.0.255 scope global dynamic wlp2s0
       valid_lft 31239sec preferred_lft 31239sec
    inet 192.168.0.136/24 brd 192.168.0.255 scope global secondary dynamic wlp2s0
       valid_lft 43093sec preferred_lft 43093sec
 
Thanks calm! Luulen että tällä nippelitiedolla pääsen taas eteenpäin!

Kunhan paneudun asiaan taas ja boottaan sen palomuurin. Ehkä vkl.
 
jarif sanoi:
No tuo kirjautuminen ei mitenkään liity julkisen IP:n määritelmään
Napsauta laajentaaksesi...
liittyy hyvinkin vahvasti. Julkinen IP on tunnettu mistä tahansa, eikä vaihdu. Reverse proxy, nobile ip ja muut vastaavat vaativat julkisella IP osoitteella toimivan hostin jotta välitystiedot löytyvät. Endpointit toki voivat olla harmaita osoitteita.
 
jive sanoi:
liittyy hyvinkin vahvasti. Julkinen IP on tunnettu mistä tahansa, eikä vaihdu. Reverse proxy, nobile ip ja muut vastaavat vaativat julkisella IP osoitteella toimivan hostin jotta välitystiedot löytyvät. Endpointit toki voivat olla harmaita osoitteita.
Napsauta laajentaaksesi...
Nuo asiat jotka listasit EI ole julkisen IP:n määritelmässä.


Lähetetty minun Nexus 6P laitteesta Tapatalkilla
 
Asioita julkisesta IP:stä, kun tätä asiaa nyt ryhdyttiin hieromaan:

- julkinen IP-osoite on IP-osoite, jonka reititys ja näkyvyys on sallitty Internetissä.
- Ei julkisia osoitteita on muutama sarja, 192.168.0.0/24, 10.0.0.0/8, 172.16.0.0/24 subnetit.
- Reverse proxy on sovellustason verkkotekniikka, jota voidaan käyttää verkossa riippumatta siitä onko IP-osoite sisäinen vai julkinen. Itsellä on näitä käytössä runsaasti molemmissa verkkotyypeissä. Useimmat ihmiset eivät tällaista tarvitse yhtään mihinkään, eivätkä edes tiedä koko tekniikasta yhtään mitään.
- "IP on tunnettu mistä tahansa, eikä vaihdu" on hölynpölyä. Julkinen IP-osoite useimmille tarkoittaa vaihtuvaa IP-osoitetta, eikä kiinteätä IP-osoitetta usein edes myydä kotitalouksille tarkoitettuihin liittymiin.
- Tässä on nyt on jotenkin sekoitettu asioina palvelimen pitäminen ja IP-osoitteiden luokittelut. On triviaalia ylläpitää palvelinta Internernetissä, vaikka ei olisi käytössä kiinteätä IP-osoitetta.
- kiinteän julkisen IP-osoitteen ehkä tärkein käyttötarkoitus on SMTP-palvelimen ylläpito. Tällöin tarvitaan myös rDNS-määritys nimipalveluun, jotta palvelin voisi osallistua postiliikenteeseen täysivaltaisena yhteisön jäsenenä.
- jonkun satunnaisen websiten tai telnet-portin ylläpito onnistuu mainiosti ilman kiinteätä IP-osoitetta, kunhan DNS näyttää aina oikean kulloisenkin osoitteen halutulle nimelle.

Esimerkki omasta Nextcloud -palvelimestani: https://cloud.bitwell.fi/

1. bitwell.fi DNS hoidetaan Cloudflaressa, ja osoitteet on kaikki kiinteitä, lukuunottamatta osoitetta cloud.bitwell.fi, joka on Alias (CNAME) toiseen osoitteeseen: cloud.fredriksson.dy.fi

jarif@www ~]$ host cloud.bitwell.fi
cloud.bitwell.fi is an alias for nextcloud.fredriksson.dy.fi.
nextcloud.fredriksson.dy.fi has address 86.115.206.23

2. cloud.fredriksson.dy.fi toimii virtuaalikoneena omassa kotiverkossani, ja sen julkinen IP määrittyy Telian DHCP-palvelimelta kuten kuluttajaliittymien osoitteet määrittyy. Käytän kuitenkin suomalaista dy.fi -palvelua, ja modeemini on ohjeistettu päivittämään kulloinenkin julkinen IP k.o. palveluun.

Cloudflare ja Bitwell.fi domain ei tue dynaamista DNS:ää, joka tässä tapauksessa kumminkin on ratkaisu ongelmaan.

Tämä ratkaisu ei kuitenkaan yhtään mitenkään liity julkisen IP:n määritelmään. Puhutaan pähkinäistä ja mustekaloista. Joku on nyt saattanut oppia nämä kaksi käsitettä samaan ongelmaansa liittyen, kun on ollut tarve saada "telnet" Internettiin.

Lopetan vänkäämisen tämän julkisen IP:n osalta tähän. Tämä ketju ei ollut sitä kysymystä varten, vaan ihan muuta.
 
Viimeksi muokattu:
jarif sanoi:
- "IP on tunnettu mistä tahansa, eikä vaihdu" on hölynpölyä. Julkinen IP-osoite useimmille tarkoittaa vaihtuvaa IP-osoitetta, eikä kiinteätä IP-osoitetta usein edes myydä kotitalouksille tarkoitettuihin liittymiin.
Napsauta laajentaaksesi...
Tässä kohtaa menin harhaan, oletin että kysymys oli alunperin nimenomaan yllä olevassa määritelmässä kiinteäksi kutsutuista osoitteista. Sekin kyllä onnistuu, mutta ei ihan helposti. Pahoittelen ketjun haaroittamista. Minulle jullkinen ja kiinteä tarkoittavat samaa asiaa.
 
jarif sanoi:
Asioita julkisesta IP:stä, kun tätä asiaa nyt ryhdyttiin hieromaan:

- julkinen IP-osoite on IP-osoite, jonka reititys ja näkyvyys on sallitty Internetissä.
- Ei julkisia osoitteita on muutama sarja, 192.168.0.0/24, 10.0.0.0/8, 172.16.0.0/24 subnetit.
- Reverse proxy on sovellustason verkkotekniikka, jota voidaan käyttää verkossa riippumatta siitä onko IP-osoite sisäinen vai julkinen. Itsellä on näitä käytössä runsaasti molemmissa verkkotyypeissä. Useimmat ihmiset eivät tällaista tarvitse yhtään mihinkään, eivätkä edes tiedä koko tekniikasta yhtään mitään.
- "IP on tunnettu mistä tahansa, eikä vaihdu" on hölynpölyä. Julkinen IP-osoite useimmille tarkoittaa vaihtuvaa IP-osoitetta, eikä kiinteätä IP-osoitetta usein edes myydä kotitalouksille tarkoitettuihin liittymiin.
- Tässä on nyt on jotenkin sekoitettu asioina palvelimen pitäminen ja IP-osoitteiden luokittelut. On triviaalia ylläpitää palvelinta Internernetissä, vaikka ei olisi käytössä kiinteätä IP-osoitetta.
- kiinteän julkisen IP-osoitteen ehkä tärkein käyttötarkoitus on SMTP-palvelimen ylläpito. Tällöin tarvitaan myös rDNS-määritys nimipalveluun, jotta palvelin voisi osallistua postiliikenteeseen täysivaltaisena yhteisön jäsenenä.
- jonkun satunnaisen websiten tai telnet-portin ylläpito onnistuu mainiosti ilman kiinteätä IP-osoitetta, kunhan DNS näyttää aina oikean kulloisenkin osoitteen halutulle nimelle.

Esimerkki omasta Nextcloud -palvelimestani: https://cloud.bitwell.fi/

1. bitwell.fi DNS hoidetaan Cloudflaressa, ja osoitteet on kaikki kiinteitä, lukuunottamatta osoitetta cloud.bitwell.fi, joka on Alias (CNAME) toiseen osoitteeseen: cloud.fredriksson.dy.fi

jarif@www ~]$ host cloud.bitwell.fi
cloud.bitwell.fi is an alias for nextcloud.fredriksson.dy.fi.
nextcloud.fredriksson.dy.fi has address 86.115.206.23

2. cloud.fredriksson.dy.fi toimii virtuaalikoneena omassa kotiverkossani, ja sen julkinen IP määrittyy Telian DHCP-palvelimelta kuten kuluttajaliittymien osoitteet määrittyy. Käytän kuitenkin suomalaista dy.fi -palvelua, ja modeemini on ohjeistettu päivittämään kulloinenkin julkinen IP k.o. palveluun.

Cloudflare ja Bitwell.fi domain ei tue dynaamista DNS:ää, joka tässä tapauksessa kumminkin on ratkaisu ongelmaan.

Tämä ratkaisu ei kuitenkaan yhtään mitenkään liity julkisen IP:n määritelmään. Puhutaan pähkinäistä ja mustekaloista. Joku on nyt saattanut oppia nämä kaksi käsitettä samaan ongelmaansa liittyen, kun on ollut tarve saada "telnet" Internettiin.

Lopetan vänkäämisen tämän julkisen IP:n osalta tähän. Tämä ketju ei ollut sitä kysymystä varten, vaan ihan muuta.
Napsauta laajentaaksesi...


CloudFlare muuten tukee nimipalvelintietueiden päivittämistä rajapinnan yli, eli periaattessa näin tukee sitä DynDNS:sää. Eihän DynDNS muuten ole kuin rajapinta minne lähetetään tieto uusimmasta IP:stä ja päivittää sen nimipalvelimeen.
 
jive sanoi:
Tässä kohtaa menin harhaan, oletin että kysymys oli alunperin nimenomaan yllä olevassa määritelmässä kiinteäksi kutsutuista osoitteista. Sekin kyllä onnistuu, mutta ei ihan helposti. Pahoittelen ketjun haaroittamista. Minulle jullkinen ja kiinteä tarkoittavat samaa asiaa.
Napsauta laajentaaksesi...

Mulla on sisäverkon osoitteetkin käytännössä kiinteitä, kun ne on määritetty staattisesti DHCP-palvelimeeni.

Tommoset henkilökohtaiset määritykset ja niiden julistaminen saattaa jatkossakin tuoda mielenkiintoisia vääntöjä ;D
 
calm sanoi:
Ihan iloisestihan dhclient haki yhdeltä dhcpd:ltä toisenkin IP:n yhdelle interfacelle, kun vaan käski eri client-identifierillä hakemaan. Että miksipä ei onnistuisi geneerisesti..

Koodi: 
# dhclient -1 -d -v -C c4:85:08:12:34:56 wlp2s0
Internet Systems Consortium DHCP Client 4.3.5
Copyright 2004-2016 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/wlp2s0/c4:85:08:a6:5e:28
Sending on   LPF/wlp2s0/c4:85:08:a6:5e:28
Sending on   Socket/fallback
DHCPDISCOVER on wlp2s0 to 255.255.255.255 port 67 interval 6 (xid=0xe39eb1f9f)
DHCPREQUEST on wlp2s0 to 255.255.255.255 port 67 (xid=0xe39eb1f9f)
DHCPOFFER from 192.168.0.1
DHCPACK from 192.168.0.1 (xid=0xe39eb1f9f)
bound to 192.168.0.136 -- renewal in 16569 seconds.

$ ip a s wlp2s0
2: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether c4:85:08:a6:5e:28 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.130/24 brd 192.168.0.255 scope global dynamic wlp2s0
       valid_lft 31239sec preferred_lft 31239sec
    inet 192.168.0.136/24 brd 192.168.0.255 scope global secondary dynamic wlp2s0
       valid_lft 43093sec preferred_lft 43093sec
Napsauta laajentaaksesi...

Ei se tolla onnistu. FreeBSD menee nurin heti, jos saa dhclientillä kaksi IP:tä siitä sillatusta portista.
 
jarif sanoi:
Ei se tolla onnistu. FreeBSD menee nurin heti, jos saa dhclientillä kaksi IP:tä siitä sillatusta portista.
Napsauta laajentaaksesi...
Perustesti:
1. dhclient portista A. Portilla A on macA, tullee IP-A, verkko X, linklocal reitti X:ään ja oletusreitti Y. Portilla B ei thedä mitään.
2. dhclient portista B. Portilla B on macB, tullee IP-B, verkko X, linklocal reitti X:ään ja oletusreitti Y. Portilla A ei thedä mitään.

Jos molemmat onnistuvat, mitä halutaan molempia käyttäen?
* Portille A IP-A
* Portille B IP-B
* linklocal reitti X:ään kumman kautta?
* oletusreitti Y kumman kautta?
Toisin sanoen, toinen dhclient ei saa hyödyntää muuta kuin IP:n DHCP:ltä; ei prefiksiä eikä reittejä.
 
Juurikin noin. Miten rajataan OPT1, OPT2 ja OPT3 niin että ne hakee vain IP:n, ei muuta? Kun siis LAN ja WAN -portit toimii niinkuin ne normaalisti toimii. Nuo OPTx portit olisi ihan ylimääräisiä eikä saisi häiritä varsinaista toimintaa.
 
Lainataan vähän topiccia. Onnistuuko ketjun idea pfSensellä? Eli yhdestä fyysisestä portista pitäisi useampi WAN saada pfSenselle. Olen tehnyt tuon virtuaaliympäristössä missä virtuaalikortteja voi helposti lisätä, mutta nyt pyörii paljaalla metallilla.
 
bindi sanoi:
Lainataan vähän topiccia. Onnistuuko ketjun idea pfSensellä? Eli yhdestä fyysisestä portista pitäisi useampi WAN saada pfSenselle. Olen tehnyt tuon virtuaaliympäristössä missä virtuaalikortteja voi helposti lisätä, mutta nyt pyörii paljaalla metallilla.
Napsauta laajentaaksesi...

No FreeBSD siinä pfsensen alla kuitenkin on joten joo kyllähän se pitäis. Testaa luoda sub if ja keksi sille joku uus MAC-osote minkä jälkeen pistät sen huhuilemaan DHCP:llä osotetta. Samaan tapaan joskus linuxilla taisin testailla mut tais tosiaan kusta siihen kun en feikannu sitä erillaista MAC-osotetta.
 
ja mitenköhän tuo käytännössä tehdään? vlaneilla koitin mutta niiden maccia ei voi muuttaa, kaikilla on sama.
 
bindi sanoi:
ja mitenköhän tuo käytännössä tehdään? vlaneilla koitin mutta niiden maccia ei voi muuttaa, kaikilla on sama.
Napsauta laajentaaksesi...

No googlella kantsii ohjeita toki ettiä en muista ulkoo millä nimellä se verkkokortti nyt FreeBSD osalta onkaan mut olkoon vaikka ed0 niin
esim. "ifconfig ed0:0 10.10.10.1 netmask 255.255.255.0 up" tuolleen taitaa sit mennä kiintees osote siihen subinterfaceen. Keksis siihen sit jollaki namiskalla eri MAC-osotteen ja DHCP:llä IP-osotteen haku.
 
keskiverto sanoi:
'request' tuolla: dhclient.conf(5): DHCP client config file - Linux man page

FreeBSD:n vastaava sivu näyttää lyhyemmältä. Joko joku on jättänyt kirjoittamatta, tai toteutuskin on suppeampi.
Napsauta laajentaaksesi...

Tuollahan näyttäisi olevan "pseudo"-avainsanan kohdalla melko suora kuvaus siitä miten saadaan haettua samalle verkkoliitännälle toinenkin IP-osoite DHCP:llä.

Tuolla tosin sanotaan: "The client script for the pseudo-interface should not configure the interface up or down..." mutta tulkitsisin sen tarkoittavan että pseudo-verkkoliitännän skriptin ei pitäisi koskea "emo"-verkkoliitännän asetuksiin.

Kokeilemalla varmaan näkee hilaako tuo pseudo-asetus automaattisesti toissijaisen osoitteen pystyyn samaan tyyliin kuin pulshu tuossa ylempänä esitti, vai pitääkö se skriptata itse.
 
Nostetaas vanhaa aihetta. Itse tarvisin seuraavanlaiseen systeemiin askelmerkit

internet - ISP-bridgerouter HEADOFFICE (publicip1-publicip5) ->
raspi4 ubuntu server HEADOFFICE ->
tunnel over internet (GRE/l2tp/openvpn?) ->
Router1 (openwrt, edgerouter or some) BRANCHOFFICE ->
Customerdevice BRANCHOFFICE publicip5

ohjeita on miljoona toteutuksesta, mutta käsittelee lähes aina site-to-site versiota, jossa yhdistetään kaksi privaattiverkkoa. Nyt halutaan että BRANCHOFFICEssa pystytään leasaamaan ISP:n dhcpeestä osoite suoraan.

tai sitten en osaa hahmottaa asiaa, ja toteutus vaatii privaattiverkot HEAD ja BRANCH officeen että tämän saa toteutettua. ISP dhcp asetuksiin ei tietysti ole pääsyä. DHCP-relayn konffiminen voi olla mahdotonta, tietämättä ISP:n dhcpeen sieluelämää

Kaikki konffi pitäisi olla raspi4(HEAD) ja router1(BRANCH) laitteissa. jotta mikä vaan Customerdevice(BRANCH) saa julkisen iipeen suoraan ISPn dhcpeeltä tunnelin läpi
 
starma2 sanoi:
Nostetaas vanhaa aihetta. Itse tarvisin seuraavanlaiseen systeemiin askelmerkit

internet - ISP-bridgerouter HEADOFFICE (publicip1-publicip5) ->
raspi4 ubuntu server HEADOFFICE ->
tunnel over internet (GRE/l2tp/openvpn?) ->
Router1 (openwrt, edgerouter or some) BRANCHOFFICE ->
Customerdevice BRANCHOFFICE publicip5

ohjeita on miljoona toteutuksesta, mutta käsittelee lähes aina site-to-site versiota, jossa yhdistetään kaksi privaattiverkkoa. Nyt halutaan että BRANCHOFFICEssa pystytään leasaamaan ISP:n dhcpeestä osoite suoraan.

tai sitten en osaa hahmottaa asiaa, ja toteutus vaatii privaattiverkot HEAD ja BRANCH officeen että tämän saa toteutettua. ISP dhcp asetuksiin ei tietysti ole pääsyä. DHCP-relayn konffiminen voi olla mahdotonta, tietämättä ISP:n dhcpeen sieluelämää

Kaikki konffi pitäisi olla raspi4(HEAD) ja router1(BRANCH) laitteissa. jotta mikä vaan Customerdevice(BRANCH) saa julkisen iipeen suoraan ISPn dhcpeeltä tunnelin läpi
Napsauta laajentaaksesi...

Ootko kysyny ISP:ltä, että onko mahdollista, että he tiputtavat omasta reitittimestään DHCP- ja DNS-palvelut pois päältä ja se toimisi vain pelkkänä siltana (bridge) [? Se kun nyt yleisestikin helpottaa verkottamista, kun ei tarvitse kysellä ISP:ltä jokaisesta IP-osoitteesta ja DNS-nimestä... Se muutos tosin maksaa kerran, ainakin kun ite kysyin viime duunipaikassa.

Ja sen lisäksi kun (sen mitä ymmärsin noista... nuolista (tyhjyyteen?). Onko toi Raspi4 jotenkin kriittisessä? paikassa? Mikäli noin on, niin silloin kattelisin tarkasti mitä softaa pyörittäisin siinä = kykeneekö softa High-availabilityyn yhden LAN-portin kautta (epäilen), jos ei, niin miettisin myös sijoittamista uuteen rautaan.
 
FireExit sanoi:
Ootko kysyny ISP:ltä, että onko mahdollista, että he tiputtavat omasta reitittimestään DHCP- ja DNS-palvelut pois päältä ja se toimisi vain pelkkänä siltana (bridge) [? Se kun nyt yleisestikin helpottaa verkottamista, kun ei tarvitse kysellä ISP:ltä jokaisesta IP-osoitteesta ja DNS-nimestä... Se muutos tosin maksaa kerran, ainakin kun ite kysyin viime duunipaikassa.

Ja sen lisäksi kun (sen mitä ymmärsin noista... nuolista (tyhjyyteen?). Onko toi Raspi4 jotenkin kriittisessä? paikassa? Mikäli noin on, niin silloin kattelisin tarkasti mitä softaa pyörittäisin siinä = kykeneekö softa High-availabilityyn yhden LAN-portin kautta (epäilen), jos ei, niin miettisin myös sijoittamista uuteen rautaan.
Napsauta laajentaaksesi...

ISPeen reititin on bridge.

Tämä on ns. "pilotti" ja tulee satunnaiseen käyttöön. Älkää murehtiko raudasta/sijoituspaikasta. Voidaan käyttää mitä vaan.

Yritin emuloida tuota open-vpn site-to-site ohjeella, mutta dhcp-kyselyt ei tule läpi/ei kulje oikein Branch-officeen, tai sitten tein sen väärin.
 
selvennykseksi vielä. HEADOFFICE on autotalli1 Kouvola(kuituliittymä 5kpl public ip)
BRANCHOFFICE on autotalli2 oulu(telia 4g opengate)
 
Tuo kuulostaa vähän siltä että tarvitsisit jotain "Layer-2 VPN"-tekniikkaa. Mutta kun tuolla hakusanalla lähtee etsimään, alkaa saman tien tulla vastaan juttua MPLS:stä ja Ciscon tai Juniperin laitteista, eli taitaa olla isojen poikien leikkejä nuo.

Jos nyt kuitenkin saisit tuollaisen aikaan, kannattaa huomata että kaikki BRANCHOFFICEn liikenne pitää sitten kierrättää HEADOFFICEn kautta ennen kuin sitä päästetään "ulkomaailmaan", koska vaikka sinulla olisi sama internet-operaattori käytössä molemmissa OFFICEissa, verkko on todennäköisesti segmentoitu niin että Kouvolan kuituliittymiin jaellut IP-osoitteet eivät reitity Ouluun operaattorin puolesta sitten millään.
 
En keksi miten onnistuisi edes isojen poikien vehkeillä tuo, että tunneloidaan WAN reunan L2 liikenne samaan aikaan kun headofficen muurilla on oma jalka samassa verkossa. Open Source vehkeistä Vyattassa on joku toteutus millä saa enkapsuloitua L2 liikenteen L3 päälle https://docs.vyos.io/en/equuleus/configuration/interfaces/l2tpv3.html

Tosin en suorilta keksi mitä iloa siitä on, että sillä raspilla olisi omassa verkkokorissa julkinen IP. Itse tekisin 1-to-1 NAT:illa
 
Kiitos vastauksista. Ciscon GRE-tunnelointi ilmeisesti osaisi ko. asian tehdä.

//tunneloidaan WAN reunan L2 liikenne samaan aikaan kun headofficen muurilla on oma jalka samassa verkossa. //
Tätä lausetta koitin saada aikaan, mutta en onnistunut. Jalkoja voidaan lisätä, jos siitä on apua

Branchofficessa (Oulu) on bulk-laitteisto, joka voidaan konfiguroida käyttöön ainoastaan Headofficen (Kouvola) WANin takaa (publicip). Tämä olisi mukava tehdä Oulussa, ettei bulk-laitteistoa tarvitse siirtää fyysisesti Kouvolaan konfigurointia varten.
 
telcoM sanoi:
Tuo kuulostaa vähän siltä että tarvitsisit jotain "Layer-2 VPN"-tekniikkaa. Mutta kun tuolla hakusanalla lähtee etsimään, alkaa saman tien tulla vastaan juttua MPLS:stä ja Ciscon tai Juniperin laitteista, eli taitaa olla isojen poikien leikkejä nuo.
Napsauta laajentaaksesi...

Google "OpenVPN Bridge". VIrtuaaliverkkoja on tullut vietyä tuolla tavoin toimipaikkojen välillä, joten kenties se WAN-verkkokin sen yli pujahtaa. :hmm: Voi toki vaatia hieman ajatusleikkiä ja testaamista interfacejen kanssa, mutta WAN on kuitenkin oikeastaan vain yksi VLAN.

Semisti polttelis tunkata ja testata, mutta kun ei käyttöä moiselle, niin jätän ilon kysyjälle. :comp:
 
starma2 sanoi:
Nostetaas vanhaa aihetta. Itse tarvisin seuraavanlaiseen systeemiin askelmerkit

internet - ISP-bridgerouter HEADOFFICE (publicip1-publicip5) ->
raspi4 ubuntu server HEADOFFICE ->
tunnel over internet (GRE/l2tp/openvpn?) ->
Router1 (openwrt, edgerouter or some) BRANCHOFFICE ->
Customerdevice BRANCHOFFICE publicip5

ohjeita on miljoona toteutuksesta, mutta käsittelee lähes aina site-to-site versiota, jossa yhdistetään kaksi privaattiverkkoa. Nyt halutaan että BRANCHOFFICEssa pystytään leasaamaan ISP:n dhcpeestä osoite suoraan.

tai sitten en osaa hahmottaa asiaa, ja toteutus vaatii privaattiverkot HEAD ja BRANCH officeen että tämän saa toteutettua. ISP dhcp asetuksiin ei tietysti ole pääsyä. DHCP-relayn konffiminen voi olla mahdotonta, tietämättä ISP:n dhcpeen sieluelämää

Kaikki konffi pitäisi olla raspi4(HEAD) ja router1(BRANCH) laitteissa. jotta mikä vaan Customerdevice(BRANCH) saa julkisen iipeen suoraan ISPn dhcpeeltä tunnelin läpi
Napsauta laajentaaksesi...
Siellä branchofficeissa et tee mitään Head officen julkisella IP:llä. En näe mitään mikä tätä edellyttäisi. Haet todennäköisesti justiinsa sitä site-2-site VPN ratkaisua ja siihen päälle VPN ratkaisuun säännöstöä että osa liikenteestä kulkee pääkonttorin kautta (avuiksi termi split tunneling) ja näkyy siten Head pään julkisella IP:llä ja sitten julkiseen IP:hen sidotut palvelut lähtee sivukonttoreissa toimimaan...
 
Kirjaudu tai rekisteröidy kirjoittaaksesi tänne.

Uutiset

Uutisia lyhyesti

Uusimmat viestit

Statistiikka

Viestiketjuista
261 350
Viestejä
4 535 756
Jäsenet
74 790
Uusin jäsen
anykanen

Hinta.fi

Back
Ylös Bottom