Dy adresa shërbimi në një klient OpenVPN: iroute dhe lo

Aplikacioni përgjigjet në adresën e tunelit të tij, dhe adresa që dokumentuat për të nuk të çon askund. Asgjë në regjistrin e OpenVPN nuk ankohet, partneri shfaqet i lidhur, dhe hub-i liston saktësisht një klient. Hendeku është se një adresë e dytë në një klient janë dy fakte të ndara: host-i duhet ta zotërojë atë, dhe hub-i duhet të dijë cili partner e zotëron. Trajto njërën pa tjetrën dhe trafiku ose vdes në hub ose arrin pa rrugë për në shtëpi.

Alias-i është lokal, pronësia është e largët

Për adresën e tunelit negociohet, kështu që të dy skajet e mësojnë gjatë shtrëngimit të duarve. Për adresën shtesë të shërbimit nuk negociohet fare, prandaj shtimi i saj nuk ndryshon asgjë në hub në vetvete. Klienti mund ta zotërojë adresën menjëherë dhe serveri do ta dërgojë gjithsesi atë trafik në rrugën e tij të paracaktuar ose do ta hedhë poshtë. Duhet të krijohen dy regjistrime, në dy vende të ndryshme.

Në klient adresa i përket host-it, dhe loopback është shtëpia e natyrshme për një identitet shërbimi që nuk duhet të shfaqet kurrë në një lidhje fizike. Në hub, hartëzimi partner-prefiks është një deklaratë e veçantë që lexohet vetëm nga serveri. Asnjëri regjistrim nuk nënkupton tjetrin.

Mbani të dy intervalet të ndara edhe në shënimet tuaja. Adresat në një shembull janë vlera dokumentacioni, dhe mbivendosja e tyre me një LAN të vërtetë është mënyra më e shpejtë për ta bërë një konfigurim funksional të duket i prishur.

Shtoni adresën në klient në mënyrë të përhershme

Vendosni adresën e shërbimit në loopback me një prefiks host-i, që host-i ta trajtojë si hyrje lokale dhe jo si një nënrrjet për t’u arritur. ip address add 10.66.0.10/32 dev lo e bën këtë për një adresë, dhe përsëritja e komandës për një adresë të dytë modelon dy shërbime.

Ekzekutoni atë si një provë të njëhershme, pastaj zhvendoseni në atë që zotëron konfigurimin e rrjetit të host-it, sepse një shtesë në kohën e ekzekutimit zhduket në ristartim dhe dublikatat grumbullohen midis rilidhjeve. Një njësi systemd e renditur pas rrjetit është një opsion, dhe një menaxher rrjeti i shpërndarjes është një tjetër. Çfarëdo që të zgjidhni, adresa duhet të ekzistojë përpara se aplikacioni të lidhet, përndryshe shërbimi ngrihet në socketin e gabuar. Verifikoni me ip address show dev lo pas një ristartimi dhe jo pas komandës manuale.

Lidhja është një vendim i ndarë nga adresimi. Një aplikacion që dëgjon në çdo adresë pranon trafik në ndërfaqe që nuk i kishit menduar kurrë, ndaj drejtojeni atë në adresën specifike të shërbimit. Atëherë politika lokale e hyrjes ka diçka të saktë për t’u përputhur.

Kërkojeni në skedarin CCD që hub-i lexon vërtet

Në server, deklarata e pronësisë shkon në skedarin për çdo klient të zgjedhur nga emri i përbashkët i autentikuar, brenda drejtorisë së emërtuar nga client-config-dir. Rreshti është iroute 10.66.0.10 255.255.255.255, një për adresë, dhe i tregon serverit cili partner duhet të marrë trafikun për atë destinacion.

Dy detaje e prishin këtë në heshtje. Emri i skedarit duhet të përputhet me emrin që serveri përdor vërtet, i cili ndryshon kur username-as-common-name është në lojë. Dhe iroute vlen vetëm në modalitetin TUN me një drejtori konfigurimi klienti të konfiguruar, prandaj i njëjti rresht nuk bën asgjë në një vendosje me urë. Shtoni rreshta në skedarin ekzistues në vend që ta zëvendësoni, sepse ai mund të mbajë tashmë një adresë fikse ose opsione push. Referenca e OpenVPN 2.6 dokumenton si drejtorinë ashtu edhe direktivën e pronësisë.

Vetë kernel-i i hub-it ka gjithashtu nevojë për një rrugë drejt atyre destinacioneve, që trafiku i krijuar lokalisht të hyjë në procesin e tunelit. route 10.66.0.10 255.255.255.255 në konfigurimin e serverit mbulon trafikun që serveri krijon vetë, ndërsa klientët e tjerë kanë nevojë për push "route 10.66.0.10 255.255.255.255" për ta mësuar destinacionin vetë.

Rrugëtimi dhe autorizimi mbeten të ndara. Një rrugë e shtyrë i thotë një klienti ku të dërgojë paketat dhe nuk jep asgjë; shërbimi ende duhet ta pranojë thirrësin sipas kushteve të veta.

Kontrolloni politikën e hyrjes dhe rrugën e përgjigjes

Një paketë e adresuar te alias-i arrin në host-in pronar si hyrje lokale, prandaj pyetja është nëse muri i zjarrit lokal e lejon atë burim dhe portë. Lejoni portën specifike të shërbimit nga diapazoni i burimeve VPN në vend që të hapni të gjithë adresën.

Përgjigjet kanë nevojë për një rrugë kthimi te thirrësi. Për një thirrës brenda grupit normal të tunelit kjo rrugë ekziston tashmë, sepse pajisja e tunelit e mbart atë. Një thirrës pas një rrjeti tjetër të rrugëtuar ka nevojë edhe për rrugën e kthimit të atij rrjeti, dhe këtu konfigurimet asimetrike humbin paketa.

Kujdesuni për një dëgjues të dytë në të njëjtën portë të lidhur me një adresë tjetër, sepse kernel-i dorëzon te socket-i që përputhet dhe rezultatet duken të rastësishme. Kontrolloni me ss -lntp dhe konfirmoni që adresa e lidhur është alias-i i shërbimit. NAT i burimit nuk nevojitet këtu, dhe shtimi i tij fsheh identitetin e thirrësit nga i cili varen regjistrat tuaj.

Testoni adresat dhe pronësinë veçmas

Testoni në dy hapa. Së pari konfirmoni që host-i pronar mund ta arrijë shërbimin në alias-in e tij nga vetja, gjë që i ndan problemet e lidhjes dhe të murit të zjarrit nga rrugëtimi. Pastaj testoni nga një thirrës real VPN duke përdorur autentikimin e vetë aplikacionit. Kur i pari kalon dhe i dyti dështon, pjesa që mungon është në anën e hub-it.

Kontrolloni edhe mënyrat e dështimit që i mbijetojnë një lidhjeje: alias-i mbetet i caktuar kur tuneli është poshtë, dhe hub-i e mban rrugën e tij kur partneri mungon. Asnjë objekt i vetëm nuk provon që shërbimi është i arritshëm, prandaj testi me dy hapa mund një ping të vetëm nga një laptop.