Slid, men vid: Ting Ta'r Tid

I 1994, for næsten præcis 27 år siden, landede jeg i SFO og fik et kontor på 26. etage med en fabelagtig udsigt over Oakland og San Francisco:

Illustration: Poul-Henning Kamp

Om aftenen var udsigten endnu mere imponerende, Golden Gate belyst i horizonten, endeløse bånd af røde og hvide billygter i kilometerlange traffikpropper i 80/880/980/580/24 udfletningen på Oakland siden af den gamle Bay Bridge, men det lykkedes mig aldrig at få et godt billede af det.

(Filmen blev naturligvis fremkaldt til "PhotoCD" og hvis I har nogen af dem skal I se at få lavet kopier af dem: Kodak mente åbenbart det med "op til 30års holdbarhed" alvorligt.)

Ud over hele dot-com bobblen var jeg også på anden parket til IPv6's fødsel, "IPng" som det hed den gang og nu, endelig, næsten en menneskealder senere:

root@d1:~ # ping -6 -c 5 freebsd.org  
PING6(56=40+8+8 bytes) 2a02:2190:200:b9a:230:18ff:fe0a:3a1e --> 2610:1c1:1:606c::50:15  
16 bytes from 2610:1c1:1:606c::50:15, icmp_seq=0 hlim=51 time=84.439 ms  
16 bytes from 2610:1c1:1:606c::50:15, icmp_seq=1 hlim=51 time=84.305 ms  
16 bytes from 2610:1c1:1:606c::50:15, icmp_seq=2 hlim=51 time=84.230 ms  
16 bytes from 2610:1c1:1:606c::50:15, icmp_seq=3 hlim=51 time=84.587 ms  
16 bytes from 2610:1c1:1:606c::50:15, icmp_seq=4 hlim=51 time=84.635 ms  
--- freebsd.org ping6 statistics ---  
5 packets transmitted, 5 packets received, 0.0% packet loss  
round-trip min/avg/max/std-dev = 84.230/84.439/84.635/0.156 ms

IPv6 er endelig nået til udkantsdanmark og det endda på en fiber!

Verdens første "podcast" er ældre end IPv6.

Carl Malamud lavede en "Internet Talk Radio" kaldet "Flame Of The Internet" og lavede en hel serie interviews med alt og alle i IPng/IPv6 arbejdet, under titlen "Geek Of The Week", som heldigvis er bevaret på Archive.org.

Vi havde en T1 linie hos TFS, så man kunne godt høre streaming audio (64kbit/s ukomprimeret telefonkvalitet) hvis man havde en Sun workstation og et par hovedtelefoner.

Når man idag hører disse stemmer fra fortiden og hvilke bekymringer de gjorde sig om IPng's egenskaber og muligheder, er det chokerende hvor langt der var fra teori til praksis.

Men det er mere tankevækkende hvad de slet ikke taler om.

De store carriers, ikke mindst UUnet, senere WorldCom, så ingen grund til at gøre det nemt at være multihomed, så det døde i standardiseringen.

NSA synes ikke det var smart at flow-routing gjorde packet captures uigennemskuelige, så det blev begravet i argumenter om hvor mange problemer det ville medføre.

Dengang var vi naturligvis ikke opmærksomme på at det var det der skete, men set i bakspejlet er det ret tydeligt at det var der foregik.

Dengang gjorde vi grin med at de næste tre lag i OSI stakken var Økonomi, Administration og Politik.

Men det viste sig at være sandheden.

Den senste barierre for IPv6 er at knapheden på IPv4 addresser er profitabel for dem der har IPv4 addresser.

Hvorfor skulle TDC og andre være ivrige efter at give mig en gratis IPv6/48 når de kan udleje IPv4 addresser enkeltvis for priser der intet har at gøre med deres udgifter i den forbindelse ?

The future looks much closer than it is in the mirror"

phk

Kommentarer (31)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Nis Schmidt

Jeg husker præsentationerne af DEC's Network Integration Server 600/900, IPv6 og protokollerne X400/X500 på "Network University" i 1991. Amerikanerne havde "flyveforbud" pga af den nylige krig mod Iraq. Så min kollega, Brian og jeg fik lov til at præsentere Pathworks (V4.0) klienterne til OS/2 og DOS/Win i Europa - 4 byer på 12 dage.

  • 2
  • 0
