OpenVPN server at client sa isang host: bakit bumabagsak ang mga client

Magdagdag ng profile ng client sa isang makina na may tumatakbong VPN server, at ang orihinal na serbisyo ang unang biktima. Maaaring hindi kailanman mabuo ang bagong tunnel, o maaari itong bumangon habang tahimik na humihinto ang mga umiiral na client ng server sa pagtanggap ng sagot. Dalawang banggaan ang nagbubunga ng parehong resulta: isang pool ng tunnel na ginagamit na, at isang default na rutang ini-install ng bagong kalahati ng client at sumasakop sa buong talahanayan. Wala sa kanila ang gumagawa ng mensahe ng error ng OpenVPN, kaya't ang pagkabigo ay binabasa bilang problema ng server.

Isang makina, dalawang papel, at dalawang magkasalungat na sagot kung saan dapat pumunta ang mga sagot.

Parehong pool, dalawang server: sino ang mananalo

Ang bawat instance ng server ay nangangailangan ng sariling subnet ng tunnel. Ang pagkopya ng linyang gaya ng server 10.8.0.0 255.255.255.0 sa pangalawang configuration ay nagbibigay sa dalawang instance ng parehong prefix, at ang resulta ay alinman sa pagtanggi na magsimula o isang tahimik na labanan kung saan ang mga client ng isang server ay tumatanggap ng mga address na itinuturing din ng isa pang pag-aari nito. Hindi nakakatulong ang magkaibang UDP port at magkaibang pangalan ng device, dahil wala sa kanila ang humahawak sa espasyo ng address. Palitan ang pangalawang pool, at palitan ito sa lahat ng lugar kung saan ito binabanggit ng mga ruta.

Ilista kung ano ang aktibo bago mag-edit: inililista ng ip -4 addr show ang mga device ng tunnel, inililista ng ss -lunp ang mga nakikinig, at pinapangalanan ng systemctl list-units ang mga unit. Isang sulyap sa mga address ng tunnel ang magpapasya kung nagbabanggaan ang mga pool.

Ano ang idinadagdag ng profile ng client sa talahanayan

Ang kalahati ng client ay nagsusulat ng mga ruta sa sandaling kumonekta. Hinahati ng redirect-gateway def1 ang default na ruta sa 0.0.0.0/1 at 128.0.0.0/1, parehong dinadaanan ng bagong device, kasama ang isang host route patungo sa malayong server na sadyang naka-pin sa pisikal na interface. Umiiral ang pin na iyon upang mapanatili ng tunnel ang landas para sa sarili nitong transportasyon. Lahat ng iba pa, kasama ang mga sagot na utang ng lokal na server sa sarili nitong mga client, ay sumusunod na ngayon sa bagong default at lumalabas sa malayong link.

Kaya ang pangalawang banggaan ay hindi sirang tunnel. Ito ay gumaganang tunnel sa maling lugar sa talahanayan.

Tatlong paraan upang paghiwalayin ang mga papel

Ang pinakamaliit na interbensyong pagwawasto ay naglalayo sa default na ruta mula sa profile ng client: route-nopull at malinaw na mga linyang route para sa malalayong prefix, upang ang lokal na talahanayan ay magbago lamang kung saan mo hiniling. Ang susunod na hakbang ay isang tuntunin ng patakaran na nagbubukod sa lokal na subnet ng tunnel, na nagpapahintulot sa mga sagot sa mga lokal na client na lumabas sa interface kung saan sila dumating kahit may default na ruta. Ang pinakamalubusan ay isang hiwalay na namespace ng network para sa papel ng client, na ganap na nag-aalis ng pinagsasaluhang talahanayan at nangangailangan ng pagpapanatili ng pangalawang konteksto ng routing.

Anuman ang landas na piliin mo, dapat pangalanan ng eksepsiyon ang lokal na subnet ng tunnel at hindi ang LAN. Ang sagot na ipinapadala ng lokal na server ay may address ng tunnel bilang destinasyon, kaya ang eksepsiyong hugis LAN ay hindi kailanman tumutugma dito.

Alin sa dalawang instance ang may kasalanan

Ihinto ang instance ng client at subukan muli ang mga orihinal na client. Ang agarang pagbangon ay nangangahulugang routing, hindi server. Ibalik ang client at subaybayan ang isang sagot gamit ang ip route get na binibigyan ng address ng pinagmulan at destinasyon, na nagpapakita ng landas na pipiliin ng kernel, pagkatapos ay panoorin ang interface na aktuwal na ginagamit ng mga packet gamit ang tcpdump -ni any port 1194. Ang file ng status ng server, na isinusulat tuwing ilang segundo sa pamamagitan ng direktibang status, ay naglalaman ng listahan ng mga konektadong client at mga counter ng byte sa parehong direksyon.

Basahin ang mga counter na iyon laban sa isa't isa. Ang trapikong lumalabas at hindi na bumabalik ay sagot sa routing, hindi problema sa handshake.