Loka-al-loka kontraŭ fora aliro per VPN: kion la du kunligas

Ambaŭ dezajnoj nomiĝas VPN kaj solvas malsamajn problemojn. Loka-al-loka tunelo kunligas du pordegojn, do ĉiu gastiganto malantaŭ ili povas atingi permesitajn adresojn ĉe la alia flanko sen instali ion ajn. Fora-aliro tunelo kunligas unuopajn aparatojn al reto, unu klienton samtempe. La komparo gravas ĉar plej multaj deplojaj eraroj ekestas per konfigurado de unu dum oni atendas la konduton de la alia, kaj la simptomo kutime estas tempolimo ĉe servo, kiun la tunelo vere atingis.

Du dezajnoj, du limoj

Neniu el la dezajnoj etendas LAN-dissendan domajnon. Aparatoj ĉe la fora flanko ne aperas en loka malkovra listo, kaj atendi tion estas la unua supozo forĵetenda. Privataj DNS-nomoj, kiujn vi intence publikigas, estas pli antaŭvideblaj ol iu ajn malkovra protokolo kaj postvivas ŝanĝon de provizanto.

Prenu 10.10.0.0/24 ĉe unu loko kaj 10.20.0.0/24 ĉe la alia. Pordego A bezonas itinero aŭ trafikan selektilon, kiu sendas la prefikson 10.20.0.0/24 en la tunelon, kaj pordego B bezonas la spegulan bildon. Gastigantoj ambaŭflanke poste uzas ordinarajn IP-konektojn kaj neniam ekscias, ke tunelo ekzistas. Tiu nevidebleco estas la trajto, kaj ĝi ankaŭ estas kial paneoj aspektas kiel ordinaraj retaj eraroj anstataŭ tunelaj eraroj.

Politik-bazita kaj itinero-bazita ne estas la sama tunelo

En politik-bazita IPsec-deplojo, la interkonsentitaj trafikaj selektiloj difinas precize, kiuj paroj de fonto kaj celo estas protektitaj. Se nova subreto aperas malantaŭ unu pordego kaj neniu selektilo kovras ĝin, la tunelo restas funkcianta kaj la nova subreto simple ne estas portata. En itinero-bazita dezajno, interfaco ricevas la trafikon kaj la itinera tabelo decidas, kio igas aldonon de prefikso itinera ŝanĝo anstataŭ denova intertraktado de la tunelo.

StrongSwan montras ambaŭ vidpunktojn rekte, kaj legi ilin kune estas la maniero konstati, kiun modelon vi fakte deplojis.

swanctl --list-sas
ip xfrm policy
ip -4 route show table all | grep -E '10\.(10|20)\.'

Selektila listo, kiu preterlasas la prefikson, kiu gravas al vi, klarigas la paneon sen iu ajn paketa kaptado, kaj itinero montranta al la malĝusta interfaco klarigas la spegulan paneon sur la revena vojo. Legu ambaŭ antaŭ ol denove intertrakti ion ajn, ĉar ŝlosila renovigo ne aldonos selektilon, kiun vi neniam konfiguris.

Planu la adresadon antaŭ la tunelo

Surlokaj gamoj estas la dezajna eraro, kiun oni ne povas ripari per konfiguro. Se ambaŭ lokoj uzas 192.168.1.0/24, gastiganto, kiu bezonas 192.168.1.50, havas du kandidatojn kaj neniun manieron elekti. La tunelo aŭtentikiĝos, la sekurecaj asocioj establiĝos, kaj la itinera decido tamen estos malĝusta aŭ ambigua.

Elektu unu el tri honestaj opcioj: renumeri unu lokon, traduki la surlokajn gamojn ĉe la pordego por ke ĉiu flanko vidu apartan prefikson, aŭ rezigni pri rekta itinero por tiuj gastigantoj kaj publikigi la servon alimaniere. Ĉiu havas koston, kaj la unua kutime estas la plej malmultekosta dum dujara horizonto. Decidu antaŭ ol la tunelo ekzistas, ĉar poste la ŝanĝo tuŝas ĉiun aparaton kun la malnova adreso.

Solvu ankaŭ la demandon pri MTU frue. Tunelo malpliigas la uzeblan utilan ŝarĝon, kaj dezajno, kiu dependas de fragmentado, kondutas alie ol tiu, kiu fiksas la MSS ĉe la pordegoj.

Plusendado kaj politiko staras ekster la tunelo

La pordego devas esti preta plusendi pakaĵojn inter la tunela interfaco kaj la LAN-interfaco, kaj ambaŭ direktoj bezonas politikon, kiu permesas la servon. En Linux tio estas du apartaj agordoj, plus la fajromuraj reguloj, kiuj decidas, ĉu la plusendita fluo entute estas permesita.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -s 10.20.0.0/24 -d 10.10.0.0/24 -j ACCEPT
iptables -A FORWARD -s 10.10.0.0/24 -d 10.20.0.0/24 -j ACCEPT

La ricevanta gastiganto aldonas trian tavolon: ĝia propra fajromuro ankoraŭ devas akcepti klienton el la fora subreto. Dosieroservilo, kiu permesas nur sian lokan /24, rifuzos plusenditan trafikon de 10.20.0.7, kiom ajn sana la tunelo aspektos, kaj tiu rifuzo facile legeblas kiel itinera paneo.

Testu el gastiganto, ne el la pordego

Ping sendita de la pordego mem povas sekvi alian fontan adreson kaj alian politikon ol plusendita uzula trafiko. Tio igas ĝin malforta testo kaj foje misgvida: ĝi sukcesas dum la aplikaĵo paneas, aŭ paneas dum la aplikaĵo funkcias.

ip route get 10.10.0.5 from 10.20.0.7
ping -I 10.20.0.7 10.10.0.5
curl -sv --max-time 5 http://files.10-10.internal/ -o /dev/null

Uzu realan gastiganton, realan fontan adreson kaj la realan protokolon, kiun la aplikaĵo uzas. Poste legu la respondon aparte, ĉar funkcianta antaŭa direkto sen revena itinero produktas tempolimon, kiu aspektas idente al blokita servo.

Elektu la dezajnon laŭ la demando, kiun vi respondas: ĉu vi kunligas retojn aŭ akceptas aparatojn? Ĉio alia, inkluzive kiun provizanton vi konfiguras, sekvas el tiu respondo.