Kush duhet të zotërojë rrugët dhe DNS-në kur openfortivpn lidhet?

Katër faza mbivendosen mbi njëra-tjetrën në një sesion openfortivpn që funksionon. Klienti autentikohet në portë dhe nis një lidhje TLS, pastaj ekzekuton PPP brenda asaj lidhjeje, pastaj merr një adresë dhe informacion DNS dhe më në fund zbaton rrugët e hostit dhe cilësimet e zgjidhësit. Çdo fazë mund të jetë e gjallë ndërsa tjetra nuk është, dhe për këtë arsye “i lidhur” është një fjalë kaq e rrëshqitshme në thread-et e mbështetjes.

Vendimi që heq pjesën më të madhe të konfuzionit është kush zotëron fazën e fundit. Ose klienti VPN i zbaton vetë ndryshimet në host, ose i bën një komponent tjetër, dhe përzierja e të dyve në gjysmë të rrugës është mënyra se si rrugët dhe skedarët e zgjidhësit përfundojnë duke përshkruar sesione të ndryshme.

Katër faza që duken si një lidhje e vetme

Faza e parë është pranimi. një domen autentikimi me emër ose një kod njëpërdorimësh, dhe merr parametrat e nevojshëm për të vazhduar. Kur klienti shtyp se është i lidhur me portën, kjo do të thotë që transporti TLS është aktiv. Nuk do të thotë që PPP ka negociuar, dhe sigurisht nuk do të thotë që një aplikacion i brendshëm është i arritshëm.

Faza e dytë është lidhja PPP. Klienti nis një proces PPP ndaj pajisjes së tunelit, dhe të dyja palët negociojnë opsionet e lidhjes dhe adresat. Vetëm pas kësaj hosti e di se cilat adresa lokale dhe të largëta përdor sesioni, dhe vetëm atëherë një rrugë drejt tunelit ka kuptim.

Faza e tretë është zbatimi i atij informacioni në host, dhe këtu ka rëndësi pronësia. Klienti mund të shtojë rrugët dhe të rishkruajë konfigurimin e zgjidhësit, ose mund t'i thuhet të tërhiqet dhe t'i lërë të dyja çdo gjëje tjetër që menaxhon rrjetin në atë makinë. README i projektit i përshkruan këto si përgjegjësi të ndara dhe jo si një sjellje automatike.

Kush e redakton tabelën e rrugëtimit

Si parazgjedhje klienti është pronari. Ai shton një rrugë drejt portës përmes ndërfaqes fizike, një rrugë për partnerin e tunelit dhe rrugë për rrjetet që sesioni lejohet të përdorë, pastaj i heq ato kur procesi del. Kjo parazgjedhje është e përshtatshme në një laptop me një menaxher rrjeti dhe pa softuer tjetër VPN.

Zgjidh dorëzimin vetëm kur diçka tjetër zotëron vërtet rrugëtimin. Një integrim i menaxherit të rrjetit, një hapësirë emrash rrjeti kontejneri ose një agjent rrugëtimi në nivel site mund të dinë tashmë si të instalojnë dhe pastrojnë të njëjtat parashtesa. Kalimi i opsionit no-routes atëherë parandalon dy shkrimtarë të zihen për të njëjtën tabelë, që është një garë që shfaqet si humbje e ndërprerë e një nënrrjeti dhe jo si dështim i pastër.

Mbivendosja është arsyeja e dytë për dorëzim. Nëse rrugët e shtyra përfshijnë një parashtesë që rrjeti lokal tashmë e përdor, klienti nuk mund ta zgjidhë konfliktin për ju. Dikush duhet të vendosë nëse ajo parashtesë është e arritshme përmes tunelit, lidhjes fizike apo një rrugë më specifike, dhe ai vendim i takon atij që zotëron topologjinë.

