Veza između lokacija nasuprot udaljenom pristupu preko VPN-a: šta svaki od njih povezuje

Oba dizajna se nazivaju VPN i rješavaju različite probleme. Tunel između lokacija povezuje dva pristupnika, pa svaki host iza njih može dosegnuti dozvoljene adrese na drugoj strani bez instaliranja bilo čega. Tunel za udaljeni pristup povezuje pojedinačne uređaje sa mrežom, jedan klijent u jednom trenutku. Poređenje je važno jer većina grešaka pri primjeni nastaje kada se jedan dizajn konfiguriše očekujući ponašanje drugog, a simptom je obično istek vremena na usluzi do koje je tunel zaista stigao.

Dva dizajna, dvije granice

Ni jedan dizajn ne proširuje broadcast domenu LAN-a. Uređaji na daljoj strani se ne pojavljuju na lokalnoj listi za otkrivanje, a očekivanje da će se pojaviti prva je pretpostavka koje se treba odreći. Privatna DNS imena koja namjerno objavljujete predvidivija su od bilo kojeg protokola za otkrivanje i preživljavaju promjenu dobavljača.

Uzmite 10.10.0.0/24 na jednoj lokaciji i 10.20.0.0/24 na drugoj. Pristupniku A treba ruta ili selektor saobraćaja koji šalje prefiks 10.20.0.0/24 u tunel, a pristupniku B treba njen zrcalni odraz. Hostovi sa obje strane zatim koriste običnu IP povezanost i nikada ne saznaju da tunel postoji. Ta nevidljivost je funkcija, i zato kvarovi izgledaju kao obične mrežne greške, a ne kao greške tunela.

Politika i ruta nisu isti tunel

U IPsec primjeni zasnovanoj na politici, pregovarani selektori saobraćaja tačno određuju koji parovi izvora i odredišta su zaštićeni. Ako se iza jednog pristupnika pojavi nova podmreža i nijedan selektor je ne pokriva, tunel ostaje aktivan, a nova podmreža se jednostavno ne prenosi. U dizajnu zasnovanom na rutama, interfejs prima saobraćaj, a odluku donosi tabela rutiranja, što dodavanje prefiksa čini promjenom rute, a ne ponovnim pregovaranjem tunela.

StrongSwan direktno prikazuje oba pogleda, a njihovo zajedničko čitanje je način da utvrdite koji ste model zaista primijenili.

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

Lista selektora kojoj nedostaje prefiks koji vam je važan objašnjava kvar bez ikakvog hvatanja paketa, a ruta koja pokazuje na pogrešan interfejs objašnjava zrcalni kvar na povratnom putu. Pročitajte oboje prije nego što bilo šta ponovo pregovarate, jer obnavljanje ključa neće dodati selektor koji nikada niste konfigurisali.

Isplanirajte adresiranje prije tunela

Preklapajući opsezi su greška u dizajnu koja se ne može ispraviti konfiguracijom. Ako obje lokacije koriste 192.168.1.0/24, host kome treba 192.168.1.50 ima dva kandidata i nikakav način da izabere. Tunel će se autentifikovati, sigurnosne asocijacije će se uspostaviti, a odluka o rutiranju će ipak biti pogrešna ili dvosmislena.

Odaberite jednu od tri iskrene opcije: prenumerišite jednu lokaciju, prevedite preklapajući opseg na pristupniku tako da svaka strana vidi poseban prefiks, ili odustanite od direktnog rutiranja za te hostove i objavite uslugu na drugi način. Svaka ima cijenu, a prva je obično najjeftinija na dvogodišnjem horizontu. Odlučite prije nego što tunel postoji, jer naknadna promjena dotiče svaki uređaj sa starom adresom.

I pitanje MTU riješite rano. Tunel smanjuje korisni teret, a dizajn koji se oslanja na fragmentaciju ponaša se drugačije od onog koji fiksira MSS na pristupnicima.

Prosljeđivanje i politika stoje izvan tunela

Pristupnik mora biti spreman prosljeđivati pakete između interfejsa tunela i LAN interfejsa, a oba smjera trebaju politiku koja dozvoljava uslugu. Na Linuxu su to dvije odvojene postavke, plus pravila vatrozida koja odlučuju da li je proslijeđeni tok uopšte dozvoljen.

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

Prijemni host dodaje treći sloj: njegov vlastiti vatrozid još uvijek mora prihvatiti klijenta sa udaljene podmreže. Server datoteka koji dozvoljava samo svoju lokalnu /24 odbit će proslijeđeni saobraćaj sa 10.20.0.7, koliko god tunel izgledao zdrav, a to odbijanje lako se pogrešno pročita kao kvar rutiranja.

Testirajte sa hosta, ne sa pristupnika

Ping koji šalje sam pristupnik može slijediti drugu izvornu adresu i drugu politiku od proslijeđenog korisničkog saobraćaja. To ga čini slabim testom, a povremeno i obmanjujućim: uspije dok aplikacija ne radi, ili ne uspije dok aplikacija radi.

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

Koristite stvarni host, stvarnu izvornu adresu i stvarni protokol koji aplikacija koristi. Zatim odvojeno pročitajte povratni put, jer radni smjer naprijed bez povratne rute daje istek vremena koji izgleda jednako kao blokirana usluga.

Odaberite dizajn prema pitanju na koje odgovarate: povezujete li mreže ili primate uređaje? Sve ostalo, uključujući to kojeg dobavljača konfigurišete, slijedi iz tog odgovora.