/dev/null - Overig

NixOS en Openvpn-nl

Reageer met quote
Vandaag, 10:31 door Anoniem, 9 reacties
Waarom is er geen versie van Openvpn-nl voor NixOS? We willen toch graag binnen Nederland overstappen naar NixOS?

https://openvpn.sentyron.com/software.html
Reacties (9)
Reageer met quote
Vandaag, 11:10 door Anoniem
https://nixos.wiki/wiki/OpenVPN
Reageer met quote
Vandaag, 11:44 door Anoniem
De broncode is beschikbaar, dus ik zie het probleem niet. Overigens zou ik liever zien dat ze WireGuard gebruiken.
Reageer met quote
Vandaag, 11:45 door Anoniem
Die is er wel: https://search.nixos.org/packages?channel=26.05&query=openvpn#show=openvpn

Waarom sentyron er geen heeft moet je aan sentyron vragen

Verder geen idee wat sentyron is
Reageer met quote
Vandaag, 12:56 door Anoniem
Door Anoniem: Die is er wel: https://search.nixos.org/packages?channel=26.05&query=openvpn#show=openvpn

Waarom sentyron er geen heeft moet je aan sentyron vragen

Verder geen idee wat sentyron is

Sentyron is volgens mij een partij die de HW/SW tak van Fox Crypto/Fox-IT heeft overgenomen. OpenVPN-NL is een “hardened” versie van OpenVPN.
Reageer met quote
Vandaag, 13:48 door Anoniem
Door Anoniem:
Door Anoniem: Die is er wel: https://search.nixos.org/packages?channel=26.05&query=openvpn#show=openvpn

Waarom sentyron er geen heeft moet je aan sentyron vragen

Verder geen idee wat sentyron is

Sentyron is volgens mij een partij die de HW/SW tak van Fox Crypto/Fox-IT heeft overgenomen. OpenVPN-NL is een “hardened” versie van OpenVPN.

Die versie van OpenVPN is niet de modernste. ;) Het is maar de vraag of daar geen kwetsbaarheden in zitten aangezien het laag gerubriceerde info mag transporteren.
Reageer met quote
Vandaag, 14:22 door Anoniem
Willen we dat?
Reageer met quote
Vandaag, 14:50 door _R0N_
Door Anoniem: De broncode is beschikbaar, dus ik zie het probleem niet. Overigens zou ik liever zien dat ze WireGuard gebruiken.

Ja en nee, Wireguard werkt beter, als het werkt.
Het suffe is dat, omdat het UDP based is, de client altijd aangeeft geconnect te zijn ook al is de server down. Dat gaat heel veel gebruikers vragen opleveren.
Reageer met quote
Vandaag, 15:22 door Anoniem
Door _R0N_:
Door Anoniem: De broncode is beschikbaar, dus ik zie het probleem niet. Overigens zou ik liever zien dat ze WireGuard gebruiken.

Ja en nee, Wireguard werkt beter, als het werkt.
Het suffe is dat, omdat het UDP based is, de client altijd aangeeft geconnect te zijn ook al is de server down. Dat gaat heel veel gebruikers vragen opleveren.

Dat heeft niks speciaal met UDP te maken.

TCP heeft ook geen keepalive detectie in de core specificatie , alleen de (erg vaak geimplementeerde) _mogelijkheid_ (optional feature) van TCP keepalive.
Vaker zit er in een applicatie protocol (zoals bv SSH) een eigen keep alive optie.
Een VPN protocol, ongeacht encapsulatie methode zou een keepalive optie kunnen implementeren.


Verder is qua performance een encapsulatie zonder buffering/retransmit gewoon beter voor TCP-payload verkeer.
Of het nu UDP, GRE, IPSec is - de payload-TCP krijgt dan een correct beeld van de netwerk omstandigheden (drops, toenemende latency) om transmit rate bij te sturen zoals TCP ontworpen is.
TCP-in-TCP maskeert die karakteristieken en leidt tot slechtere performance van de interne TCP sessie wanneer er congestie of packet loss is.

https://en.wikipedia.org/wiki/Tunneling_protocol zie TCP meltdown.
Reageer met quote
Vandaag, 21:07 door Anoniem
Door Anoniem:
Door _R0N_:
Door Anoniem: De broncode is beschikbaar, dus ik zie het probleem niet. Overigens zou ik liever zien dat ze WireGuard gebruiken.

Ja en nee, Wireguard werkt beter, als het werkt.
Het suffe is dat, omdat het UDP based is, de client altijd aangeeft geconnect te zijn ook al is de server down. Dat gaat heel veel gebruikers vragen opleveren.

Dat heeft niks speciaal met UDP te maken.

TCP heeft ook geen keepalive detectie in de core specificatie , alleen de (erg vaak geimplementeerde) _mogelijkheid_ (optional feature) van TCP keepalive.
Vaker zit er in een applicatie protocol (zoals bv SSH) een eigen keep alive optie.
Een VPN protocol, ongeacht encapsulatie methode zou een keepalive optie kunnen implementeren.


Verder is qua performance een encapsulatie zonder buffering/retransmit gewoon beter voor TCP-payload verkeer.
Of het nu UDP, GRE, IPSec is - de payload-TCP krijgt dan een correct beeld van de netwerk omstandigheden (drops, toenemende latency) om transmit rate bij te sturen zoals TCP ontworpen is.
TCP-in-TCP maskeert die karakteristieken en leidt tot slechtere performance van de interne TCP sessie wanneer er congestie of packet loss is.

https://en.wikipedia.org/wiki/Tunneling_protocol zie TCP meltdown.
Inderdaad UDPis connectieloos en er vind geen foutcorrectie plaats. Is bij een video stream ook niet echt nodig. Daar is throughput veel belangrijker. Bij TCP wordt er garantie geleverd dat de gegevens aankomen zoals ze verstuurd werden, en eventuele communicatiefouten, zowel in de gegevens zelf als in de volgorde van de gegevens kunnen worden opgevangen. Een keep alive bericht is op dit niveau onzinnig. Het enige wat van belang is, is of de lijn vrij is om een pakketje te versturen.
Reageren
Ondersteunde bbcodes
Bold: [b]bold text[/b]
Italic: [i]italic text[/i]
Underline: [u]underlined text[/u]
Quote: [quote]quoted text[/quote]
URL: [url]https://www.security.nl[/url]
Config: [config]config text[/config]
Code: [code]code text[/code]

Je bent niet en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.

Zoeken
search
Certified Secure GenAI Deep Dive Security Training
Security Awareness Ransomware Edition