Serveri dhe klienti OpenVPN në një host: pse klientët bien

Shtoni një profil klienti në një makinë ku tashmë punon një server VPN, dhe viktima e parë do të jetë shërbimi origjinal. Tuneli i ri mund të mos krijohet kurrë, ose mund të ngrihet ndërsa klientët ekzistues të serverit ndalojnë në heshtje së marri përgjigje. Dy përplasje japin të dyja rezultatet: një pishinë tunelesh që është tashmë në përdorim, dhe një rrugë e paracaktuar e instaluar nga gjysma e re e klientit që mbulon të gjithë tabelën. Asnjëra nuk prodhon një mesazh gabimi të OpenVPN, prandaj dështimi lexohet si problem i serverit.

Një makinë, dy role, dhe dy përgjigje të papajtueshme se ku duhet të shkojnë përgjigjet.

E njëjta pishinë, dy serverë: kush fiton

Çdo instancë serveri ka nevojë për nënrrjetin e vet të tunelit. Kopjimi i një rreshti si server 10.8.0.0 255.255.255.0 në konfigurimin e dytë u jep të dyja instancave të njëjtin parashtesë, dhe rezultati është ose refuzim për t'u nisur ose një garë e heshtur ku klientët e një serveri marrin adresa që tjetri gjithashtu i konsideron të vetat. Portat e ndryshme UDP dhe emrat e ndryshëm të pajisjeve nuk ndihmojnë, sepse asnjëri nuk prek hapësirën e adresave. Ndryshoni pishinën e dytë, dhe ndryshojeni kudo ku rrugët e përmendin atë.

Listoni çfarë është aktive përpara se të redaktoni: ip -4 addr show liston pajisjet e tunelit, ss -lunp liston dëgjuesit, dhe systemctl list-units emërton njësitë. Një vështrim te adresat e tunelit vendos nëse pishinat përplasen.

Çfarë i shton profili i klientit tabelës

Gjysma e klientit shkruan rrugët sapo lidhet. redirect-gateway def1 e ndan rrugën e paracaktuar në 0.0.0.0/1 plus 128.0.0.0/1, të dyja drejtohen përmes pajisjes së re, bashkë me një rrugë hosti drejt serverit të largët që është qëllimisht e fiksuar te ndërfaqja fizike. Ai fiksim ekziston që tuneli të mbajë një shteg për transportin e vet. Çdo gjë tjetër, duke përfshirë përgjigjet që serveri lokal u detyrohet klientëve të vet, tani ndjek parazgjedhjen e re dhe del përmes lidhjes së largët.

Pra përplasja e dytë nuk është tunel i thyer. Është një tunel që punon në vendin e gabuar të tabelës.

Tre mënyra për t'i mbajtur rolet të ndara

Rregullimi më pak invaziv e mban rrugën e paracaktuar jashtë profilit të klientit: route-nopull plus rreshta route të shprehur për parashtesat e largëta, kështu që tabela lokale ndryshon vetëm aty ku e kërkuat. Hapi tjetër është një rregull politike që përjashton nënrrjetin lokal të tunelit, duke i lënë përgjigjet për klientët lokalë të dalin në ndërfaqen ku mbërritën, edhe kur ekziston një rrugë e paracaktuar. Më e plota është një hapësirë e veçantë emrash rrjeti për rolin e klientit, e cila e heq plotësisht tabelën e përbashkët dhe kërkon një kontekst të dytë drejtimi për t'u mirëmbajtur.

Cilado rrugë që zgjidhni, përjashtimi duhet të emërtojë nënrrjetin lokal të tunelit dhe jo LAN-in. Përgjigja që dërgon serveri lokal e ka destinacion një adresë tuneli, prandaj një përjashtim në formë LAN-i nuk përputhet kurrë me të.

Cila nga të dyja instancat është fajtore

Ndaloni instancën e klientit dhe ritestoni klientët origjinalë. Rikuperimi i menjëhershëm do të thotë drejtim, jo server. Kthejeni klientin dhe ndiqni një përgjigje të vetme me ip route get të cilit i jepen si adresa burimore ashtu edhe ajo e destinacionit, gjë që tregon shtegun që do të zgjidhte kerneli, pastaj vëzhgoni ndërfaqen që paketat përdorin vërtet me tcpdump -ni any port 1194. Skedari i statusit të serverit, i shkruar çdo pak sekonda përmes direktivës status, përmban listën e klientëve të lidhur dhe numëruesit e bajtëve në të dy drejtimet.

Lexoni ata numërues njëri kundrejt tjetrit. Trafiku që del dhe nuk kthehet kurrë është përgjigje drejtimi, jo problem shtrëngimi duarsh.