#2 Claus Bruun

I 1998 købte jeg den her https://www.amazon.ae/IPv6-Internet-Protocol-Christian-Huitema/dp/013850... og pløjede den igennem på en tur til Athens, Georgia og tilbage til DK. Så var jeg klar! - Det kunne jo ikke vare ret længe, - de havde jo tænkt på rigtig meget udover adresserummet med hele header strukturen, kryptering etc. etc.

......

Og så allerede 2016-07-07 fik jeg mail fra Baldur på Gigabit om, at jeg havde fået mit første IPv6/48 netværk! (Faktisk havde jeg experimenteret med tunneling fra Hurricane electric et års tid op til, men det kom aldrig til at fungere ordentligt).

Hvad der skete i mellem de to events må vist afskrives til de tre ekstra lag til OSI modellen :-(

  • 9
  • 0
#3 Baldur Norddahl

Fra en ISPs synsvinkel er der desværre stadig alt for meget der ikke spiller out of the box med hensyn til IPv6. Vores IPV6 løsning fungerer men der er kompromiser jeg ikke er glad for. Der er også meget kundeudstyr der er ringe på IPv6 og eksempelvis mangler de samme firewall muligheder på IPv6 i forhold til IPv4.

IPv6 er dog allerede noget der gør gavn. Det sparer penge. På grund af prisen på IPv4 adresser, så sendes de fleste kunders trafik igennem en CGN server. Men alt IPv6 trafik kan routes udenom og dermed kan CGN serveren være mindre. De største indholdsleverandører, eksempelvis Google, Netflix, Akamai med flere, har implementeret IPv6 og derfor er det en betragtelig andel af trafikken.

  • 11
  • 0
#4 Claus Bruun

Vi havde en T1 linie hos TFS, så man kunne godt høre streaming audio (64kbit/s ukomprimeret telefonkvalitet)

Var det 64kbit eller 56kbit ? - Amerikanerne havde jo valgt en kodning af bitstrømmen, der gjorde, at de kun kunne lave Nx56kbit ISDN, T1, T2 etc., hvor vi havde Nx64 (EuroISDN, E1, E2,...)

  • 0
  • 0
#5 Christian Lynbech

I januar '98 startede jeg hos Telebit Communications[1], en mindre biks i Aarhus der var bygget på (nogen af) resterne af Regnecentralens netværksafdeling.

Telebit havde et par år tidligere (jeg tror det var i '95) udsendt verdens første kommercielle dualstack IPv4/IPv6 router og vi gik nu og ventede på at IPv6 ville blive et hit.

I sluthalvfemserne sad rejsepengene noget løsere end de gjorde senere, så jeg fik lov til at tage til en Linux konference der blev holdt på Duke University. Alan Cox holdt oplæg om IPv6 i Linux og allerede på dette tidspunkt var der en udbredt frustration over at det ikke gik stærkere med at få IPv6 rullet ud.

Alan Cox fremførte, og det synes jeg stadigvæk lyder plausibelt, at havde man ikke ændret ret meget andet end at sætte adresse størrelsen op, så havde det været rullet ud overalt. Bagsiden af den analyse, som jeg også synes lyder plausibel, er at man så nok aldrig ville have fået en ny chance for at rette op på nogen af de andre uhensigtsmæssigheder der var i IPv4; manglen på IPv4 adresser skulle være den motor der drev IPv6 igennem. Man havde så blot overset den kreativitet som ISP'ere og udstyrs-leverandører ville ligge for dagen for at arbejde rundt om manglen på IPv4 adresser, som ydermere var yderst ulige fordelt. Jo tidligere du kom på internettet, jo større en del af addresse rummet havde du, så amerikanerne svømmede i IPv4 adresser mens lande som Kina havde sådan som noget som ét klasse C netværk til alle folkeskoler i hele Kina.

[1] Telebit lever på sin vis stadigvæk. I 1999 blev vi købt af Ericsson og siden solgt videre til konsulenthuset TietoEVRY. Telebit routeren (TBC) blev i al væsentligthed solgt til TDC hvor den i første omgang drev alarmnettet (når sirenerne blev testet kunne alle høre at nettet var oppe) og skulle efter sigende også have været en væsentlig årsag til at TDC var tidligt med på IP toget. Og nej, Telebit Communications havde ingen relation til den nu hedengangne amerikanske modem producent der også hed Telebit.

  • 10
  • 0
#6 Lasse Mølgaard

Der er også meget kundeudstyr der er ringe på IPv6 og eksempelvis mangler de samme firewall muligheder på IPv6 i forhold til IPv4.

Tjah hvis jeg kigger på min egen forbindelse (Fibia), så et det ret meget op ad bakke at overhovedet tildele min router en IPv6 adresse - på LAN siden.

Den kører med ret primitiv admin interface, så der er nærmest ingen mulighed for at ændre i firewallen og slet ikke mulighed for at tilføje statiske routes.

Lad os blot sige at jeg har anden udbyder i tankerne, når fibernettet bliver åbnet lidt mere i Jylland.

De har har i hvert fald snakket om et-eller-andet til foråret... :-)

  • 2
  • 0
#7 Martin Schultz

Som Baldur også nævner er IPv6 ikke altid godt implementeret i slutbruger udstyr.

Min ellers udemærkede ubiquity router kan maks levere omkring 250 megabit med ipv6 hvor den på ipv4 fint levere en gigabit.

I følge deres support har den simpelthen ikke kræfter til mere, uden at jeg helt kan forstå at ipv6 skulle kræve væsentligt mere cpu/ram end ipv4 men måske er det noget hardware offload der kun understøtter v4.

  • 4
  • 0
#9 Jens Jönsson

Min ellers udemærkede ubiquity router kan maks levere omkring 250 megabit med ipv6 hvor den på ipv4 fint levere en gigabit.

Nu har jeg ikke selv prøvet, men flere oplyser væsentligt højere IPv6 performance på f.eks. EdgeRouter X (Er ikke klar over hvilken model du har).

Alternativt kan du prøve med OpenWRT og se om det giver en forskel. http://www.makikiweb.com/ipv6/edgerouterx_openwrt.html

  • 2
  • 0
#11 Preben Trærup

Jeg kom til omtalte Telebit i 2000, hvor jeg blev en del af den gruppe, der skulle lave en IP stack til Ericssons handsets - den politisk korrekte svenske betegnelse for en dims af typen mobiltelefon på daværende tidspunkt. En af de features, der skulle være med i stakken var det dersens stedbarn IPv6. Jeg husker endnu lyden af modemmerne, når vi skulle have en tunnel op at køre for at få testet IPv6.

fast forward 20 år... Jeg har endeligt fået rå IPv6 på hjemmeadressen og gigabit hastighed til menneskepenge.

Nu vil tilfældet at jeg arbejder med fiberprodukter for tiden. Den nyeste EPON generation kører 10 gigabit og kan klare IPv6 til både slutkunder og management. Gad vide hvilken del jeg først kommer til at have en support sag på - hvis jeg da ikke når at gå på pension før med den nuværende udbredelshastighed :-)

