De VPN is ferhuze: wêrom't jo OpenVPN-klant noch it âlde IP skillet

De provider feroare jo iepenbiere adres, jo hawwe it dynamyske DNS-record bywurke, en de klant kin noch altyd net ferbine. Fan bûten liket it as is it record net útstoarn. Meastentiids is it record goed en skillet de klant it adres dat it foar de ferhuzing oplost hat, om't in rinnende tunnel en in bewarre profyl elk har eigen byld hawwe fan wêr't de server wennet. Trije lagen moatte it iens wêze, en se wurde bywurke neffens ferskillende skema's.

Sjoch wat it profyl skillet, net wat DNS seit

Iepenje de ferbining dy't jo echt brûke en lês de remote-rigel. In nûmerike adres dêre folget nea in hostname-bywurking, hoe korrekt it record ek wurdt.

Kontrolearje dan oft it profyl dat jo bewurke hawwe dat is dat de klant laden hat. Ymportearre profylen binne gewoan: in behearder hat miskien moannen lyn in kopy nommen en syn eigen ferzje holden, dat it bestân yn jo downloadmap en de yngong yn 'e app kinne ferskille. Fergelykje it einpunt yn 'e eigen ferbiningsdetails fan 'e klant foar't jo DNS hielendal debugge.

Twa bestannen, ien einpunt — dat is hjir de gewoane fynst.

grep -nE '^remote|^resolv-retry|^persist-remote-ip|^float' client.ovpn
printf 'resolver says: '; dig +short vpn.example.net

Lês de folgjende ferbiningspoging fan 'e klant

Werstart de ferbining mei wiidweidige logging en lês de rigel wêryn it adres neamd wurdt dat it kontaktet. Dy wearde is wichtich, net wat jo browser oplost hat.

In resolver-cache kin it foarige antwurd noch hâlde, en guon netwurken hâlde it langer as't de TTL fan it record freget. Freegje de resolver dy't de klant echt brûkt, ynstee fan in iepenbiere dy't jo fan earne oars test hawwe.

As it logboek it nije adres sjen lit en de ferbining noch mislearret, is it probleem ferhuze: it pakket giet earne hinne en nimmen antwurdet. Dat is in fraach oer in listener, firewall of portforwarding, en it leit oan 'e serverkant ynstee fan yn it oplossingspaad fan 'e klant. Hâld dy twa mislearrings apart, want in net berikbere listener as DNS-probleem behannelje stjoert jo twa kear troch deselde lus.

Wit hokker werstart jo dogge

Net alle werstarts behâlde deselde steat, dêrom kin in adresferoaring oars gedrage ôfhinklik fan hoe't it proses weromset wurdt. In sêfte werstart dy't troch in sinjaal útloche is, behâldt mear fan 'e kontekst fan 'e foarige sesje, wylst in folsleine stop en start wer fan 'e konfiguraasje begjint. As jo testje oft de klant opnij oplost, wolle jo it paad dat fan 'e konfiguraasje begjint.

Persistinsje-ynstellingen binne ek fan belang, om't se ûntwurpen binne om te hâlden wat autentisearre is, net om nije adressen efternei te jeien.

De skjinste test is in frisse start fan it bedoelde profyl, folge troch in blik op 'e logrigel dy't it einpunt neamt. Alles wat jo leare fan in diels bewarre sesje is in bewearing oer dy sesje.

De fjouwer opsjes en har aparte taken

remote mei in hostname is de ynstelling dy't opnij oplossen hielendal mooglik makket; in letterlik adres op dy rigel slút it út. resolv-retry regelet wat der bart as in syktocht mislearret, en 2.6 set it al standert op ûneinich. It tafoegjen feroaret dus neat, en it plannet nea in periodike kontrôle foar in oar antwurd. Wa't seit dat it nije adressen ûndersiket, hat herstel mei farskens betize.

persist-remote-ip giet oer trochgeandheid, net oer farskens: it brûkt it einpunt wer dat it lêst autentisearre, oer de sêfte werstarts dy't it stipet. Wylst jo in ferhuzing testje, is dat it tsjinoerstelde fan wat jo wolle. Skeakelje it út foar de test as jo build it ynskeakelet, en set it werom as it nije einpunt bewiisd is. Ynskakele litten kin in slagge werferbining jo neat oer DNS fertelle.

float akseptearret in autentisearre peer waans adres healwei de sesje feroare is, en allinnich yn opstellings dy't dat stypje. It fernijt DNS net, en it sil in providerferoaring net fan sels folgje. Behannele it as in fearkrêftfunksje foar peers dy't roamje, net as in meganisme foar dynamyske adressen foar servers.

Befêstigje it nije einpunt foar't jo de klant de skuld jouwe

Fan bûten jo netwurk, kontrolearje dat it nije adres in listener hat op 'e konfigurearre port en dat de trochstjoering fan 'e provider dêrhinne wiist. In korrekt A-record foar in masine sûnder iepen port produsearret krekt it symptoom dat minsken oan caching taskriuwe.

Ferbine dan opnij en ferifiearje twa dingen: de klant hat autentisearre tsjin it ferwachte servercertifikaat, en de sesje berikt de boarne dy't jo bedoelden. In adresferoaring ferleget de identiteitseasken net, en in ferbining dy't slagget nei it ferkearde einpunt is slimmer as ien dy't mislearret. De OpenVPN 2.6-hânlieding listet alle fjouwer opsjes mei har eigen berik, en dat is de checklist om njonken it profyl te hâlden.

Hâld in bûtenbânse wei nei de server foar't jo de tunnel werstarte dy't jo behearderstagong draacht. Dy iene foarsichtigens foarkomt de measte foarfallen dy't dit senario produsearret.