Hoe't jo in adrespul foar VPN-klanten planne dy't past
Kies de pul yn it serversfjild, lês dan it adres dat in klant echt krijt, folgje it antwurd werom, en skriuw berik, modus, rûte en DNS-omfang op.
Begjin yn it pulsfjild op 'e VPN-server, net yn in rekkenblêd. Wat jo dêr ynfiere, wurdt de ynterne adresromte foar elke klant dy't dêrnei ferbynt, en it moat gearwêze kinne mei it LAN dat dy klanten berikke, de rûtearre lokaasjes dêrefter en elk adres dat de klant thús al hat. Ferbyn ien klant sa gau't de pul bewarre is, want dy earste ferbining fertelt jo oft de wearde yn 'e praktyk wurket. Fan dêrút beweecht de rûnlieding nei bûten: it adres dat de klant krige, it paad dat in antwurd nimt, en de notysje dy't jo efterlitte.
Begjin by it pulsfjild, foar't ien klant ferbynt
Elk produkt toant dit oars, dus fyn it objekt dat echt adressen tawijst. OpenVPN hat in pulsfjild op 'e serverside dat it folgjende frije adres útdielt, in IKEv2-gateway hat in pulseksje bûn oan 'e peer-konfiguraasje, en WireGuard hat gjin fan beide, want elke peer draacht syn eigen adres yn syn konfiguraasjebestân. In puldirektive en in adres per peer binne net útwikselber, en it ferkearde bewurkje fergriemt de rest fan 'e rûnlieding.
As jo it fjild hawwe, listje dan de berikken op dy't al besteane: it kantoar-LAN, elk rûtearre lokaasje, de cloud-VPC en elke oare pul dy't noch yn tsjinst is. Oerlap wurdt besletten troch prefiks-aritmetika, net troch oft de hostnûmers fertroud lykje, dus fergelykje it aggregaat mei elk fan dy berikken. Twa berikken dy't beide as 10.x lykje binne ûnskeadlik as har aggregaten elkoar net snije en in stipe-ynsidint as se dat wol dogge.
Beslis dan oft it adres in funksje is fan wa't ferbynt of fan wannear't se ferbine. Dynamyske tawizing jout wat frij is, wylst tawizing per identiteit in fêst adres oan in bewiis bûn hâldt. Skriuw de kar op, want it feroaret hoe't in werferbining letter derút moat sjen.
Lês it adres dat de klant echt krige
Ferbyn ien klant en lês wat de tunnel rapportearret, net wat de pul beloofde. De klant toant syn ynterne adres yn 'e ferbiningsstatus, en op Linux draacht de ynterface it direkt.
Fergelykje dat adres mei it berik dat jo bewarre hawwe. As it bûten it berik leit, sjogge jo in oar tawizingspaad as dat jo bewurke hawwe. Kontrolearje ek de prefikslange, want in klant mei in /32 hat gjin peer op 'e keppeling en stjoert elke bestimming fia syn standertrûte.
ip -4 addr show tun0
ip route get 192.168.50.20
In klant dy't ferbynt fan in thúsrouter mei itselde berik sil ferbine en dan hast neat berikke. De klant hâldt syn lokale rûte foar dat prefiks, sadat it tunneladres botset mei it netwurk dêrefter en ferkear fia de ferkearde ynterface fuortgiet. Dat gefal kin net op 'e server reparearre wurde; it dokumintearre middel is it thúsnetwurk op 'e nij te nûmerjen of in pulsberik te kiezen dat fier genôch is om botsingen seldsum te hâlden. Skriuw sawol de flater as it middel op, want de helpdesk sil it wer treffe.
Ferbyn deselde klant op 'e nij en hâld it adres yn 'e gaten. In dynamyske pul kin deselde wearde of in oare weromjaan en beide binne goed, wylst in pul per identiteit dy't it adres feroaret de bining net earet. Dy kontrôle duorret sekonden en beslist oft de modus dy't jo yn 'e earste seksje opskreaun hawwe de modus is dy't jildt.
Folgje in antwurd werom fan 'e tsjinst
De pul wurket allinnich as antwurden werom reizgje kinne. In tsjinst op it LAN antwurdet op it ynterne adres, dus syn gateway hat in rûte foar de pul nedich of in oersetting foar de tsjinst. As in fersyk fia de tunnel oankomt en it antwurd fia in oar paad fuortgiet, smyt in steatbefette firewall of in omkearde-paadkontrôle it fuort, en de klant sjocht in tsjinst dy't ferbynt en dan hinget. Set de pul yn it rûte-ûntwerp as ien gearfetsbere blok yn stee fan rûtes per host ta te foegjen.
Oersetting feroaret wat de rest fan it systeem sjocht. As de boarne oerskreaun wurdt, is it adres yn 'e host-firewall en yn it applikaasjelog it oersette, sadat in regel skreaun tsjin it puladres neat treft en in logrigel net werom te folgjen is nei in klant. De strongSwan-dokumintaasje oer trochstjoeren beslacht de serverside-helte fan dat paad foar in IKEv2-gateway. DNS draacht deselde beheining, want in namme dy't oplost nei in adres dat de klant net berikke kin, mislearret letter en earne oars.
Twa klanten, dan ien yntrekking
Ferbyn twa klanten tagelyk en lês beide adressen. Se moatte ferskille, brûkber wêze en binnen de pul lizze, en elk moat de tsjinst berikke dêr't it foar bedoeld is. In pul dy't dûbele adressen útdielt, lit him meastal hjir sjen en net yn 'e earste test mei ien klant.
Lûk ien bewiis yn wylst de oare klant ferbûn bliuwt, en probearje dan de tsjinst fan 'e oerlibjende klant. In yntrekking dy't de oare sesje fersteurt, wiist op dielde steat, meastal ien bewiis of ien adres dat oer apparaten hinne werbrûkt wurdt. Ferbyn de ynlutsen klant op 'e nij en befêstigje dat er wegere wurdt yn stee fan it frijjûne adres te krijen.
Einigje mei in bestimming dy't wegere wurde moat. In klant dy't alles berikt, is ferbûn, net test.
Skriuw de fjouwer wearden dêr't de folgjende feroaring se fine sil
De notysje is koart: it pulsberik en it prefiks, de tawizingsmodus, it werompaad of de oersetting yn gebrûk, en it DNS-omfang dat foar dy bestimmingen antwurdet. Set it njonken de serverkonfiguraasje yn stee fan yn in ticket, en datearje it. Elkenien dy't letter ien fan 'e fjouwer feroaret, hat de oare trije foar him nedich, want in gruttere of lytsere pul brekt de rûte en in rûteferoaring brekt it DNS-antwurd.
Hâld de eigendomsnotysje derby: it tunnelberik heart by de VPN-server, en in reservearring makke yn it LAN-DHCP-berik reservearret neat foar in klant yn 'e tunnel. Dy iene rigel foarkomt it meast foarkommende op 'e nij dwaan, wêrby't immen in reservearring tafoeget en ferwachtet dat it tunneladres dêrnei folget.