Udover de ting PHK og Christian #5 nævner som IPv6 showstoppers, så tror jeg også man overså en anden lille detalje.

IPv6 er designet til at løse adresseproblemet - samt gøre det voldsomt nemmere at route pakkerne.

Man glemte så bare lige at en hel sækfuld allerede udbredte internetforbundne tingester faktisk bruger (og misbruger) IPv4 DHCP options til alt muligt fra provisionering til softwareopdatering. Rigtigt mange af disse DHCP options var ikke lige med i IPv6 DHCP oprindeligt, så enten skulle der findes på noget nyt - med de fejlskud, det koster - alternativt bare tage fra hylden hvad der lige løser opgaven nu og her - time to market nu om dage - customer centricity dengang.

Det med småt om sikkerhed kan så tilføjes her

  • 8
  • 0
#12 Mikkel Bundgaard

Et andet problem ved ipv6 er, at for langt de fleste slutkunder så virker ipv4 ligeså godt. Der er ikke nogen synlig added value. Jeg har selv ipv6 men har svært ved at sælge det ind. For hvorfor skulle de vælge en anden leverandør når den eksisterende virker(selv med cgn).

  • 1
  • 0
#13 Lasse Mølgaard

Jeg har selv ipv6 men har svært ved at sælge det ind. For hvorfor skulle de vælge en anden leverandør når den eksisterende virker(selv med cgn).

