Statyske OpenVPN-klantadressen efter OPNsense
In poelbestân makket in adres kleverich, net permanint. Pin klantadressen fêst mei oerskriuwings, ferdiel it tunnelberik foar de /30-rekkenkunde, en publisearje se dan.
Nammen hawwe adressen nedich dy’t net bewege, en it poelbestân fan OpenVPN makket in adres allinnich kleverich. Ferlieze dat bestân, of jou in sertifikaat opnij út ûnder in oare gewoane namme, en de weromkommende klant belânet earne oars yn ’e poel wylst syn DNS-register noch nei it âlde adres wiist. It duorsume antwurd is in klientspesifike oerskriuwing dy’t it adres fêstpint, plus in breder tunnelnetwurk sadat fêstpine adressen bûten it dynamyske berik lizze. De rekkenkunde efter dy ferdieling is wêr’t it measte betizing wennet.
OPNsense hâldt dy oerskriuwings yn ’e klientspesifike ynstellingen fan ’e tsjinner, kaaiere op ’e gewoane namme fan it sertifikaat, wat de gewoane namme diel fan it adresplan makket.
In kleverige lease is gjin statysk adres
It poelbestân skriuwt adres-nei-klant-kaarten en jout se werom as in bekende klant opnij ferbynt. Dat is gemak yn stee fan in kontrakt: it bestân kin opnij generearre wurde, de kaart ferdwynt as de identiteit fan ’e klant feroaret, en twa tsjinners dy’t in poel diele sille it net iens wêze. In klientspesifike oerskriuwing wurket oars, want it adres komt út konfiguraasje yn stee fan út skiednis. Se oerlibbet ek in werstart en in weromynstallaasje fan it apparaat, mits de oerskriuwing mei de rest fan ’e konfiguraasje bewarre wurdt.
It dynamyske alternatyf, de VPN mei in klantferbiningsskript en dynamyske bywurkingen yn DNS bekabelje, wurket en freget in resolver dy’t bywurkingen akseptearret plus in skript by elke ferbining. Op in apparaat binne jo beheind ta de pakketten dy’t de leveransier stjoert, en dat is meast wêr’t dat plan stjit.
De /30-rekkenkunde dêr’t nimmen fan hâldt
Under de standert net30-topology krijt elke klant syn eigen /30: it earste brûkbere adres giet nei de tsjinnerkant, it twadde nei de klant. Oerskriuwings moatte dêrom bûten it dynamyske tunnelnetwurk fan ’e tsjinner lizze, wat betsjut dat dat netwurk earst ferdield wurde moat. In tsjinner op 10.8.0.0/24 kin nei 10.8.0.0/23 ferhúzje, wêrby’t de helte fan it âlde berik foar dynamyske klanten bliuwt en de oare helte foar oerskriuwings. Foegje it orizjinele /24 ta as ekstra lokaal IPv4-netwurk sadat ferkear nei beide helten de tunnel yn giet.
Elk oerskriuwingsadres moat op in /30-grins lânje, dus it lêste oktet is in mearfâld fan fjouwer. In /30 op 10.8.1.0 jout de klant 10.8.1.2, en dat is it adres dat it DNS-register draacht. As jo ynstee 10.8.1.3 kieze, krije jo in klant dy’t ferbynt en gjin ferkear trochjaan kin, want it adres heart by in subnet dat de topology him nea tawiisd hat.
It plan is makliker te hâlden as oerskriuwings fan ’e boppekant fan it ferdiele berik nei ûnderen tawiisd wurde, sadat de dynamyske poel yn frije romte útwreidet yn stee fan om fêste eilannen hinne.
Lokale netwurken en de sône dy’t klanten freegje
Klant-nei-klant-ferkear hat syn eigen tastimming nedich. De list mei lokale IPv4-netwurken fan ’e tsjinner moat beide helten fan it berik befetsje, dynamysk en statysk; sûnder dy list akseptearret de tsjinner in pakket fan ien klant en hat gjin belied dat it nei in oare trochlitte. It symptoom lêst as in DNS-flater, want de namme wurdt oplost en de ferbining mislearret dochs. Kontrolearje tagelyk de ynstelling klant-nei-klant, want in yngong foar in lokaal netwurk allinnich makket trochstjoeren tusken peers net mooglik.
Publisearje de registers yn ’e sône dy’t fiere klanten wier freegje. In register yn in sône dy’t allinnich troch de LAN-resolver betsjinne wurdt, is ûnsichtber foar in klant waans ta-stjoerde resolver earne oars wiist, en mear registers oan ’e ferkearde sône taheakje makket dat nea goed. Befêstigje de ta-stjoerde DNS-opsje en it sykdomein foardat jo eat taheakje.
Wat te kontrolearjen op in nije ferbining
Ferbin de klant opnij en befêstigje dat it tawiisde adres by syn oerskriuwing past foardat jo eat oars testen. Los dan de namme op fan in twadde klant en ferbin mei de tsjinst by namme, wat it DNS-register, de rûte en de firewall tagelyk op ’e proef stelt. Befêstigje it antwurdrûte oan ’e tsjinnerkant, want in namme dy’t oplost wylst de tsjinst ûnberikber bliuwt, is in rûte- of beliedsprobleem yn stee fan in nammeprobleem. Hâld de oerskriuwingstabel neist de sertifikaatlist sadat beide gear besjoen wurde.
In sertifikaat dat ûnder in oare gewoane namme opnij útjûn wurdt, past net mear by syn oerskriuwing en stjoert de klant werom nei de dynamyske poel. Ferwachtsje dat nei elke identiteitsferoaring.