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

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

Dva dizajna, dvije granice

Nijedan dizajn ne proširuje broadcast domenu LAN-a. Uređaji na daljoj strani ne pojavljuju se na lokalnom popisu za otkrivanje, a očekivanje da hoće prva je pretpostavka koje se treba odreći. Privatna DNS imena koja namjerno objavljujete predvidljivija 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 prometa koji šalje prefiks 10.20.0.0/24 u tunel, a pristupniku B treba njezina zrcalna slika. Hostovi s obje strane zatim koriste običnu IP povezanost i nikada ne saznaju da tunel postoji. Ta nevidljivost je značajka, i zato kvarovi izgledaju kao obične mrežne pogreške, a ne kao pogreške tunela.

Politika i ruta nisu isti tunel

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

StrongSwan izravno prikazuje oba pogleda, a njihovo zajedničko čitanje način je da utvrdite koji ste model doista implementirali.

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

Popis selektora kojem nedostaje prefiks koji vam je važan objašnjava kvar bez ikakvog hvatanja paketa, a ruta koja pokazuje na pogrešno sučelje objašnjava zrcalni kvar na povratnom putu. Pročitajte oboje prije nego što bilo što ponovno pregovarate, jer obnavljanje ključa neće dodati selektor koji nikada niste konfigurirali.

Isplanirajte adresiranje prije tunela

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

Odaberite jednu od tri iskrene mogućnosti: prenumerirajte jednu lokaciju, prevedite preklapajući raspon na pristupniku tako da svaka strana vidi različit prefiks, ili odustanite od izravnog usmjeravanja 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 dira svaki uređaj sa starom adresom.

Riješite i pitanje MTU-a rano. Tunel smanjuje korisni teret, a dizajn koji se oslanja na fragmentaciju ponaša se drukčije od onoga koji fiksira MSS na pristupnicima.

Prosljeđivanje i politika stoje izvan tunela

Pristupnik mora biti spreman prosljeđivati pakete između sučelja tunela i LAN sučelja, a oba smjera trebaju politiku koja dopušta uslugu. Na Linuxu su to dvije odvojene postavke, plus pravila vatrozida koja odlučuju je li proslijeđeni tok uopće dopušten.

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

Prihvatni host dodaje treći sloj: njegov vlastiti vatrozid još uvijek mora prihvatiti klijenta iz udaljene podmreže. Poslužitelj datoteka koji dopušta samo svoju lokalnu /24 odbit će proslijeđeni promet s 10.20.0.7, koliko god tunel izgledao zdrav, a to je odbijanje lako pročitati kao kvar usmjeravanja.

Testirajte s hosta, ne s pristupnika

Ping koji šalje sam pristupnik može slijediti drugu izvornu adresu i drugu politiku od proslijeđenog korisničkog prometa. To ga čini slabim testom, a povremeno i obmanjujućim: uspijeva dok aplikacija ne radi, ili ne uspijeva 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 konfigurirate, slijedi iz tog odgovora.