Ako naplánovať fond adries VPN klientov, ktorý sadne
Vyberte fond v poli servera, potom prečítajte adresu, ktorú klient skutočne dostane, sledujte odpoveď späť a zaznamenajte rozsah, režim, trasu a rozsah DNS.
Začnite v poli fondu na serveri VPN, nie v tabuľke. Čo tam zadáte, sa stane vnútorným adresným priestorom pre každého klienta, ktorý sa pripojí neskôr, a musí koexistovať s LAN, na ktorú títo klienti dosahujú, s routovanými lokalitami za ňou a s akoukoľvek adresou, ktorú klient už má doma. Pripojte jedného klienta hneď po uložení fondu, pretože to prvé pripojenie vám povie, či hodnota v praxi funguje. Odtiaľ sa prechádzka vydáva von: adresa, ktorú klient dostal, cesta, ktorou sa odpoveď uberá, a záznam, ktorý po sebe zanecháte.
Začnite v poli fondu, skôr než sa pripojí akýkoľvek klient
Každý produkt to vystavuje inak, takže nájdite objekt, ktorý adresy skutočne prideľuje. OpenVPN má serverovú direktívu fondu, ktorá vydáva ďalšiu voľnú adresu, brána IKEv2 má sekciu fondu viazanú na konfiguráciu partnera a WireGuard nemá ani jedno, pretože každý partner nesie svoju vlastnú adresu vo svojom konfiguračnom súbore. Direktíva fondu a adresa jednotlivého partnera nie sú zameniteľné a úprava tej nesprávnej premrhá zvyšok prechádzky.
Keď pole máte, vypíšte rozsahy, ktoré už existujú: kancelársku LAN, každú routovanú lokalitu, cloudovú VPC a akýkoľvek iný fond, ktorý je ešte v prevádzke. Prekryv rozhoduje aritmetika prefixu, nie to, či čísla hostiteľov vyzerajú povedome, preto porovnajte agregát s každým z týchto rozsahov. Dva rozsahy, ktoré oba vyzerajú ako 10.x, sú neškodné, keď sa ich agregáty nepretínajú, a incident podpory, keď sa pretínajú.
Potom rozhodnite, či je adresa funkciou toho, kto sa pripája, alebo toho, kedy sa pripája. Dynamické prideľovanie vydáva to, čo je voľné, zatiaľ čo prideľovanie podľa identity viaže pevnú adresu na prihlasovacie údaje. Voľbu zapíšte, pretože mení, ako má neskôr vyzerať opätovné pripojenie.
Prečítajte adresu, ktorú klient skutočne dostal
Pripojte jedného klienta a čítajte, čo hlási tunel, nie čo fond sľuboval. Klient zobrazuje svoju vnútornú adresu v stave pripojenia a v Linuxe ju rozhranie nesie priamo.
Porovnajte túto adresu s rozsahom, ktorý ste uložili. Ak leží mimo rozsahu, pozeráte sa na inú cestu pridelenia, než ktorú ste upravovali. Skontrolujte aj dĺžku prefixu, pretože klient s /32 nemá žiadneho partnera na linke a posiela každé cieľové umiestnenie cez svoju predvolenú trasu.
ip -4 addr show tun0
ip route get 192.168.50.20
Klient, ktorý sa pripája z domáceho routera s tým istým rozsahom, sa pripojí a potom nedosiahne takmer nič. Klient si pre tento prefix ponecháva svoju lokálnu trasu, takže adresa tunela koliduje so sieťou za ním a prevádzka vychádza cez nesprávne rozhranie. Tento prípad sa na serveri nedá opraviť; dokumentovanou nápravou je prečíslovanie domácej siete alebo voľba rozsahu fondu dostatočne vzdialeného, aby kolízie zostali zriedkavé. Zaznamenajte poruchu aj nápravu, pretože helpdesk sa s ňou stretne znova.
Pripojte toho istého klienta znova a sledujte adresu. Dynamický fond môže vrátiť rovnakú hodnotu alebo inú a obe sú správne, zatiaľ čo fond podľa identity, ktorý adresu mení, viazanosť nedodržiava. Tá kontrola trvá sekundy a rozhodne, či režim, ktorý ste zaznamenali v prvej časti, je režim v platnosti.
Sledujte odpoveď späť od služby
Fond funguje len vtedy, keď sa odpovede môžu vrátiť späť k nemu. Služba v LAN odpovedá na vnútornú adresu, takže jej brána potrebuje trasu pre fond alebo preklad pred službou. Keď požiadavka príde tunelom a odpoveď odíde inou cestou, stavový firewall alebo kontrola spätnej cesty ju zahodí a klient vidí službu, ktorá sa pripojí a potom visí. Zaradťe fond do návrhu smerovania ako jeden sumarizovateľný blok namiesto pridávania trás pre každého hostiteľa.
Preklad mení to, čo vidí zvyšok systému. Keď sa zdroj prepíše, adresa vo firewalle hostiteľa a v protokole aplikácie je preložená, takže pravidlo napísané proti adrese fondu nezodpovedá ničomu a riadok protokolu sa nedá dohľadať ku klientovi. Dokumentácia strongSwan k presmerovaniu pokrýva serverovú polovicu tejto cesty pre bránu IKEv2. DNS nesie to isté obmedzenie, pretože meno, ktoré sa preloží na adresu, ktorú klient nedosiahne, zlyhá neskôr a inde.
Dvaja klienti, potom jedno odvolanie
Pripojte dvoch klientov súčasne a prečítajte obe adresy. Musia byť odlišné, použiteľné a vo vnútri fondu a každý musí dosiahnuť službu, pre ktorú je určený. Fond, ktorý vydáva duplicitné adresy, sa zvyčajne prejaví tu, nie v prvom teste s jedným klientom.
Odvolajte jedny prihlasovacie údaje, kým druhý klient zostáva pripojený, a potom vyskúšajte službu z preživšieho klienta. Odvolanie, ktoré narúša druhú reláciu, ukazuje na zdieľaný stav, najčastejšie jedny prihlasovacie údaje alebo jednu adresu znova použitú medzi zariadeniami. Pripojte odvolaného klienta znova a potvrďte, že je odmietnutý, namiesto toho, aby dostal uvoľnenú adresu.
Skončite cieľom, ktorý by mal byť zamietnutý. Klient, ktorý dosiahne všetko, bol pripojený, nie otestovaný.
Zapíšte tie štyri hodnoty tam, kde ich nájde ďalšia zmena
Záznam je krátky: rozsah a prefix fondu, režim prideľovania, spätná cesta alebo preklad v použití a rozsah DNS, ktorý pre tieto ciele odpovedá. Umiestnite ho vedľa konfigurácie servera, nie do tiketu, a opatrite dátumom. Každý, kto neskôr zmení jednu zo štyroch, potrebuje ostatné tri pred sebou, pretože zmena veľkosti fondu rozbije trasu a zmena trasy rozbije odpoveď DNS.
Ponechajte pri ňom poznámku o vlastníctve: rozsah tunela patrí serveru VPN a rezervácia vytvorená v rozsahu DHCP v LAN nič nerezervuje pre klienta vnútri tunela. Ten jediný riadok bráni najčastejšiemu prepracovaniu, keď niekto pridá rezerváciu a očakáva, že adresa tunela ju bude nasledovať.