Si një klient OpenVPN pas NAT bëhet dalja e internetit

Tre host-e Linux, një dizajn: një hub OpenVPN i arritshëm publikisht, një laptop konsumatori dhe një makinë daljeje pas një ruteri shtëpiak të zakonshëm që nuk përçon asgjë nga brenda. Dalja telefonon vetë hub-in. Pastaj trafiku i internetit i konsumatorit hyn në tunel në laptop dhe del përmes lidhjes së vetë daljes. Gjithçka befasuese në këtë rregullim rrjedh nga një detaj: dalja e nisi lidhjen, prandaj rruga nga brenda ekziston tashmë dhe nuk nevojitet përçim porti për ta krijuar.

Ajo që vijon ndjek rrugën e paketës dhe jo rendin e konfigurimit, sepse konfigurimi ka kuptim vetëm kur e dini cili komponent zotëron cilën vendim. Çdo shtresë zotëron saktësisht një vendim, dhe gabimet grumbullohen aty ku dy shtresa merren si një.

Dy sesione transporti, një rrugë e brendshme

Secili host mban lidhjen e vet të jashtme me hub-in, dhe asnjëra prej këtyre lidhjeve nuk e di për tjetrën. Trafiku i konsumatorit drejt internetit është një rrjedhë e brendshme e veçantë që transportohet brenda tunelit të konsumatorit dhe pastaj riemetohet nga tuneli i daljes. Hub-i duhet të rrugëzojë pikërisht këtë rrjedhë, dhe dalja duhet ta përçojë atë.

outer: consumer --TLS--> hub
outer: exit     --TLS--> hub
inner: consumer --tun--> hub --internal--> exit --tun--> uplink

Meqenëse të dyja lidhjet e jashtme nisen nga ana e klientit, ruteri i daljes nuk sheh kurrë një SYN hyrës dhe nuk ka kurrë nevojë për një rregull NAT destinacioni. Duhet vetëm të mbajë gjallë transportin e vendosur, gjë që e bën tashmë për çdo lidhje të gjatë. Asgjë në internetin publik nuk duhet të arrijë fillimisht daljen, prandaj një adresë dinamike në atë lidhje nuk është problem. Ruteri duhet prapë të lejojë sesionin dalës, por ky është i njëjti leje që shfletuesi përdor tashmë.

Çfarë instalon në të vërtetë iroute brenda serverit

Hub-i është pajisja e vetme që vendos se cili partner zotëron cilën destinacion, dhe e merr atë vendim në tabelën e vet të rrugëzimit të hapësirës së përdoruesit, jo në atë të kernelit. Një zë client-config-dir për daljen me emrin exit-node mund të kërkojë atje prefiksin e parazgjedhur:

# /etc/openvpn/server/ccd/exit-node
iroute 0.0.0.0 0.0.0.0

Ai rresht i thotë procesit të serverit "paketat e brendshme me çdo destinacion i përkasin këtij klienti". Nuk shton një rrugë të parazgjedhur në sistemin operativ të hub-it dhe nuk e bën hub-in portë interneti. Referenca e OpenVPN 2.6 mban rrugëzimin e brendshëm specifik të klientit dhe rrugëzimin e kernelit si mekanizma të veçantë, dhe pikërisht ky ndarje është arsyeja pse dizajni funksionon pa prekur rrugën e parazgjedhur të hub-it.

Konsumatori ka nevojë për udhëzimin pasqyrë, të dorëzuar si push, që trafiku i tij të hyjë në tunel në vend që të dalë përmes portës lokale. Me topologjinë e nënrrjetit, grupi është një rrugë e lidhur në pajisjen tun të daljes, prandaj drejtimi i kthimit nuk ka nevojë për push shtesë; ajo që dalja nuk duhet të marrë është ridrejtimi më poshtë, i cili do ta kthente trafikun e vet të lidhjes në tunelin që po përpiqet të përdorë. Dërgojeni vetëm te konsumatori dhe lexoni rrugët e zbatuara në klient në vend që të besoni se skedari CCD u zgjodh.

# /etc/openvpn/server/ccd/consumer-01
push "redirect-gateway def1"

Përçimin e bën kernel-i i daljes

