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
Y protocol a ddewiswyd i weithredu'r dasg hon oedd yn wreiddiol OpenVPN, oherwydd, yn gyntaf, gall greu dyfais tap y gellir ei hychwanegu at y bont heb unrhyw broblemau, ac yn ail, OpenVPN Mae'n cefnogi TCP, a oedd hefyd yn bwysig, gan nad oedd gan yr un o'r fflatiau gyfeiriad IP pwrpasol. Doeddwn i ddim yn gallu defnyddio STUN oherwydd bod fy ISP, am ryw reswm, yn rhwystro cysylltiadau UDP sy'n dod i mewn o'i rwydweithiau. Roedd TCP yn caniatáu i mi anfon porthladd y gweinydd VPN ymlaen i'r VPS rhent gan ddefnyddio SSH. Er bod y dull hwn yn creu gorbenion sylweddol, gan fod y data wedi'i amgryptio ddwywaith, doeddwn i ddim eisiau integreiddio'r VPS i'm rhwydwaith preifat, gan fod risg y byddai trydydd partïon yn cael rheolaeth drosto. Felly, roedd cael dyfais o'r fath ar fy rhwydwaith cartref yn annymunol iawn, felly penderfynais dalu gorbenion sylweddol am ddiogelwch.
I anfon y porthladd ymlaen ar y llwybrydd lle roedd y gweinydd wedi'i gynllunio i gael ei ddefnyddio, defnyddiais y rhaglen sshtunnel. Wna i ddim mynd i fanylion ei ffurfweddiad—mae'n eithaf hawdd. Nodaf mai ei bwrpas oedd anfon porthladd TCP 1194 ymlaen o'r llwybrydd i'r VPS. Nesaf, ffurfweddais y gweinydd. OpenVPN Ar y ddyfais tap0, a oedd wedi'i chysylltu â'r bont br-lan. Ar ôl profi'r cysylltiad â'r gweinydd newydd ei greu o fy ngliniadur, daeth yn amlwg bod y syniad anfon porthladdoedd ymlaen wedi gweithio, ac roedd fy ngliniadur wedi dod yn aelod o rwydwaith y llwybrydd, er nad oedd yn rhan ohono'n gorfforol.
Yr unig beth oedd ar ôl i'w wneud oedd dosbarthu cyfeiriadau IP mewn gwahanol fflatiau fel na fyddent yn gwrthdaro a ffurfweddu'r llwybryddion fel OpenVPN-cleientiaid.
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 hefyd angen aseinio'r cyfeiriadau hyn i'r llwybryddion cleient. OpenVPN-gweinydd, trwy ychwanegu'r llinell ganlynol 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 mae flat1_id a flat2_id yn enwau'r dyfeisiau a bennir wrth greu tystysgrifau ar gyfer cysylltu â OpenVPN
Nesaf, ffurfweddwyd y llwybryddion OpenVPN- cleientiaid, ychwanegwyd dyfeisiau tap0 ar y ddau at y bont br-lan. Ar y pwynt hwn, roedd popeth yn ymddangos yn iawn, gan y gallai'r tri rhwydwaith weld ei gilydd a gweithredu fel un uned. Fodd bynnag, daeth manylyn braidd yn annymunol i'r amlwg: weithiau byddai dyfeisiau'n derbyn cyfeiriad IP o'r llwybrydd anghywir, gyda'r holl ganlyniadau a ddilynodd. Am ryw reswm, methodd y llwybrydd yn un o'r fflatiau ag ymateb i DHCPDISCOVER mewn pryd, a derbyniodd y ddyfais y cyfeiriad anghywir. Sylweddolais fod angen i mi hidlo ceisiadau o'r fath yn tap0 ar bob llwybrydd, ond fel y digwyddodd, ni all iptables weithio gyda dyfais os yw'n rhan o bont, felly roedd angen i mi ddefnyddio ebtables. Yn anffodus, nid oedd fy firmware yn ei gynnwys, felly roedd yn rhaid i mi ailadeiladu'r delweddau ar gyfer pob dyfais. Ar ôl gwneud hyn ac ychwanegu'r llinellau canlynol at /etc/rc.local ar bob 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: Dod i Adnabod WireGuard
Yn ddiweddar, bu mwy o sôn ar y Rhyngrwyd am WireGuard, gan edmygu ei hwylustod ffurfweddu, cyflymder trosglwyddo uchel, ping isel, a diogelwch cymharol. Datgelodd chwiliad am wybodaeth ychwanegol amdano nad yw'n cefnogi cefnogaeth i aelodau'r bont na'r protocol TCP, a arweiniodd fi i gredu nad oedd dewis arall. OpenVPN i mi, dydy o dal ddim yno. Felly gohiriais ddod i adnabod WireGuard.
Ychydig ddyddiau yn ôl, lledaenodd newyddion trwy adnoddau sy'n gysylltiedig â TG mewn un ffordd neu'r llall a WireGuard bydd yn cael ei gynnwys yn y cnewyllyn o'r diwedd Linux, gan ddechrau gyda fersiwn 5.6. Cafodd erthyglau newyddion, fel bob amser, ganmoliaeth WireGuardUnwaith eto, plymiais i chwilio am ffyrdd i gymryd lle'r hen bethau da OpenVPNY tro hwn, fe wnes i redeg i mewn i . 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 chi 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 allan o'r bont ac yn ei rhedeg OpenVPN Ar y llwybrydd yn fflat 2, cadarnheais fod y rhwydwaith yn gweithio'n iawn eto ac nad oedd cysylltiadau'n colli. Wrth chwilio, des i ar draws fforymau lle'r oedd pobl yn cwyno am yr un problemau, a lle cawsant eu cynghori i godi'r MTU. Cyn gynted ag y dywedwyd hynny, gwnaed hynny. Fodd bynnag, nes bod yr MTU wedi'i osod yn ddigon uchel—7000 ar gyfer dyfeisiau gretap—profiais naill ai gysylltiadau TCP wedi colli neu gyflymder trosglwyddo isel. Oherwydd yr MTU uchel ar gyfer gretap, yr MTU ar gyfer cysylltiadau WireGuard Gosodwyd y lefelau cyntaf a'r ail ar 8000 a 7500 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 yn cysylltu â'r gweinydd am ryw reswm. Ar ôl cysylltu â'u SSH (diolch byth, roeddwn i wedi ffurfweddu sshtunnel ar gyfer hyn o'r blaen), darganfyddais fod WireGuard Am ryw reswm, mae'n creu llwybr ar gyfer y pwynt terfynol, ond mae'n anghywir. Er enghraifft, ar gyfer 192.168.30.2, nododd y tabl llwybr lwybr trwy'r rhyngwyneb pppoe-wan, h.y., trwy'r rhyngrwyd, er y dylai'r llwybr iddo fod wedi'i gyfeirio trwy'r rhyngwyneb wg0. Ar ôl dileu'r llwybr hwn, adferwyd y cysylltiad. A allaf ddod o hyd i gyfarwyddiadau yn unrhyw le ar sut i orfodi WireGuard Doeddwn i ddim yn gallu osgoi creu'r llwybrau hyn. Ar ben hynny, doeddwn i ddim hyd yn oed yn deall a oedd hyn yn nodwedd o OpenWRT neu o'r WireGuardHeb dreulio llawer o amser yn darganfod y broblem, ychwanegais linell at y sgript sy'n seiliedig ar amserydd ar y ddau lwybrydd a ddileodd y llwybr hwn:
route del 192.168.30.2
Crynhoi
Gwrthodiad llwyr OpenVPN Dydw i ddim wedi cyflawni hyn eto, gan fod angen i mi gysylltu â rhwydwaith newydd o liniadur neu ffôn o bryd i'w gilydd, ac mae sefydlu dyfais gretap arnyn nhw fel arfer yn amhosibl. Fodd bynnag, er gwaethaf hyn, rydw i wedi ennill mantais o ran cyflymder trosglwyddo data rhwng fflatiau, ac mae defnyddio VNC, er enghraifft, bellach yn ddi-drafferth. Mae Ping wedi gostwng ychydig ond wedi dod yn fwy sefydlog:
Gan 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
Gan 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, yn y fflat gyda'r llwybrydd-gweinydd, mae gen i gyflymder cysylltiad rhyngrwyd o 30 Mbps, ac yn y fflatiau eraill mae'n 5 Mbps. Ar ben hynny, yn ystod y defnydd OpenVPN Doeddwn i ddim yn gallu cyflawni cyflymder trosglwyddo data rhwng rhwydweithiau yn fwy na 3,8 Mbps yn ôl darlleniadau iperf, tra WireGuard "pwmpio" ef i fyny i'r un 5 Mbit/eiliad.
Ffurfweddiad WireGuard ar VPS[Interface]
Address = 192.168.30.1/24
ListenPort = 51820
PrivateKey = <ЗАКРЫТЫЙ_КЛЮЧ_ДЛЯ_VPS>
[Cymheiriaid]
Allwedd Gyhoeddus = <VPN_1_MS_PUBLIC_KEY>
AllowedIPs = 192.168.30.2/32
[Cymheiriaid]
Allwedd Gyhoeddus = <VPN_2_MK2_ALLWEDD_GYHWYSAIDD>
AllowedIPs = 192.168.30.3/32
[Cymheiriaid]
Allwedd Gyhoeddus = <VPN_2_MK3_ALLWEDD_GYHWYSAIDD>
AllowedIPs = 192.168.30.4/32
Ffurfweddiad 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'
Ffurfweddiad 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'
Ffurfweddiad 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 yr ail lefel VPN, rwy'n nodi i gleientiaid WireGuard Porthladd 51821. Ni ddylai hyn fod yn angenrheidiol, gan y bydd y cleient yn sefydlu cysylltiad o unrhyw borthladd rhydd, heb fraint, ond fe wnes i hyn fel y gallwn wrthod pob cysylltiad sy'n dod i mewn ar ryngwynebau wg0 pob llwybrydd, ac eithrio cysylltiadau UDP sy'n dod i mewn i borthladd 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 OpenVPN-gweinyddion a chleientiaid
OpenVPN-gweinydd
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-lzoOpenVPN-cleient
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
