VPN medzi lokalitami alebo vzdialený prístup: čo každé spája

Obe riešenia sa nazývajú VPN a riešia odlišné problémy. Tunel medzi lokalitami spája dve brány, takže každý hostiteľ za nimi môže dosiahnuť povolené adresy na druhej strane bez toho, aby čokoľvek inštaloval. Tunel vzdialeného prístupu pripája jednotlivé zariadenia k sieti, vždy jeden klient. Porovnanie je dôležité, pretože väčšina chýb pri nasadení vzniká tým, že sa nakonfiguruje jedno riešenie a očakáva sa správanie druhého, a príznakom býva zvyčajne vypršanie času pri službe, ktorú tunel skutočne dosiahol.

Dve riešenia, dve hranice

Ani jedno riešenie nerozširuje broadcastovú doménu LAN. Zariadenia na vzdialenej strane sa neobjavujú v miestnom zozname objavovania a očakávať to je prvý predpoklad, ktorého sa treba vzdať. Privátne názvy DNS, ktoré zámerne zverejňujete, sú predvídateľnejšie než akýkoľvek protokol objavovania a prežijú zmenu dodávateľa.

Vezmite 10.10.0.0/24 na jednej lokalite a 10.20.0.0/24 na druhej. Brána A potrebuje trasu alebo selektor prevádzky, ktorý posiela prefix 10.20.0.0/24 do tunela, a brána B potrebuje jeho zrkadlový obraz. Hostitelia na oboch stranách potom používajú bežné IP spojenie a nikdy sa nedozvedia, že tunel existuje. Táto neviditeľnosť je funkcia a práve preto poruchy vyzerajú ako bežné sieťové chyby, nie ako chyby tunela.

Na základe politiky a na základe trasy nie sú ten istý tunel

Pri nasadení IPsec založenom na politike vyjednané selektory prevádzky presne určujú, ktoré páry zdroja a cieľa sú chránené. Ak sa za jednou bránou objaví nová podsieť a žiadny selektor ju nepokrýva, tunel zostane aktívny a nová podsieť sa jednoducho neprenáša. V riešení založenom na trase preberá prevádzku rozhranie a rozhoduje smerovacia tabuľka, čo robí pridanie prefixu zmenou smerovania, nie opätovným vyjednaním tunela.

StrongSwan zobrazuje oba pohľady priamo a ich spoločné čítanie je spôsob, ako zistiť, ktorý model ste vlastne nasadili.

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

Zoznam selektorov, v ktorom chýba prefix, na ktorom vám záleží, vysvetľuje poruchu bez akéhokoľvek zachytávania paketov, a trasa smerujúca na nesprávne rozhranie vysvetľuje zrkadlovú poruchu na spiatočnej ceste. Prečítajte si oboje, skôr než čokoľvek opäť vyjednáte, pretože obnovenie kľúča nepridá selektor, ktorý ste nikdy nenakonfigurovali.

Naplánujte adresovanie ešte pred tunelom

Prekrývajúce sa rozsahy sú chybou návrhu, ktorú konfigurácia neopraví. Ak obe lokality používajú 192.168.1.0/24, hostiteľ, ktorý potrebuje 192.168.1.50, má dvoch kandidátov a žiadny spôsob výberu. Tunel sa overí, bezpečnostné asociácie sa nadviažu a rozhodnutie o smerovaní bude aj tak nesprávne alebo nejednoznačné.

Vyberte jednu z troch poctivých možností: prečíslujte jednu lokalitu, preložte prekrývajúci sa rozsah na bráne, aby každá strana videla iný prefix, alebo sa vzdajte priameho smerovania pre týchto hostiteľov a publikujte službu inak. Každá má cenu a prvá je zvyčajne najlacnejšia v dvojročnom horizonte. Rozhodnite sa pred vznikom tunela, pretože dodatočná zmena sa dotkne každého zariadenia so starou adresou.

Otázku MTU vyriešte tiež skoro. Tunel znižuje použiteľnú záťaž a návrh spoliehajúci sa na fragmentáciu sa správa inak ako ten, ktorý na bránach určuje MSS.

Preposielanie a politika stoja mimo tunela

Brána musí byť ochotná preposielať pakety medzi rozhraním tunela a rozhraním LAN a oba smery potrebujú politiku, ktorá službu povoľuje. V Linuxe sú to dve samostatné nastavenia, plus pravidlá firewallu, ktoré rozhodujú, či je preposielaný tok vôbec povolený.

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

Prijímajúci hostiteľ pridáva tretiu vrstvu: jeho vlastný firewall musí stále prijať klienta zo vzdialenej podsiete. Súborový server, ktorý povoľuje len svoju miestnu /24, odmietne preposielanú prevádzku z 10.20.0.7, nech tunel vyzerá akokoľvek zdravo, a toto odmietnutie sa ľahko prečíta ako porucha smerovania.

Testujte z hostiteľa, nie z brány

Ping odoslaný samotnou bránou môže sledovať inú zdrojovú adresu a inú politiku než preposielaná používateľská prevádzka. To z neho robí slabý test a občas zavádzajúci: uspeje, keď aplikácia zlyháva, alebo zlyhá, keď aplikácia funguje.

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

Použite skutočného hostiteľa, skutočnú zdrojovú adresu a skutočný protokol, ktorý aplikácia používa. Potom si prečítajte spiatočnú cestu oddelene, pretože funkčný dopredný smer bez spiatočnej trasy dáva vypršanie času, ktoré vyzerá rovnako ako blokovaná služba.

Vyberte riešenie podľa otázky, na ktorú odpovedáte: spájate siete alebo prijímate zariadenia? Všetko ostatné, vrátane toho, ktorého dodávateľa konfigurujete, vyplýva z tejto odpovede.