Twee diensadresse op een OpenVPN-kliënt: iroute en lo

Die toepassing antwoord op sy tonneladres, en die adres wat jy daarvoor gedokumenteer het, loop nêrens heen nie. Niks in die OpenVPN-log kla nie, die eweknie wys as gekonnekteer, en die hub lys presies een kliënt. Die gaping is dat ’n tweede adres op ’n kliënt twee aparte feite is: die gasheer moet dit besit, en die hub moet weet watter eweknie dit besit. Hanteer een sonder die ander en verkeer sterf óf by die hub óf kom aan sonder ’n roete huis toe.

Die alias is plaaslik, die eienaarskap is op die afstand

’n Tonneladres word onderhandel, so beide kante leer dit tydens die handdruk. ’n Ekstra diensadres word glad nie onderhandel nie, en daarom verander dit op sigself niks op die hub nie. Die kliënt kan die adres onmiddellik besit en die bediener sal steeds daardie verkeer na sy verstekroete stuur of dit laat val. Twee rekords moet geskep word, op twee verskillende plekke.

Op die kliënt behoort die adres aan die gasheer, en loopback is die natuurlike tuiste vir ’n diensidentiteit wat nooit op ’n fisiese skakel moet verskyn nie. Op die hub is die eweknie-tot-voorvoegsel-kaart ’n aparte verklaring wat net die bediener lees. Nie een rekord impliseer die ander nie.

Hou die twee reekse ook apart in jou notas. Adresse in ’n voorbeeld is dokumentasiewaardes, en om hulle met ’n werklike LAN te oorvleuel is die vinnigste manier om ’n werkende opstelling as stukkend te laat lyk.

Voeg die adres permanent op die kliënt by

Plaas die diensadres op loopback met ’n gasheervoorvoegsel, sodat die gasheer dit as plaaslike inset behandel eerder as as ’n subnet om te bereik. ip address add 10.66.0.10/32 dev lo doen dit vir een adres, en om die opdrag vir ’n tweede adres te herhaal, modelleer twee dienste.

Voer dit as ’n eenmalige toets uit en skuif dit dan na wat die gasheer se netwerkkonfigurasie besit, want ’n byvoeging tydens looptyd verdwyn by herbegin en duplikate hoop op oor herverbindings. ’n systemd-eenheid wat ná die netwerk georden is, is een opsie, en ’n distribusienetwerkbestuurder is ’n ander. Watter een jy ook kies, die adres moet bestaan voordat die toepassing bind, anders kom die diens op die verkeerde sok op. Verifieer met ip address show dev lo ná ’n herbegin eerder as ná die handmatige opdrag.

Binding is ’n aparte besluit van adressering. ’n Toepassing wat op elke adres luister, aanvaar verkeer op koppelvlakke wat jy nooit bedoel het nie, so wys dit na die spesifieke diensadres. Plaaslike insetbeleid het dan iets presies om teen te pas.

Eis dit op in die CCD-lêer wat die hub werklik lees

Op die bediener gaan die eienaarskapverklaring in die per-kliënt-lêer wat deur die geauthentiseerde gemeenskaplike naam gekies word, binne die gids wat deur client-config-dir genoem word. Die reël is iroute 10.66.0.10 255.255.255.255, een per adres, en dit sê vir die bediener watter eweknie verkeer vir daardie bestemming moet ontvang.

Twee besonderhede breek dit stilweg. Die lêernaam moet ooreenstem met die naam wat die bediener werklik gebruik, wat verskil wanneer username-as-common-name in die spel is. En iroute tree net in TUN-modus in werking met ’n kliëntkonfigurasiegids wat opgestel is, so dieselfde reël doen niks in ’n oorbrugde ontplooiing nie. Voeg reëls by die bestaande lêer eerder as om dit te vervang, want dit kan reeds ’n vaste adres of push-opsies dra. Die OpenVPN 2.6-verwysing dokumenteer beide die gids en die eienaarskapdirektief.

Die hub se eie kern het ook ’n pad na daardie bestemmings nodig, sodat plaaslik gegenereerde verkeer die tonnelproses binnegaan. route 10.66.0.10 255.255.255.255 in die bedienerkonfigurasie dek verkeer wat die bediener self begin, terwyl ander kliënte push "route 10.66.0.10 255.255.255.255" nodig het om die bestemming self te leer.

Roetering en magtiging bly apart. ’n Gepushde roete sê vir ’n kliënt waarheen om pakkette te stuur en verleen niks nie; die diens moet die oproeper steeds op sy eie voorwaardes aanvaar.

Kontroleer insetbeleid en die antwoordpad

’n Pakket wat aan die alias gerig is, kom by die besittende gasheer aan as plaaslike inset, so die vraag is of die plaaslike firewall daardie bron en poort toelaat. Laat die spesifieke dienspoort uit die VPN-bronreeks toe eerder as om die hele adres oop te maak.

Antwoorde het ’n roete terug na die oproeper nodig. Vir ’n oproeper binne die normale tonnelpoel bestaan daardie pad reeds, want die tonneltoestel dra dit. ’n Oproeper agter ’n ander geroteerde netwerk het ook daardie netwerk se terugroete nodig, en dit is waar asimmetriese opstellings pakkette verloor.

Let op ’n tweede luisteraar op dieselfde poort wat aan ’n ander adres gebind is, want die kern lewer aan watter sok ook al pas, en die resultate lyk willekeurig. Kontroleer met ss -lntp en bevestig dat die gebinde adres die diensalias is. Bron-NAT is hier nie nodig nie, en om dit by te voeg, verberg die oproeper se identiteit waarvan jou logs afhang.

Toets adresse en eienaarskap afsonderlik

Toets in twee stappe. Bevestig eers dat die besittende gasheer die diens op sy alias van homself af kan bereik, wat bind- en firewallprobleme van roetering skei. Toets dan van ’n werklike VPN-oproeper met die toepassing se eie authenticatie. Wanneer die eerste slaag en die tweede misluk, is die ontbrekende stuk aan die hub-kant.

Kontroleer ook die foutmodusse wat ’n verbinding oorleef: die alias bly toegewys wanneer die tonnel af is, en die hub hou sy roete wanneer die eweknie afwesig is. Nie een objek alleen bewys dat die diens bereikbaar is nie, en daarom is die tweestaptoets beter as ’n enkele ping vanaf ’n skootrekenaar.