Hoffwn rannu fy mhrofiad o gyfuno rhwydweithiau mewn tri fflat anghysbell yn ddaearyddol, pob un ohonynt yn defnyddio llwybryddion gydag OpenWRT fel porth, yn un rhwydwaith cyffredin. Wrth ddewis dull ar gyfer cyfuno rhwydweithiau rhwng L3 gyda llwybro is-rwydwaith a L2 gyda phontio, pan fydd yr holl nodau rhwydwaith yn yr un isrwyd, rhoddwyd blaenoriaeth i'r ail ddull, sy'n anoddach ei ffurfweddu, ond sy'n darparu mwy o gyfleoedd, gan fod y cynlluniwyd defnydd tryloyw o dechnolegau yn y rhwydwaith sy'n cael ei greu Wake-on-Lan a DLNA.
Rhan 1: Cefndir
Dewiswyd OpenVPN i ddechrau fel y protocol ar gyfer gweithredu'r dasg hon, oherwydd, yn gyntaf, gall greu dyfais tap y gellir ei hychwanegu at y bont heb broblemau, ac yn ail, mae OpenVPN yn cefnogi gweithrediad dros y protocol TCP, a oedd hefyd yn bwysig, oherwydd dim roedd gan y fflatiau gyfeiriad IP pwrpasol, ac nid oeddwn yn gallu defnyddio STUN, gan fod fy narparwr am ryw reswm yn blocio cysylltiadau CDU sy'n dod i mewn o'u rhwydweithiau, tra bod protocol TCP yn caniatáu imi anfon porthladd gweinydd VPN ymlaen i VPS wedi'i rentu gan ddefnyddio SSH. Ydy, mae'r dull hwn yn rhoi llwyth mawr, gan fod y data wedi'i amgryptio ddwywaith, ond nid oeddwn am gyflwyno VPS i'm rhwydwaith preifat, gan fod risg o hyd y byddai trydydd partïon yn ennill rheolaeth drosto, felly, yn cael dyfais o'r fath ar fy rhwydwaith cartref yn hynod annymunol a phenderfynwyd talu am ddiogelwch gyda gorbenion mawr.
I anfon y porth ymlaen ar y llwybrydd y bwriadwyd defnyddio'r gweinydd arno, defnyddiwyd y rhaglen sshtunnel. Ni fyddaf yn disgrifio cymhlethdodau ei ffurfweddiad - mae'n cael ei wneud yn eithaf hawdd, byddaf yn nodi mai ei dasg oedd anfon porthladd TCP 1194 ymlaen o'r llwybrydd i'r VPS. Nesaf, cafodd y gweinydd OpenVPN ei ffurfweddu ar y ddyfais tap0, a oedd wedi'i gysylltu â'r bont br-lan. Ar ôl gwirio'r cysylltiad â'r gweinydd newydd ei greu o'r gliniadur, daeth yn amlwg bod cyfiawnhad dros y syniad o anfon porthladd ymlaen a daeth fy ngliniadur yn aelod o rwydwaith y llwybrydd, er nad oedd ynddo'n gorfforol.
Dim ond un peth bach oedd ar ôl i'w wneud: roedd angen dosbarthu cyfeiriadau IP mewn gwahanol fflatiau fel nad oeddent yn gwrthdaro ac yn ffurfweddu'r llwybryddion fel cleientiaid OpenVPN.
Dewiswyd y cyfeiriadau IP llwybrydd canlynol ac ystodau gweinydd DHCP:
- 192.168.10.1 ag ystod 192.168.10.2 - 192.168.10.80 ar gyfer y gweinydd
- 192.168.10.100 ag ystod 192.168.10.101 - 192.168.10.149 ar gyfer y llwybrydd yn fflat Rhif 2
- 192.168.10.150 ag ystod 192.168.10.151 - 192.168.10.199 ar gyfer y llwybrydd yn fflat Rhif 3
Roedd angen hefyd aseinio'r union gyfeiriadau hyn i lwybryddion cleient y gweinydd OpenVPN trwy ychwanegu'r llinell at ei ffurfweddiad:
ifconfig-pool-persist /etc/openvpn/ipp.txt 0ac ychwanegu'r llinellau canlynol at y ffeil /etc/openvpn/ipp.txt:
flat1_id 192.168.10.100
flat2_id 192.168.10.150
lle flat1_id a flat2_id yw'r enwau dyfeisiau a nodir wrth greu tystysgrifau ar gyfer cysylltu ag OpenVPN
Nesaf, cafodd cleientiaid OpenVPN eu ffurfweddu ar y llwybryddion, ychwanegwyd dyfeisiau tap0 ar y ddau at y bont br-lan. Ar y cam hwn, roedd popeth yn ymddangos yn iawn gan fod y tri rhwydwaith yn gallu gweld ei gilydd a gweithio fel un. Fodd bynnag, daeth manylyn nad oedd yn ddymunol iawn i'r amlwg: weithiau gallai dyfeisiau dderbyn cyfeiriad IP nid gan eu llwybrydd, gyda'r holl ganlyniadau dilynol. Am ryw reswm, nid oedd gan y llwybrydd yn un o'r fflatiau amser i ymateb i DHCPDISCOVER mewn pryd a derbyniodd y ddyfais gyfeiriad nas bwriadwyd. Sylweddolais fod angen i mi hidlo ceisiadau o'r fath yn tap0 ar bob un o'r llwybryddion, ond fel y digwyddodd, ni all iptables weithio gyda'r ddyfais os yw'n rhan o bont a rhaid i ebtables ddod i'm cymorth. Yn anffodus, nid oedd yn fy firmware ac roedd yn rhaid i mi ailadeiladu'r delweddau ar gyfer pob dyfais. Trwy wneud hyn ac ychwanegu'r llinellau hyn at /etc/rc.local pob llwybrydd, datryswyd y broblem:
ebtables -A INPUT --in-interface tap0 --protocol ipv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
ebtables -A INPUT --in-interface tap0 --protocol ipv4 --ip-protocol udp --ip-source-port 67:68 -j DROP
ebtables -A FORWARD --out-interface tap0 --protocol ipv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
ebtables -A FORWARD --out-interface tap0 --protocol ipv4 --ip-protocol udp --ip-source-port 67:68 -j DROP
Parhaodd y cyfluniad hwn am dair blynedd.
Rhan 2: Cyflwyno WireGuard
Yn ddiweddar, mae pobl ar y Rhyngrwyd wedi dechrau siarad yn gynyddol am WireGuard, gan edmygu symlrwydd ei ffurfweddiad, cyflymder trosglwyddo uchel, ping isel gyda diogelwch tebyg. Wrth chwilio am ragor o wybodaeth amdano fe’i gwnaed yn glir nad oedd gweithio fel aelod o’r bont na gweithio dros y protocol TCP yn cael ei gefnogi ganddo, a wnaeth i mi feddwl nad oedd unrhyw ddewisiadau amgen i OpenVPN i mi o hyd. Felly gohiriais ddod i adnabod WireGuard.
Ychydig ddyddiau yn ôl, lledaenodd newyddion ar draws adnoddau un ffordd neu'r llall yn ymwneud â TG y byddai WireGuard yn cael ei gynnwys o'r diwedd yn y cnewyllyn Linux, gan ddechrau gyda fersiwn 5.6. Roedd erthyglau newyddion, fel bob amser, yn canmol WireGuard. Fe wnes i blymio eto i chwilio am ffyrdd i ddisodli'r hen OpenVPN da. Y tro hwn rhedais i mewn . Soniodd am greu twnnel Ethernet dros L3 gan ddefnyddio GRE. Rhoddodd yr erthygl hon obaith i mi. Roedd yn parhau i fod yn aneglur beth i'w wneud â phrotocol y CDU. Arweiniodd y chwiliad fi at erthyglau am ddefnyddio socat ar y cyd â thwnnel SSH i anfon porthladd CDU ymlaen, fodd bynnag, fe wnaethant nodi bod y dull hwn yn gweithio mewn modd cysylltiad sengl yn unig, hynny yw, byddai gwaith nifer o gleientiaid VPN yn amhosibl. Deuthum i'r syniad o osod gweinydd VPN ar VPS a sefydlu GRE ar gyfer cleientiaid, ond fel y digwyddodd, nid yw GRE yn cefnogi amgryptio, a fydd yn arwain at y ffaith, os bydd trydydd partïon yn cael mynediad i'r gweinydd , bydd yr holl draffig rhwng fy rhwydweithiau yn eu dwylo nhw , nad oedd yn fy siwtio i o gwbl.
Unwaith eto, gwnaed y penderfyniad o blaid amgryptio diangen, trwy ddefnyddio VPN dros VPN gan ddefnyddio'r cynllun canlynol:
VPN Lefel 1:
Datganiad Personol Dioddefwr yn gweinydd gyda chyfeiriad mewnol 192.168.30.1
MS yn cleient VPS gyda chyfeiriad mewnol 192.168.30.2
MK2 yn cleient VPS gyda chyfeiriad mewnol 192.168.30.3
MK3 yn cleient VPS gyda chyfeiriad mewnol 192.168.30.4
VPN ail lefel:
MS yn gweinydd gyda chyfeiriad allanol 192.168.30.2 a mewnol 192.168.31.1
MK2 yn cleient MS gyda'r cyfeiriad 192.168.30.2 ac mae ganddo IP mewnol 192.168.31.2
MK3 yn cleient MS gyda'r cyfeiriad 192.168.30.2 ac mae ganddo IP mewnol 192.168.31.3
* MS — llwybrydd-gweinydd yn fflat 1, MK2 - llwybrydd yn fflat 2, MK3 - llwybrydd yn fflat 3
* Cyhoeddir ffurfweddiadau dyfais yn y sbwyliwr ar ddiwedd yr erthygl.
Ac felly, mae pings yn rhedeg rhwng nodau rhwydwaith 192.168.31.0/24, mae'n bryd symud ymlaen i sefydlu twnnel GRE. Cyn hyn, er mwyn peidio â cholli mynediad at lwybryddion, mae'n werth sefydlu twneli SSH i anfon porthladd 22 ymlaen i'r VPS, fel y bydd y llwybrydd o fflat 10022, er enghraifft, yn hygyrch ar borthladd 2 y VPS, a'r bydd llwybrydd o fflat 11122 yn hygyrch ar borthladd 3 llwybrydd o fflat XNUMX. Mae'n well ffurfweddu anfon ymlaen gan ddefnyddio'r un sshtunnel, gan y bydd yn adfer y twnnel os bydd yn methu.
Mae'r twnnel wedi'i ffurfweddu, gallwch gysylltu â SSH trwy'r porthladd a anfonwyd ymlaen:
ssh root@МОЙ_VPS -p 10022Nesaf dylech analluogi OpenVPN:
/etc/init.d/openvpn stopNawr, gadewch i ni sefydlu twnnel GRE ar y llwybrydd o fflat 2:
ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
ip link set grelan0 up
Ac ychwanegwch y rhyngwyneb a grëwyd i'r bont:
brctl addif br-lan grelan0
Gadewch i ni berfformio gweithdrefn debyg ar lwybrydd y gweinydd:
ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set grelan0 up
A hefyd ychwanegu'r rhyngwyneb a grëwyd i'r bont:
brctl addif br-lan grelan0
gan ddechrau o'r funud hon, mae pings yn dechrau mynd i'r rhwydwaith newydd yn llwyddiannus ac rydw i, gyda boddhad, yn mynd i yfed coffi. Yna, i werthuso sut mae'r rhwydwaith yn gweithio ar ben arall y llinell, rwy'n ceisio SSH i mewn i un o'r cyfrifiaduron yn fflat 2, ond mae'r cleient ssh yn rhewi heb ofyn am gyfrinair. Rwy'n ceisio cysylltu â'r cyfrifiadur hwn trwy telnet ar borth 22 ac rwy'n gweld llinell y gallaf ddeall ohoni fod y cysylltiad yn cael ei sefydlu, mae'r gweinydd SSH yn ymateb, ond am ryw reswm nid yw'n fy annog i logio mewn.
$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1
Rwy'n ceisio cysylltu ag ef trwy VNC a gweld sgrin ddu. Rwy'n argyhoeddi fy hun mai'r broblem yw gyda'r cyfrifiadur anghysbell, oherwydd gallaf gysylltu'n hawdd â'r llwybrydd o'r fflat hwn gan ddefnyddio'r cyfeiriad mewnol. Fodd bynnag, rwy'n penderfynu cysylltu â SSH y cyfrifiadur hwn trwy'r llwybrydd ac rwy'n synnu gweld bod y cysylltiad yn llwyddiannus, a bod y cyfrifiadur anghysbell yn gweithio'n eithaf normal, ond ni all hefyd gysylltu â'm cyfrifiadur.
Rwy'n tynnu'r ddyfais grelan0 o'r bont ac yn rhedeg OpenVPN ar y llwybrydd yn fflat 2 ac yn sicrhau bod y rhwydwaith yn gweithio yn ôl y disgwyl eto ac nad yw'r cysylltiadau'n cael eu gollwng. Wrth chwilio dwi’n dod ar draws fforymau lle mae pobl yn cwyno am yr un problemau, lle maen nhw’n cael eu cynghori i godi’r MTU. Nid cynt wedi dweud na gwneud. Fodd bynnag, nes bod yr MTU wedi'i osod yn ddigon uchel - gwelwyd 7000 ar gyfer dyfeisiau gretap, naill ai wedi gostwng cysylltiadau TCP neu gyfraddau trosglwyddo isel. Oherwydd yr MTU uchel ar gyfer gretap, gosodwyd yr MTUs ar gyfer cysylltiadau WireGuard Haen 8000 a Haen 7500 i XNUMX a XNUMX yn y drefn honno.
Cynhaliais osodiad tebyg ar y llwybrydd o fflat 3, a'r unig wahaniaeth oedd bod ail ryngwyneb gretap o'r enw grelan1 wedi'i ychwanegu at lwybrydd y gweinydd, a ychwanegwyd hefyd at y bont br-lan.
Mae popeth yn gweithio. Nawr gallwch chi roi'r cynulliad gretap i gychwyn. Ar gyfer hyn:
Gosodais y llinellau hyn yn /etc/rc.local ar y llwybrydd yn fflat 2:
ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
ip link set dev grelan0 mtu 7000
ip link set grelan0 up
brctl addif br-lan grelan0
Wedi ychwanegu hwn at /etc/rc.local ar y llwybrydd yn fflat 3:
ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.3
ip link set dev grelan0 mtu 7000
ip link set grelan0 up
brctl addif br-lan grelan0
Ac ar lwybrydd y gweinydd:
ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set dev grelan0 mtu 7000
ip link set grelan0 up
brctl addif br-lan grelan0
ip link add grelan1 type gretap remote 192.168.31.3 local 192.168.31.1
ip link set dev grelan1 mtu 7000
ip link set grelan1 up
brctl addif br-lan grelan1
Ar ôl ailgychwyn y llwybryddion cleient, darganfyddais nad oeddent am ryw reswm yn cysylltu â'r gweinydd. Ar ôl cysylltu â'u SSH (yn ffodus, roeddwn wedi ffurfweddu sshtunnel ar gyfer hyn o'r blaen), darganfuwyd bod WireGuard am ryw reswm yn creu llwybr ar gyfer y pwynt terfyn, ond roedd yn anghywir. Felly, ar gyfer 192.168.30.2, roedd y tabl llwybr yn nodi llwybr drwy'r rhyngwyneb pppoe-wan, hynny yw, drwy'r Rhyngrwyd, er y dylai'r llwybr ato fod wedi'i gyfeirio drwy'r rhyngwyneb wg0. Ar ôl dileu'r llwybr hwn, cafodd y cysylltiad ei adfer. Nid oeddwn yn gallu dod o hyd i gyfarwyddiadau yn unrhyw le ar sut i orfodi WireGuard i beidio â chreu'r llwybrau hyn. Ar ben hynny, doeddwn i ddim hyd yn oed yn deall a oedd hyn yn nodwedd o OpenWRT neu WireGuard ei hun. Heb orfod delio â'r broblem hon am amser hir, fe wnes i ychwanegu llinell at y ddau lwybrydd mewn sgript wedi'i hamseru a oedd yn dileu'r llwybr hwn:
route del 192.168.30.2
Crynhoi
Nid wyf eto wedi llwyddo i roi'r gorau i OpenVPN yn llwyr, gan fod angen i mi weithiau gysylltu â rhwydwaith newydd o liniadur neu ffôn, ac mae sefydlu dyfais gretap arnynt yn gyffredinol amhosibl, ond er gwaethaf hyn, cefais fantais yn y cyflymder Nid yw trosglwyddo data rhwng fflatiau ac, er enghraifft, defnyddio VNC bellach yn anghyfleus. Gostyngodd ping ychydig, ond daeth yn fwy sefydlog:
Wrth ddefnyddio OpenVPN:
[r0ck3r@desktop ~]$ ping -c 20 192.168.10.110
PING 192.168.10.110 (192.168.10.110) 56(84) bytes of data.
64 bytes from 192.168.10.110: icmp_seq=1 ttl=64 time=133 ms
...
64 bytes from 192.168.10.110: icmp_seq=20 ttl=64 time=125 ms
--- 192.168.10.110 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19006ms
rtt min/avg/max/mdev = 124.722/126.152/136.907/3.065 ms
Wrth ddefnyddio WireGuard:
[r0ck3r@desktop ~]$ ping -c 20 192.168.10.110
PING 192.168.10.110 (192.168.10.110) 56(84) bytes of data.
64 bytes from 192.168.10.110: icmp_seq=1 ttl=64 time=124 ms
...
64 bytes from 192.168.10.110: icmp_seq=20 ttl=64 time=124 ms
--- 192.168.10.110 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19003ms
rtt min/avg/max/mdev = 123.954/124.423/126.708/0.675 ms
Mae'r ping uchel i'r VPS yn effeithio'n fwy arno, sydd tua 61.5 ms
Fodd bynnag, mae'r cyflymder wedi cynyddu'n sylweddol. Felly, mewn fflat gyda llwybrydd gweinydd mae gen i gyflymder cysylltiad Rhyngrwyd o 30 Mbit yr eiliad, ac mewn fflatiau eraill mae'n 5 Mbit yr eiliad. Ar yr un pryd, wrth ddefnyddio OpenVPN, nid oeddwn yn gallu cyflawni cyflymder trosglwyddo data rhwng rhwydweithiau o fwy na 3,8 Mbit yr eiliad yn ôl darlleniadau iperf, tra bod WireGuard wedi ei “hwb” i'r un 5 Mbit yr eiliad.
Cyfluniad WireGuard ar VPS[Interface]
Address = 192.168.30.1/24
ListenPort = 51820
PrivateKey = <ЗАКРЫТЫЙ_КЛЮЧ_ДЛЯ_VPS>
[Peer]
PublicKey = <ОТКРЫТЫЙ_КЛЮЧ_VPN_1_МС>
AllowedIPs = 192.168.30.2/32
[Peer]
PublicKey = <ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МК2>
AllowedIPs = 192.168.30.3/32
[Peer]
PublicKey = <ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МК3>
AllowedIPs = 192.168.30.4/32
Cyfluniad WireGuard ar MS (wedi'i ychwanegu at /etc/config/network)
#VPN первого уровня - клиент
config interface 'wg0'
option proto 'wireguard'
list addresses '192.168.30.2/24'
option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_1_МС'
option auto '1'
option mtu '8000'
config wireguard_wg0
option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_1_VPS'
option endpoint_port '51820'
option route_allowed_ips '1'
option persistent_keepalive '25'
list allowed_ips '192.168.30.0/24'
option endpoint_host 'IP_АДРЕС_VPS'
#VPN второго уровня - сервер
config interface 'wg1'
option proto 'wireguard'
option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_2_МС'
option listen_port '51821'
list addresses '192.168.31.1/24'
option auto '1'
option mtu '7500'
config wireguard_wg1
option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МК2'
list allowed_ips '192.168.31.2'
config wireguard_wg1ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.3
option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МК3'
list allowed_ips '192.168.31.3'
Cyfluniad WireGuard ar MK2 (wedi'i ychwanegu at /etc/config/network)
#VPN первого уровня - клиент
config interface 'wg0'
option proto 'wireguard'
list addresses '192.168.30.3/24'
option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_1_МК2'
option auto '1'
option mtu '8000'
config wireguard_wg0
option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_1_VPS'
option endpoint_port '51820'
option persistent_keepalive '25'
list allowed_ips '192.168.30.0/24'
option endpoint_host 'IP_АДРЕС_VPS'
#VPN второго уровня - клиент
config interface 'wg1'
option proto 'wireguard'
option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_2_МК2'
list addresses '192.168.31.2/24'
option auto '1'
option listen_port '51821'
option mtu '7500'
config wireguard_wg1
option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МС'
option endpoint_host '192.168.30.2'
option endpoint_port '51821'
option persistent_keepalive '25'
list allowed_ips '192.168.31.0/24'
Cyfluniad WireGuard ar MK3 (wedi'i ychwanegu at /etc/config/network)
#VPN первого уровня - клиент
config interface 'wg0'
option proto 'wireguard'
list addresses '192.168.30.4/24'
option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_1_МК3'
option auto '1'
option mtu '8000'
config wireguard_wg0
option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_1_VPS'
option endpoint_port '51820'
option persistent_keepalive '25'
list allowed_ips '192.168.30.0/24'
option endpoint_host 'IP_АДРЕС_VPS'
#VPN второго уровня - клиент
config interface 'wg1'
option proto 'wireguard'
option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_2_МК3'
list addresses '192.168.31.3/24'
option auto '1'
option listen_port '51821'
option mtu '7500'
config wireguard_wg1
option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МС'
option endpoint_host '192.168.30.2'
option endpoint_port '51821'
option persistent_keepalive '25'
list allowed_ips '192.168.31.0/24'
Yn y ffurfweddiadau a ddisgrifir ar gyfer VPN ail-lefel, rwy'n pwyntio cleientiaid WireGuard i borthladd 51821. Mewn theori, nid yw hyn yn angenrheidiol, gan y bydd y cleient yn sefydlu cysylltiad o unrhyw borthladd di-freintiedig am ddim, ond fe'i gwnes fel ei bod yn bosibl gwahardd pob cysylltiad sy'n dod i mewn ar ryngwynebau wg0 pob llwybrydd ac eithrio cysylltiadau CDU sy'n dod i mewn i borth 51821.
Rwy'n gobeithio y bydd yr erthygl yn ddefnyddiol i rywun.
PS Hefyd, rwyf am rannu fy sgript sy'n anfon hysbysiad PUSH i'm ffôn yn y cymhwysiad WirePusher pan fydd dyfais newydd yn ymddangos ar fy rhwydwaith. Dyma'r ddolen i'r sgript: .
DIWEDDARIAD: Ffurfweddiad gweinydd OpenVPN a chleientiaid
Gweinydd OpenVPN
client-to-client
ca /etc/openvpn/server/ca.crt
cert /etc/openvpn/server/vpn-server.crt
dh /etc/openvpn/server/dh.pem
key /etc/openvpn/server/vpn-server.key
dev tap
ifconfig-pool-persist /etc/openvpn/ipp.txt 0
keepalive 10 60
proto tcp4
server-bridge 192.168.10.1 255.255.255.0 192.168.10.80 192.168.10.254
status /var/log/openvpn-status.log
verb 3
comp-lzoCleient OpenVPN
client
tls-client
dev tap
proto tcp
remote VPS_IP 1194 # Change to your router's External IP
resolv-retry infinite
nobind
ca client/ca.crt
cert client/client.crt
key client/client.key
dh client/dh.pem
comp-lzo
persist-tun
persist-key
verb 3
Defnyddiais easy-rsa i gynhyrchu tystysgrifau
Ffynhonnell: hab.com