VPN-eindpunt-toelaatlys: Die DNS-opdatering wat jy vergeet het
'n Firewall-uitsondering vir 'n VPN-gasheernaam is nie 'n lewendige DNS-intekening nie. Besluit wie dit oplos, wanneer die stel verfris en wat 'n mislukte opsoek moet doen.
Om vpn.example.com in 'n firewall-uitsondering te tik voel soos om op DNS in te teken. Wat gewoonlik gebeur, is 'n vertaling by laaietyd, waarna die reël adresse hou en niks dit verfris nie. Twee komponente deel nou die werk: die oplosser wat antwoord en die firewall wat stoor. Die meeste eindpunt-onderbrekings begin waar daardie oorhandiging nooit ontwerp is nie.
'n Gasheernaam in 'n reël is nie 'n lewendige intekening nie
Party gereedskap los 'n naam op wanneer die konfigurasie laai; ander hou 'n gasheernaam en los dit self weer op; nog ander aanvaar net adresse. Die sigbare konfigurasie sê selde watter. Dokumentasievoorbeelde aanvaar gewoonlik die laaityd-geval, daarom verras die verskil mense tydens 'n migrasie. Lees die implementering se gedrag voordat jy aanvaar dat 'n adresverandering raakgesien sal word, want 'n verouderde toelaatlys lyk presies soos een wat werk totdat die eindpunt verskuif.
'n Reël wat die regte gasheer noem, kan steeds die verkeerde adres toelaat. Daardie gaping is die mite, nie 'n spelfout nie.
Kas-TTL is nie jou firewall se tydhouer nie
DNS-rekords dra 'n tyd om te lewe, en oplossers kas antwoorde vir daardie tydperk. Die DNS-spesifikasie definieer daardie kasgedrag, maar dit beheer DNS-data, nie 'n firewall se aparte adresstoor nie. 'n Kort TTL skep nie 'n verfrissingswerk waar daar geen is nie. Kaswerk gebeur ook op meer as een laag, so die antwoord wat 'n terminaal sien is dalk nie die een wat die firewall gesien het nie.
Vra drie vrae aan die werklike produk: wanneer dit oplos, waar dit die resultaat stoor, en wat 'n opdatering veroorsaak. As die antwoord net by selflaai is, kan 'n langdurige sessie die adres oorleef waartoe dit toegelaat is.
dig +short vpn.example.com
resolvectl query vpn.example.com
Ontwerp verfrissing en mislukking as een beleid
'n Onderhoude uitsondering het eksplisiete antwoorde nodig: wat 'n verfrissing veroorsaak voordat die kliënt 'n nuwe adres kies, hoe die toegelate stel verander sonder om 'n breë tydelike venster oop te maak, en wanneer verouderde inskrywings verwyder word. Skryf daardie antwoorde langs die reël.
Kies die mislukkingsgedrag doelbewus. Om die ou adres te hou kan 'n sessie bewaar en 'n verouderde toelating laat; om die stel skoon te maak kan herstel verydel. Nie een moet 'n toevallige gevolg van 'n mislukte opsoek wees nie. Skryf die gekose gedrag in die runbook sodat die volgende operateur nie onder druk improviseer nie.
Hou selflaai-DNS ook smal. 'n Onvoorwaardelike publieke oplosser-uitsondering is 'n direkte DNS-pad vir alles wat dit pas, nie net vir die eindpunt se naam nie.
Bewys die eindpuntverandering, nie die eerste verbinding nie
Gebruik die kliënt se ondersteunde bestuurder as dit reeds oplossing en blokkering koördineer. Op 'n werfbestuurde PF-gasheer, hou die werf se eienaarskap en herstelplan eerder as om gasheernaam-tabel-sintaksis van 'n ander platform met ander lewensiklusgedrag te kopieer.
Met 'n goedgekeurde, onskadelike toets, vergelyk die adres wat die kliënt kies met die aktiewe toegelate stel voor en na 'n beheerde verandering. Dek 'n mislukte opsoek, die verwydering van 'n inskrywing wat nie meer geldig is nie, en, waar ondersteun, 'n ander adresfamilie. Die beoogde tonnel moet herstel terwyl onverwante direkte verkeer onder beleid bly. 'n Suksesvolle eerste verbinding bewys net dat die aanvanklike vertaling toevallig korrek was.