Kush e zotëron adresën, rrugën, DNS-në dhe firewall-in në një VPN Linux?

Dy skripte që luftojnë për të njëjtën rrugë është forma e zakonshme e një problemi të VPN Linux që regjistrohet si gabim rrugëtimi. Një komponent krijon pajisjen e tunelit, një tjetër shton një rrugë të parazgjedhur, i treti rishkruan konfigurimin e zgjidhësit, dhe i katërti ringarkon rregullat e firewall-it. Secili prej tyre mund të anulojë punën e tjetrit, dhe fituesi është thjesht ai që u ekzekutua i fundit. Pyetja që ia vlen të përgjigjesh nuk është cili paketë të instalosh, por cili komponent është autoritar për çdo pjesë të gjendjes.

Shkruani këtë hartë një herë, dhe shumica e dështimeve të rilidhjes pushojnë së qeni misterioze. Katër objekte kanë rëndësi: pajisja dhe adresat e saj, rrugët dhe rregullat e politikës, konfigurimi DNS dhe firewall-i.

Pajisja dhe adresat e saj

Një pajisje tuneli krijohet ose nga një menaxher që e njeh profilin, ose nga një demon që dikush e nisi me dorë. Të dyja skemat funksionojnë vetë; përzierja e tyre jo. Nëse NetworkManager e zotëron profilin, lëreni të zotërojë edhe pajisjen, dhe mos nisni një OpenVPN të pamenaxuar kundër të njëjtit emër tuneli.

Shënoni kush e heq pajisjen kur sesioni përfundon. Një pajisje që i mbijeton sesionit të saj është burimi më i zakonshëm i adresave të vjetruara dhe i konfuzionit që vjen pas.

Rrugët dhe rregullat e politikës

Është pikërisht në rrugë që konfliktet e pronësisë shkaktojnë dëm të dukshëm. Një menaxher lidhjeje instalon një rrugë të parazgjedhur për tunelin plus një rrugë më specifike për rrjetin e largët; pastaj një skript i shkruar me dorë shton rrugën e vet të parazgjedhur me një metrikë tjetër dhe fiton ose humbet në heshtje sipas kohës. Vendosni cilat zëra janë të lidhur me lidhjen, cilat janë politikë e përhershme dhe cili komponent i rifreskon ato pas një rilidhjeje. Pastaj mbajini komponentët e tjerë jashtë asaj tabele.

Rregullat e politikës meritojnë të njëjtën qartësi, sepse një rregull që tregon një tabelë që askush nuk e plotëson prodhon një vrimë të zezë që duket saktësisht si një tunel i vdekur. Nëse ekziston një rregull për të detyruar trafikun diku, tabela që ai zgjedh duhet të mirëmbahet nga i njëjti pronar.

DNS është gjithmonë një pronar i veçantë

Një demon zgjidhës ekzekutohet si procesi i vet nën identitetin e vet, kështu që nuk i trashëgon rastësisht vendimet e rrugëtimit të tunelit. Kur VPN shtyn serverë DNS, diçka duhet ta përkthejë atë në një konfigurim për çdo lidhje që zgjidhësi respekton, dhe diçka duhet ta heqë atë më pas.

Miti këtu është se shkrimi i një serveri emrash në profil ndryshon ku shkojnë pyetësorët. Ai ndryshon çfarë i thuhet zgjidhësit, jo cilën socket zgjidhësi përdor në rrjedhën lart. Testoni me një pyetësor plus një kërkim rruge në vend që t'i besoni skedarit.

Gjendja e firewall-it, dhe kush e rikthen atë

Rregullat e firewall-it janë objekti më shpesh i mbishkruar në një host VPN. Menaxheri mund të shtojë rregulla NAT ose përcjelljeje për çdo lidhje, ndërsa një shërbim firewall në nisje ringarkon një grup rregullash të ruajtur dhe i fshin ato. Zgjidhni një autoritet të vetëm për politikën dhe bëjeni tjetrin konsumator të saj, ose pranoni që një rinisje ndryshon sjelljen në heshtje. Përjashtimet e lidhura me lidhjen i përkasin një skedari që e ngarkon i njëjti pronar, jo një komande iptables të shtypur gjatë zgjidhjes së problemeve.

Nëse rregullat duhet t'i mbijetojnë një rilidhjeje, thojeni shprehimisht. Nëse nuk duhet, thojeni edhe atë, sepse inxhinieri tjetër do të supozojë përgjigjen më të përshtatshme.

Cikli i jetës: nisje, rilidhje, çmontim

Jepini një pronar secilit prej atyre tre momenteve. Në nisje, vendosni çfarë përgatit parakushtet dhe në çfarë radhe. Në një rinisje të butë, mbani mend se pajisja mund t'i mbijetojë ndërsa gjendja e sesionit jo, prandaj duhet të ekzekutohet një validues, jo një krijues. Në çmontim, hiqni vetëm atë që krijoi kjo lidhje, sepse rivendosja e çdo rruge ose zbrazja e të gjithë firewall-it nuk është e njëjta gjë me tërheqjen e një tuneli nga shërbimi.

Për vëzhgim, ip monitor link address route shfaq ndryshimet e kernelit ndërsa ndodhin, por raporton ngjarje dhe jo qëllim: një rrugë e fshirë nuk thotë asgjë për cili proces e fshiu. Bashkojeni me hartën e pronësisë, dhe një mbyllje konfuze bëhet një listë e shkurtër kandidatësh.

Përjashtimet kanë gjithashtu një kosto. Shënimi i një klase të tërë pajisjesh si e pamenaxuar për t'i shpëtuar një konflikti ia dorëzon atë gjendje askujt, që është një vendim dhe jo një korrigjim.