Der har da vist været en del artikler på V2 om problemer med hjemmearbejdspladser p.g.a. CGN.

Men til at starte med:

VPN er en pine, når man er bagved en CGN.

Jeg har selv kun fået det til at virke med OpenVPN over TCP og en meget lav keepalive værdi - med et kæmpe båndbredde tab til følge (cirka 80%).

Jeg har tested VPN via IPSec, men jeg har ikke den store succes med blot at holde en tunnel åben.

Derudover er det også stærkt begrænset hvor mange TCP sessions du kan have gang i på samme tid.

Der er trods alt et begrænset antal TCP porte tilgængelige i CGN'en, hvis den skal køre statefull og dem skal du dele med alle andre på din udbyders net.

Tovejskommunikation via UDP er tæt på umuligt fordi UDP er stateless, så dem holder CGN ikke øje med.

Alt dette kan du undgå på IPv6, fordi her er det ikke nødvendigt med en NAT (eller CGN).

Du har dog brug for en firewall.

... og nej... NAT != firewall.

  • 2
  • 0
#14 Baldur Norddahl

Ironien er måske at hvis alt du bruger internettet til er Facebook, Netflix, YouTube, så ser du ikke nogen forskel på at have ipv6 samtidig med at hovedparten af din trafik vil være ipv6.

For den gruppe kunder er fordelen muligvis at ipv6 lader os producere internet en lille smule billigere.

  • 2
  • 0
#15 Yoel Caspersen Blogger

VPN er en pine, når man er bagved en CGN.

Jeg har selv kun fået det til at virke med OpenVPN over TCP og en meget lav keepalive værdi - med et kæmpe båndbredde tab til følge (cirka 80%).

Det lyder som et problem med din udbyders implementation af CGN - fra et teknisk perspektiv er det svært at se, hvorfor VPN (generelt) skulle være et problem.

Hos Kviknet bruger vi PPTP-helpers til vores CGN, da PPTP-baserede VPN-forbindelser ellers har problemer (og ja, der er åbenbart stadig nogen, der bruger det skrammel - jeg antager, det er gamle Microsoft Small Business Server-implementationer rundt omkring). OpenVPN virker mig bekendt out-of-the-box.

Derudover er det også stærkt begrænset hvor mange TCP sessions du kan have gang i på samme tid.

Hvor mange har du brug for?

Der er trods alt et begrænset antal TCP porte tilgængelige i CGN'en, hvis den skal køre statefull og dem skal du dele med alle andre på din udbyders net.

Både ja og nej. Der er i omegnen 65.000 porte tilgængelige pr. offentlig IP-adresse ved full cone NAT. Antallet af porte pr. kunde afhænger derfor af antallet af kunder pr. offentlig IP-adresse - og om ISP'en enforcer en ligelig fordeling af portene.

Tovejskommunikation via UDP er tæt på umuligt fordi UDP er stateless, så dem holder CGN ikke øje med.

Igen afhænger det af implementationen. En fornuftig CGNAT-router vil emulere en session på UDP (med timeout efter x antal sekunders inaktivitet).

Alt dette kan du undgå på IPv6, fordi her er det ikke nødvendigt med en NAT (eller CGN).

Enig, IPv6 er løsningen på det meste!

Du har dog brug for en firewall.

Som server: Ubetinget ja. Som klient? Ikke nødvendigvis. Din klient vil bruge EUI64 med privacy extensions, hvilket gør, at klientens IPv6-adresse vil skifte med jævne mellemrum. Antallet af mulige IPv6-adresser eliminerer de port- og IP-scanninger, der typisk ses på IPv4.

Man bør dog altid have en lokal software-firewall på klienten selv, primært fordi det er god latin med defence in depth, og fordi parter, klienten kommunikerer med, lige her og nu vil kende klientens IPv6-adresse.

  • 4
  • 0
#16 Lasse Mølgaard

Hvor mange har du brug for?

Tjah burde den ikke være en anelse højere end 5?

