Twa tsjinstadressen op ien OpenVPN-klant: iroute en lo

De applikaasje antwurdet op syn tunneladres, en it adres dat jo dêrfoar dokumintearre hawwe, giet nearne hinne. Neat yn it OpenVPN-loch kleit, de peer liket ferbûn, en de hub listet krekt ien klant. It gat is dat in twadde adres op in klant twa aparte feiten binne: de host moat it besitte, en de hub moat witte hokker peer it besit. Behandelje ien sûnder de oare en it ferkear stjert by de hub of komt oan sûnder rûte nei hûs.

It alias is lokaal, it eigendom is op ôfstân

In tunneladres wurdt ûnderhannele, sadat beide kanten it yn ’e hânskodding leare. In ekstra tsjinstadres wurdt hielendal net ûnderhannele, en dêrom feroaret it tafoegjen derfan op himsels neat op ’e hub. De klant kin it adres daliks besitte en de tsjinner sil dat ferkear dochs nei syn standertpaad stjoere of it falle litte. Twa records moatte makke wurde, op twa ferskillende plakken.

Op ’e klant heart it adres by de host, en loopback is it natuerlike thús foar in tsjinstidentiteit dy’t nea op in fysike keppeling ferskine moat. Op ’e hub is de peer-oan-prefiks-kaart in aparte ferklearring dy’t allinnich de tsjinner lêst. Gjin fan beide records ymplisearret de oare.

Hâld de twa berikken ek apart yn jo notysjes. Adressen yn in foarbyld binne dokumintaasjewearden, en se oerlaapje mei in echte LAN is de fluchste manier om in wurkjende opset as brutsen lykje te litten.

Foegje it adres permanint ta op ’e klant

Set it tsjinstadres op loopback mei in host-prefiks, sadat de host it as lokale ynfier behannelet ynstee fan as in subnet om te berikken. ip address add 10.66.0.10/32 dev lo docht dat foar ien adres, en it werheljen fan it kommando foar in twadde adres modellearret twa tsjinsten.

Rin dat as in ienmalige test, ferpleats it dan nei wat de netwurkkonfiguraasje fan ’e host besit, want in tafoeging by runtime ferdwynt by it opnij opstarten en duplikaten sammelje har oer werferbiningen. In systemd-ienheid oardere nei it netwurk is ien opsje, en in distribúsjenetwurkbehearder is in oare. Hokker jo ek kieze, it adres moat bestean foardat de applikaasje bynt, oars komt de tsjinst op ’e ferkearde socket. Ferifiearje mei ip address show dev lo nei in opnij opstarten ynstee fan nei it manuele kommando.

Binen is in beslissing apart fan adressearjen. In applikaasje dy’t op elk adres harket, akseptearret ferkear op ynterfaces dy’t jo nea bedoeld hawwe, dus rjochtsje it op it spesifike tsjinstadres. Dan hat it lokale ynfierbelied wat krefts om mei te oerienkommen.

Forderje it op yn it CCD-bestân dat de hub echt lêst

Op ’e tsjinner giet de eigendomsferklearring yn it bestân per klant dat troch de autentisearre mienskiplike namme keazen wurdt, binnen de map neamd troch client-config-dir. De rigel is iroute 10.66.0.10 255.255.255.255, ien per adres, en fertelt de tsjinner hokker peer ferkear foar dy bestimming ûntfange moat.

Twa details brekke dit stil. De bestânsnamme moat oerienkomme mei de namme dy’t de tsjinner echt brûkt, dy’t ferskilt as username-as-common-name yn it spul is. En iroute jildt allinnich yn TUN-modus mei in konfigurearre klientskonfiguraasjemap, dus deselde rigel docht neat yn in brêge-opset. Foegje rigels ta oan it besteande bestân ynstee fan it te ferfangen, want it kin al in fêst adres of push-opsjes drage. De OpenVPN 2.6-referinsje dokumintearret sawol de map as de eigendomsdirektive.

De eigen kernel fan ’e hub hat ek in paad nei dy bestimmingen nedich, sadat lokaal generearre ferkear it tunnelproses ynkomt. route 10.66.0.10 255.255.255.255 yn ’e tsjinnerkonfiguraasje dekt ferkear dat de tsjinner sels ûntstiet, wylst oare klanten push "route 10.66.0.10 255.255.255.255" nedich hawwe om de bestimming sels te learen.

Rûtearjen en autorisaasje bliuwe apart. In tawiisde rûte fertelt in klant wêr’t pakketten hinne moatte en jout neat; de tsjinst moat de opropper noch altyd op eigen betingsten akseptearje.

Kontrolearje ynfierbelied en it antwurdpaad

In pakket dat nei it alias adressearre is, komt by de besittende host oan as lokale ynfier, dus de fraach is oft de lokale firewall dy boarne en poarte tastiet. Stean de spesifike tsjinstpoarte fan it VPN-boarneberik ta ynstee fan it hiele adres te iepenjen.

Antwurden hawwe in paad werom nei de opropper nedich. Foar in opropper yn ’e normale tunnelpool bestiet dat paad al, want it tunneleapparaat draacht it. In opropper efter in oar rûtearre netwurk hat ek de weromrûte fan dat netwurk nedich, en hjir ferlieze asymmetryske opsetten pakketten.

Let op in twadde harker op deselde poarte bûn oan in oar adres, want de kernel leveret oan hokker socket dan ek past en de resultaten lykje willekeurich. Kontrolearje mei ss -lntp en befêstigje dat it bûne adres it tsjinstalias is. Boarne-NAT is hjir net nedich, en it tafoegjen ferberget de identiteit fan ’e opropper dêr’t jo lochs fan ôfhingje.

Test adressen en eigendom apart

Test yn twa stappen. Befêstigje earst dat de besittende host de tsjinst op syn alias fan himsels berikke kin, wat bind- en firewallproblemen fan rûtearjen skiedt. Test dan fan in echte VPN-opropper mei de autentikaasje fan ’e applikaasje sels. As de earste slagget en de twadde mislearret, leit it ûntbrekkende stik oan ’e hubkant.

Kontrolearje ek de mislearringsmodi dy’t in ferbining oerlibje: it alias bliuwt tawiisd as de tunnel del is, en de hub hâldt syn rûte as de peer ôfwêzich is. Gjin objekt bewiist allinnich dat de tsjinst berikber is, en dêrom ferslacht de twastaptest in inkele ping fan in laptop.