Brenda daljes, një paketë nga konsumatori arrin në ndërfaqen tun e adresuar drejt ndonjë host-i interneti. Kernel-i konsulton tabelën e rrugëzimit, gjen lidhjen e vërtetë si përputhjen më të mirë dhe pastaj zbaton dy politika të pavarura: a mund të përçohet fare kjo paketë, dhe a mund të dalë përmes asaj ndërfaqeje me atë adresë burimi. Përçimi është një sysctl, dhe në shumë shpërndarje është i fikur si parazgjedhje.

Prandaj dalja ka nevojë për përçim IPv4 të aktivizuar përgjithmonë, një rregull që pranon burimet e tunelit të konsumatorit drejt lidhjes dhe rrugën e përgjigjes përmes tun. Aktivizimi i përçimit për të gjithë host-in ndryshon edhe sjelljen e çdo gjëje tjetër që rrugëzohet përmes tij, prandaj rregulli duhet të emërojë burimet dhe ndërfaqet në vend që të pranojë gjithçka.

Rrugën e kthimit e blen përkthimi i burimit

Një host interneti nuk ka rrugë drejt një adrese 10.90.0.x, prandaj përgjigjet do të hidheshin poshtë para se të arrinin daljen. Rishkrimi i burimit ndërsa paketa largohet nga lidhja e zgjidh atë, dhe gjurmimi i lidhjeve e kthen mbrapsht rishkrimin në kthim.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.90.0.0/24 -o enp1s0 -j MASQUERADE
ip -4 route get 10.90.0.9   # run on the exit: must point at the tun

Rregulli më sipër është pikënisje për një ndërfaqe të vetme lidhjeje, jo politikë firewall. Ngushtoni burimin në caktimet që keni autorizuar vërtet, dhe mbajeni politikën e hyrjes të vetë daljes të veçantë, që maskimi për trafikun e tunelit të mos ekspozojë në heshtje shërbime lokale. Në një host me adresë lidhjeje dinamike, maskimi ju kursen edhe gjurmimin manual të adresës.

Ku hub-i mund të zbatojë dhe ku nuk mundet

Me client-to-client dhe rrugën tradicionale të të dhënave në hapësirën e përdoruesit, hub-i ua dorëzon paketat e brendshme partnerëve brenda procesit të serverit. Ato nuk kalojnë kurrë në zinxhirin FORWARD të kernelit të hub-it, prandaj një rregull kernel atje nuk mund të kufizojë kalimin mes partnerëve, sado me kujdes të jetë shkruar. Zbatimi duhet të jetë në politikën e vetë serverit: kush mund të lidhet, cilin skedar CCD merr dhe a jepet fare pronësia e parazgjedhur e daljes.

Prandaj një iroute i parazgjedhur është një vendim i gjerë besimi. Dalja duhet të pranojë ligjërisht trafik kthimi nga adresa arbitrare interneti, dhe duhet të jetë një makinë që ju kontrolloni, përditësoni dhe monitoroni. Të japësh të njëjtën pronësi një partneri të cilit nuk do t'i jepje një ruter është gabimi ku ky dizajn fton.

Anëtarësimi është kontrolli i vërtetë. Çdo klient që mund të konfigurojë rrugët e veta mund të provojë të përdorë daljen, prandaj kufizimi i kujt mund të lidhet, ose cilëve partnerë do t'u shërbejë dalja, është pjesë e dizajnit dhe jo mendim i mëvonshëm.

Të dështosh në mënyrë të sigurt kur dalja zhduket

Shkëputni daljen dhe pronësia e brendshme e parazgjedhur zhduket bashkë me sesionin e saj. Ajo që nuk duhet të ndodhë është që hub-i të bëhet në heshtje dalja zëvendësuese: asnjë rrugë e parazgjedhur nga grupi VPN drejt lidhjes së hub-it, dhe asnjë rregull i gjerë maskimi në hub që do ta përçonte me kënaqësi të njëjtin trafik. Testojeni atë dështim me qëllim, pastaj testojeni rikuperimin me një rrjedhë të re dhe jo me një faqe që ishte hapur tashmë.

# on the consumer, with the exit up and then down
ip -4 route get 1.1.1.1
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

Nëse trafiku i konsumatorit ende arrin internetin pasi dalja është larguar, diçka tjetër po e mbart dhe kufiri që synuat nuk ekziston. Trajtoni DNS dhe IPv6 gjithashtu si vendime të veçanta: rruga IPv4 plus maskimi nuk thonë asgjë për trafikun AAAA, dhe një zgjidhës i shtyrë nga hub-i do të përgjigjet nga aty ku kërkesa del vërtet.