Jeg har en hel del enheder i mit hjem, som har et netværkskort (TV, Xbox, Nintendo Switch, 3 Raspberry Pis, 1 Bærbar computer, 1 stationær computer, 1 netværksprinter, 2 accesspoints, 1 NAS, 1 tablet + mobiltelefon).

Lige så snart jeg rammer 5 simultane forbindelser, så kan ingen af mine andre enheder få fat i noget-som-helst fra internettet, til trods for at jeg har kun brugt 5-10% af min båndbredde.

Angående VPN

På VPN siden har jeg installeret OpenVPN og Strongswan og har sat Strongswan op til at bruge IKEv2 og EAP-Identity.

Resultaterne indtil videre:

  • OpenVPN via UDP: Umuligt at oprette en forbindelse - punktum! (Fra Fibias net).

  • OpenVPN via TCP: Muligt, men keepalive skal være lav, ellers lukker CGN forbindelsen indenfor 30 sekunder.

Det samme gælder i øvrigt for SSH.

Derudover er båndbredden via VPN stærkt reduceret.

Jeg har målt imellem 3 og 15 Mbit/sekundt på en 300 Mbit forbindelse - alt efter hvilken enhed jeg tester forbindelsen med (PC med i7 2700K CPU, Raspberry Pi 2B, 3 og 4, Samsung Galaxy S20 Ultra).

  • IPSec (Strongswan på server, Windows 10 native VPN klient) opsat i hub-and-spoke konfiguration.

Forbindelse bliver oprettet, men når jeg pinger klientents virtuelle ip fra serveren, så kan jeg ikke få forbindelse til klienten bagved bagved CGN (Fibia), men jeg kan godt pinge en klient, som bruger Telia som internetudbyder.

Det næste jeg vil prøve er Nebula Mesh og også WireGuard.

Med hensyn til firewall

Ja privacy extensions hjælper selvfølgelig på brute-force problemet, men jeg vil stadigvæk mene det er god latin at have en firewall på imellem ens eget net og udbyder - selv på ipv6.

Gerne med en standard regel om at outbound trafik er tilladt sammen med relateret trafik i inbound retning.

Alt andet skal afvises.

Man så åbne op for VPN, web, FTP m.m. på ren case-by-case basis.

  • 1
  • 0
#17 Yoel Caspersen Blogger

Tjah burde den ikke være en anelse højere end 5?

Jo, det skulle den så afgjort.

Hos Kviknet kører vi med en målsætning om, at max 128 kunder skal dele den samme IP-adresse, og det vil, ved en fuldstændig ligelig fordeling, give ca. 500 samtidige forbindelser pr. kunde. Men da vi kører med dynamisk allokering, kan en enkelt kunde godt have mange flere forbindelser samtidig - og så kan man jo altid, hvis man har behovet, køre med en dedikeret offentlig IP-adresse i stedet.

Med de ting, du oplever, lyder det som om, du sidder bag et CGN, der er defekt, eller som minimum ikke er optimalt konfigureret.

Gerne med en standard regel om at outbound trafik er tilladt sammen med relateret trafik i inbound retning.

Alt andet skal afvises.

Man så åbne op for VPN, web, FTP m.m. på ren case-by-case basis.

Det er også vores standardopsætning. Men jeg mener, man bør vænne sig til tanken om, at LAN ikke er et sikkert sted - perimetersikkerhed som koncept giver falsk tryghed.

  • 2
  • 0
#20 Yoel Caspersen Blogger

Fortæl det til vikingerne på Trelleborg ? :-)

Eller indbyggerne i Troja? ;)

Hvis du havde skrevet "perimetersikkerhed uden andet ..." havde vi været helt enige, men man skal være i et en meget speciel situation for at perimetersikkerhed ikke hjælper dramatisk på sikkerheden.

Jo, perimetersikkerhed gør (desværre) en forskel, men det er med til at fastholde idéen om, at bare vi har en god firewall i routeren, er den hellige grav vel forvaret.

Og det var den måske også for 30 år siden, men realiteten er, at vi i dag har et hav af devices på samme netværk (LAN), som burde segmenteres ud for sig selv og isoleres.

