Klienti OpenVPN arrin serverin por jo hostet e LAN-it: listë kontrolli

Klienti thotë i lidhur, adresa e tunelit përgjigjet ndaj ping, dhe asgjë në LAN-in e zyrës nuk përgjigjet. E shoh këtë pas pothuajse çdo përditësimi të klientit, dhe instinkti i parë është të hapësh firewall-in, që zakonisht është lëvizja e gabuar: tuneli është në rregull, dhe thyerja është në një nga tre kërcimet që paketa duhet të kalojë. Ecni rrugën në rendin që merr paketa, së pari rruga e klientit, pastaj përçimi në server, pastaj udhëtimi i kthimit, dhe do të gjeni pronarin e defektit brenda pak minutash.

Hapi i parë: vëzhgoni vendimin e rrugëtimit të klientit

Para se të prekni serverin, provoni që klienti e dërgon paketën në tunel. Pyetni kernelin cilin ndërfaqe do të përdorte për një host të caktuar të LAN-it, në vend që të lexoni gjithë tabelën:

ip route get 192.168.50.10

Nëse përgjigjja përmend përshtatësin tuaj fizik dhe portën e zyrës, asnjë ndryshim në anën e serverit nuk mund të ndihmojë. OpenVPN shpërndan rrugë vetëm kur serveri i shtyn ato, prandaj kërkoni push "route 192.168.50.0 255.255.255.0" në konfigurimin e serverit, dhe pastaj rilidhni klientin. Shumica e klientëve i zbatojnë rrugët e shtyra gjatë lidhjes, jo kur ringarkoni profilin.

Në Windows e njëjta pyetje ka një komandë tjetër. Find-NetRoute -RemoteIPAddress 192.168.50.10 printon ndërfaqen dhe kërcimin tjetër që do të zgjidhte stiva, dhe route print -4 tregon nëse prefiksi i shtyrë ekziston fare.

Hapi i dytë: konfirmoni që serveri do ta përçojë paketën

Nëse rruga e klientit është e saktë, paketa arrin serverin dhe serveri duhet të pranojë ta përçojë. Ndërprerësi i kernelit është porta e parë, dhe sysctl net.ipv4.ip_forward duhet të kthejë 1. Vendosja e tij me echo 1 > /proc/sys/net/ipv4/ip_forward funksionon deri në rindezjen tjetër, dhe pikërisht për këtë e njëjta ankesë kthehet javë më vonë.

Shkruajeni diku që i mbijeton një rindezje:

echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-openvpn-forward.conf
sysctl --system

Porta e dytë është tabela e filtrave. Një host me Docker të instaluar shpesh mban një politikë FORWARD me vlerë DROP, dhe tuneli e trashëgon atë vendim. iptables -L FORWARD -v -n tregon si politikën ashtu edhe numëruesit e paketave; nëse politika është DROP, përçimi kërkon një leje të shprehur për drejtimin nga tuneli në LAN dhe një tjetër për përgjigjen.

Hapi i tretë: ndiqni paketën në LAN dhe kërkoni përgjigjen

Vëzhgoni të dyja anët e serverit njëkohësisht. Kapni në tunel dhe në ndërfaqen LAN, të filtruar për një klient dhe një host që dalja të mbetet e lexueshme:

tcpdump -ni tun0 host 192.168.50.10
tcpdump -ni eth0 host 192.168.50.10

Kërkesat që shfaqen në tun0 dhe përsëri në eth0 me burim 10.8.0.x, të ndjekura nga heshtja, nënkuptojnë se paketa mbërriti dhe përgjigjja shkoi diku tjetër. Host-i i LAN-it përgjigjet portës së vet të paracaktuar, ajo portë nuk ka rrugë për grupin e VPN-së, dhe përgjigjja vdes në routerin e LAN-it. Pingimi i host-it të LAN-it nga serveri nuk provon asgjë për këtë rrugë, sepse ai trafik nuk e kalon kurrë tunelin.

Hapi i katërt: zgjidhni midis përkthimit dhe një rruge kthimi

Dy riparime e mbyllin vrimën, dhe zgjedhja ka pasoja përtej faktit nëse ping funksionon. Përkthimi i burimit e bën serverin dërguesin e dukshëm:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Kufizojeni rregullin te grupi dhe ndërfaqja LAN, pastaj bëjeni të përhershëm, përndryshe ringarkimi tjetër i firewall-it heq në heshtje rregullimin tuaj. Kostoja është identiteti: çdo klient duket si serveri VPN në regjistrat e LAN-it dhe në rregullat e aksesit, dhe per-client policy becomes guesswork.

Një rrugë statike për 10.8.0.0/24 në routerin e LAN-it, që tregon drejt serverit VPN, i mban adresat e klientëve të dukshme dhe është përgjigjja më e mirë afatgjatë kur ai router është i juaji. Shumë vende i mbajnë të dyja për një kohë, NAT për riparimin e menjëhershëm dhe rrugën sapo të shkruhet politika e firewall-it. Nëse serveri është një partner site-to-site dhe jo një grup, edhe ana e serverit ka nevojë për iroute për nënrrjetin e largët, përndryshe rruga e partnerit ekziston, por trafiku i klientëve nuk lidhet kurrë me të.

Hapi i pestë: verifikoni nga klienti dhe shënoni çfarë ndryshoi

Mbylle qarkun nga klienti, jo nga serveri. Lidhuni me një shërbim të vërtetë në host-in e LAN-it, pastaj konfirmoni që numëruesit e përkthimit lëvizën me iptables -t nat -L POSTROUTING -v -n, sepse një rregull me zero paketa është një rregull që nuk u përputh kurrë. conntrack -L -s 10.8.0.5 tregon rrjedhën dhe gjendjen e saj kur ju duhet provë që drejtimi i kthimit po ndiqet.

Lini një shënim në konfigurimin e serverit: cili nënrrjet, cila ndërfaqe, cili rregull, dhe a ka routeri i LAN-it një rrugë kthimi. Herën tjetër kur një përditësim i klientit fshin një rrugë të shtyrë, ai shënim e kthen një sesion shuarjeje zjarri në një rregullim prej një rreshti.