Pastrimi është i treti. Një klient që rrëzohet para se të heqë rrugët e tij lë një vrimë të zezë që i mbijeton sesionit, dhe lidhja tjetër mund të shtojë një dublikatë mbi të. Kush zotëron rrugëtimin zotëron edhe verifikimin se zënë të vjetra kanë ikur. Bëje atë kontroll pjesë të rrugës së nisjes, jo një hap opsional pastrimi.

Kush zotëron DNS-në dhe skedarin e zgjidhësit

DNS është i njëjti vendim me skaje më të mprehta. Klienti mund të pranojë serverët DNS që raporton porta ose partneri PPP dhe t'i shkruajë në konfigurimin e zgjidhësit të hostit. Në një makinë të thjeshtë kjo është pikërisht ajo që dëshironi, sepse emrat e brendshëm atëherë zgjidhen vetëm sa kohë tuneli është aktiv.

Në një host modern Linux zgjidhësi mund të menaxhohet nga një stub lokal, dhe rishkrimi i skedarit të zgjidhësit pas shpinës së atij stub prodhon një konfigurim që duket i saktë dhe sillet në mënyrë jokonsistente. Nëse hosti tashmë ekzekuton një menaxher zgjidhësi, lëre atë të zotërojë DNS-në dhe ushqeje me serverët e tunelit përmes ndërfaqes së tij të mbështetur. Opsioni no-dns i klientit është zgjedhja e saktë atje, jo një shmangie.

DNS i ndarë është një pyetje e veçantë nga kush e shkruan skedarin. Dërgimi i çdo kërkese përmes tunelit është i thjeshtë dhe i ngadaltë; dërgimi vetëm i zonave të brendshme përmes tij kërkon konfigurim për domen që shumica e klientëve të thjeshtë nuk e ofrojnë. Vendos çfarë sjelljeje i nevojitet hostit përpara se të aktivizosh ndryshimet e zgjidhësit të klientit. Një zgjedhje e gabuar këtu duket si ndërprerje e zgjidhjes së emrave edhe kur vetë tuneli është në rregull.

Privilegjet, gatishmëria dhe dorëzimi

Krijimi i pajisjes së tunelit dhe redaktimi i rrugëve të hostit ose gjendjes së zgjidhësit kërkon autoritet të lartë rrjeti. Gabimi i zakonshëm është të konkludohet se për këtë arsye gjithçka duhet të ekzekutohet si root, duke përfshirë shfletuesin ose aplikacionin që përdor tunelin. Mbaje pjesën e privilegjuar të vogël: klienti dhe skedari i tij i konfigurimit, në pronësi të një administratori, ndërsa aplikacionet e përdoruesit mbajnë llogarinë e tyre normale.

Gatishmëria duhet të përcaktohet për secilin konsumator. Një mbikëqyrës mund ta konsiderojë shërbimin të nisur kur procesi i klientit po ekzekutohet dhe pajisja e tunelit ekziston. Një punë kopjimi rezervë duhet ta konsiderojë VPN-në të përdorshme vetëm kur pika e saj e ruajtjes përgjigjet përmes tunelit. Këto janë kontrolle të ndryshme, dhe përdorimi i më të dobëtit për qëllimin më të fortë prodhon punë që nisin shumë herët dhe dështojnë herë pas here. Shkruaje përkufizimin e zgjedhur, sepse një mbikëqyrës dhe një punë që nuk bien dakord për gatishmërinë janë një biletë mbështetjeje që pret të ndodhë.

Testoje kontratën me katër vëzhgime: faza e portës përfundon, PPP cakton adresat, rruga e synuar është e pranishme dhe një kërkesë drejt një hosti të brendshëm ka sukses. Pastaj ndal klientin dhe konfirmo se secila prej këtyre është hequr ose rikthyer. Nëse hosti ende zgjidh emra të brendshëm ose ende mban një rrugë pasi tuneli mbyllet, dorëzimi i pronësisë është i paplotë.