Det er under en uge siden, at jeg hjalp en kunde med at finde årsagen til, at der konstant indløb klager over attacks fra hans IP-adresse - årsagen var et kinesisk overvågningskamera, som sad på hans LAN, og tydeligvis var en del af et botnet.

Hvad gør vi ved alle de devices, som ikke har indbygget firewall, og som vælter ind i folks hjem i disse år? Fjernsyn, kameraer, badevægte, lyskilder, køleskabe osv. Alt sammen ting, der burde holdes ud i en strakt arm med en ildtang, men som i stedet lukkes ind i det allerhelligste.

Realiteten er, at det private netværk allerede i dag er en slagmark - og jo før, vi indser det, jo før kan vi komme i gang med at få løst problemet.

  • 7
  • 0
#22 Baldur Norddahl

Vi indfører produktansvar for direkte og indirekte skader ?

Det er kineserne da ligeglade med. Og det er for sent.

I ISP netværket har vi segmenteret kunderne fra hinanden. Et vlan per kunde. Det koncept kan videreføres helt ud til det enkelte apparat. Hvorfor skal dit kinesiske kamera have lov til at port scanne din printer?

På vores kontor har vi aktiveret funktionen "port isolation". Det forhindrer at vores computere kan kommunikere direkte med hinanden. Det er ikke nødvendigt i 2021 på et kontor. Det er ikke perfekt, printerne er nødt til at have fuld adgang til nettet, men de er kun en printer, så det burde have været muligt at begrænse lidt mere. Chrome Cast til TV skærme i mødelokalerne skal også have adgang. Men det er ikke standard i billige managed switche til kontorbrug at man kan lave ACL regler på portene.

  • 3
  • 0
#23 Henning Wangerin

Jeg kan varmt anbefale "tinc" VPN, jeg har stor glæde af dets "mesh" arkitektur og har flere gange set det holde forbindelsen hvor enten IPv4 eller IPv6 var nede, men ikke begge.

Jeg den kører bare derudaf.

Har kørt med tinc i mange år, og har flere servere ud i verden som give nem adgang for klienterne.

Og specielt med ipv6 på klienterne bliver mesh-opsætningen genialt ved at klient-klient trafik kan gå direkte mellem dem uden at skulle forbi en server for at komme igennem NAT.

/Henning

  • 0
  • 0
#25 Michael Cederberg

Både ja og nej. Der er i omegnen 65.000 porte tilgængelige pr. offentlig IP-adresse ved full cone NAT. Antallet af porte pr. kunde afhænger derfor af antallet af kunder pr. offentlig IP-adresse - og om ISP'en enforcer en ligelig fordeling af portene.

For udgående traffik kan man så mappe samme port til flere kunder? Remote IP+Port burde være unikt.

Jo, perimetersikkerhed gør (desværre) en forskel, men det er med til at fastholde idéen om, at bare vi har en god firewall i routeren, er den hellige grav vel forvaret.

Og det var den måske også for 30 år siden, men realiteten er, at vi i dag har et hav af devices på samme netværk (LAN), som burde segmenteres ud for sig selv og isoleres.

Helt enig. Desværre er det ikke nemt. Jeg har ca. 60 IP devices på mit netværk spredt ud over 10 VLANs og en pfSense router. Det tog lang tid at sætte op og der er en række consumer protocoller der ikke er routing venlige.

Jeg kunne godt tænke mig et router/firewall setup hvor jeg havde en "service template" og så mappede forskellige devices til samme.

Hvis jeg fx. havde en template for chromecast så kunne jeg bruge den på følgende måde:

Service=Chromecast  
Chromcast renderer: chromecast1, chromecast2, chromecast3  
Chromecast users: laptops, phones

Herefter kunne routeren selv åbne for de porte/ip/multicast/protocoller der var nødvendige for at devices der tilhørte laptops eller phones gruppen kunne bruge chromecast1..3.

På samme måde vill der være en service der hed "Internet HTTP/HTTPS" access. Her ville jeg så konfigurere devices der skulle have ... wait for it ... adgang til internettet med HTTP(S).

Med fornuftig navngivning kunne man godt lære almindelige mennesker at sætte skidtet op (og ja, Fru Olsen skal ikke rode med noget hvor der står HTTP). Men det ville kræve at det at tilføje en ny device krævede lidt mere end blot at taste wifi password ind.

  • 0
  • 0
#26 Yoel Caspersen Blogger

For udgående traffik kan man så mappe samme port til flere kunder? Remote IP+Port burde være unikt.

I teorien ja, men så holder det op med at være et full cone NAT (og så kan du bl.a. få problemer med hole punching).

Helt enig. Desværre er det ikke nemt. Jeg har ca. 60 IP devices på mit netværk spredt ud over 10 VLANs og en pfSense router. Det tog lang tid at sætte op og der er en række consumer protocoller der ikke er routing venlige.

Og dit setup er et mareridt at vedligeholde, især for andre ;)

Jeg kunne godt tænke mig et router/firewall setup hvor jeg havde en "service template" og så mappede forskellige devices til samme.

Ja, det er nok umiddelbart den mest brugervenlige løsning. En række templates til de mest gængse devices, parret med muligheden for at lave sine egne templates, hvis man er superbruger.

Det næste, kritiske punkt er: Hvem skal vedligeholde det? Når fru Olsen henter en app, hvis kommunikationsmønster ikke passer ind i systemet, hvad skal der så ske?

  • 1
  • 0
#27 Christian Halgreen

Tjah burde den ikke være en anelse højere end 5?

.........

Med de ting, du oplever, lyder det som om, du sidder bag et CGN, der er defekt, eller som minimum ikke er optimalt konfigureret.

Det kunne vel også være NAT44 funktionaliteten i den lokale router, der har en uhensigtsmæssig begrænsning. Jeg noterer at det er andre enheder på det lokale netværk, der ikke kan oprette forbindelser. Lasse skriver ikke noget om nye forbindelser fra de enheder, der har aktivitet i gang.

  • 0
  • 0
#28 Lasse Mølgaard

Det kunne vel også være NAT44 funktionaliteten i den lokale router, der har en uhensigtsmæssig begrænsning. Jeg noterer at det er andre enheder på det lokale netværk, der ikke kan oprette forbindelser. Lasse skriver ikke noget om nye forbindelser fra de enheder, der har aktivitet i gang.

Det er sådan set lige meget om det et en enhed som laver 6 forbindelser eller om det 6 forskellige enheder, som åbner en forbindelse hver.

Det er "bare ærgerligt, Sonny Boy" for den sjette forbindelse. :-/

Men som jeg har også give hints om i andre posts: Min fiber router er meget mærkelig.

Det faktum at det er komplet umuligt at blot tildele den en ipv6 adresse burde være det første hint.

Og den kender ikke til konceptet firewall eller routingstabeller.

... I hvert fald ikke i det admin interface, som jeg har adgang til.

  • 0
  • 0
#29 Morten Christensen

Resultaterne indtil videre:

OpenVPN via UDP: Umuligt at oprette en forbindelse - punktum! (Fra Fibias net).

Jeg har godt 40 kolleger, som arbejder hjemmefra over OpenVPN via UDP. Vi er i Fibia-land, så rigtig mange må have deres fiber med CGN, selvom jeg ikke har statistik på det. Jeg har selv investeret et telefonopkald i at få routeren sat i bridgemode og få en offentlig IP-adresse, men det har mine kolleger ikke.

Vores VPN'er har været stabile over hele nedlukningen og mange år før det, og eneste tilbud er OpenVPN over UDP.

(Ikke et forsvar for Fibia. Jo hurtigere de giver adgang for udbydere der kan finde ud af IPv6, jo bedre.)

  • 1
  • 0
#31 Michael Cederberg

Det næste, kritiske punkt er: Hvem skal vedligeholde det? Når fru Olsen henter en app, hvis kommunikationsmønster ikke passer ind i systemet, hvad skal der så ske?

Jeg forestiller mig at man crowdsourcer det. Noget med at få folk til at reviewe service-templates og give dem points for deres arbejde. Jo flere points revieweren har, jo højere score til det reviewede. Med et offentligt audit trail sådan at hvis man opdager et "bad apple" blandt reviewers, så kan vedkommende downvotes. I øvrigt tror jeg det største problem er devices; ikke apps.

  • 0
  • 0
Log ind eller Opret konto for at kommentere