Ugyanaz az alhálózat mindkét végén: képezze le a távoli LAN-t egy szabad tartományra

Az otthon és az iroda is 192.168.1.0/24-et használ, így a 192.168.1.1 címre küldött kérésnek két lehetséges válasza van, és az ügyfél kérdezés nélkül választ egyet. Egy működő irodai hálózat újraszámozása ritkán népszerű, és az útválasztó címei gyakran be vannak égetve a nyomtatókba, kamerákba és dokumentációkba. Az ügyféloldali címleképezés ehelyett egy szabad tartomány alatt jelenítheti meg a távoli hálózatot, és a gazdagép rész azonos maradhat, így a 192.168.1.20 10.203.41.20-ként jelenik meg. A bökkenő, hogy csak néhány ügyfél valósítja meg, és semmit nem tesz a visszaútért.

Két nézet ugyanarról a gazdagépről

A leképezés megtartja a gazdagép részt, és csak a hálózati részt változtatja meg. Ugyanaz a gép ezután két címen válaszol attól függően, hol áll. Mindkét oszlop felírása bármilyen beállítás előtt megakadályozza a naplók és tűzfalszabályok későbbi félreértelmezését.

Az otthoni helyi eszközök megtartják saját 192.168.1.x címeiket, és éppen ez a gyakorlat lényege. A szomszédos szobában lévő nyomtató elérhető marad, miközben az iroda olyan tartomány alatt jelenik meg, amely nem ütközik.

Az argumentumok sorrendje az egész trükk

Az opció irányt, hálózatot és maszkot, valamint aliast vesz fel: az első hálózat az, amit az ügyfél lát, az alias az, amit a kiszolgáló lát. A távoli átjáró mögött élő erőforrások esetében az irány a cél formája. A két hálózat megfordítása, mert az utolsó argumentumot aliasnak hívják, az a hiba, amely olyan alagutat hoz létre, amely csatlakozik és semmit nem képez le.

push "route 10.203.41.0 255.255.255.0"
push "client-nat dnat 10.203.41.0 255.255.255.0 192.168.1.0"

Az útvonal az, ami az ügyfél csomagjait az új tartományhoz az alagútba küldi; a fordítás menet közben átírja a célt. A 192.168.1.20-ról érkező válasz visszaíródik 10.203.41.20-ra, hogy az ügyfélen lévő socket konzisztens maradjon. Egyetlen gazdagép ugyanígy működik teljes hosszúságú maszkkal, amíg az útvonal és a leképezés ugyanazt a címet írja le.

Ez címleképezés, nem portleképezés. Két szolgáltatás egy gazdagépen nem választható szét vele, és a protokoll, amely IP-címeket ágyaz be a hasznos terhelésébe, továbbra is a valódiakat fogja látni.

A leképezés nem hoz létre visszautat

A fordítás az ügyfélnél történik, így a kiszolgálónak továbbra is az alagútba kell irányítania a válaszokat, és a tűzfalának továbbra is engedélyeznie kell azokat. Ha a távoli átjáró nem tudja, hogyan érje el az alagút alhálózatát, a kérés megérkezik és a válasz a rossz ajtón távozik; a leképezés csak azt éri el, hogy a hiba ügyfélproblémának tűnjön.

A kiszolgálóoldali szabályoknak azokat a címeket kell leírniuk, amelyek a fordítás után a kiszolgálón léteznek, nem az ügyfél számára látható tartományt. Az alias átmásolása egy engedélyezési szabályba egy délutánt pazarol el, mert egyetlen csomag sem hordozza azt azon az oldalon.

Válasszon olyan aliastartományt, amely nem ütközik semmi mással, amit az ügyfél irányít: egy másik VPN, egy konténerhálózat, egy második iroda. Az ütközés itt az eredeti kétértelműséget hozza vissza egy másik szám alatt, és nehezebb észrevenni, mert a címek ismeretlennek tűnnek.

A nevek és a hasznos terhelések túlélik a fordítást

Egy gazdagépnév, amely a valódi 192.168.1.20-ra oldódik fel, a böngészőt a helyi eszközhöz küldi a távoli helyett, bármit is mond az útválasztási tábla. A privát DNS válaszának az ügyfél számára látható tartományra kell mutatnia, miközben a TLS-tanúsítvány továbbra is azt a nevet hordozza, amelyet az alkalmazás elvár. A névvel teszteljen, ne a címmel, mert a cím működhet, miközben a név csendben rossz irányba oldódik fel. Amikor a távoli átjáró is kiszolgálja azt a zónát, a saját rekordjainak is szükségük van az ügyfél számára látható tartományra.

Az átirányítások, a beágyazott URL-ek és azok az alkalmazások, amelyek saját címüket adják ki egy hasznos terhelésben, olyan módokon törhetnek el, amelyeket semmilyen csomagleképezés nem tud megjavítani. Kezelje ezeket alkalmazásproblémaként, és ennek megfelelően mérje fel a ráfordítást, mielőtt megígéri, hogy az újraszámozás nem szükséges.

Három ellenőrzés az elköteleződés előtt

Először erősítse meg az ügyfél megvalósítását. A Community OpenVPN támogatja ezt az opciót; az OpenVPN 3 kódbázisa a nem támogatott funkciók között sorolja fel, így a Connect stílusú ügyfélnek küldött profil egyszerűen figyelmen kívül hagyhatja. Az elfogadott és soha nem alkalmazott direktíva rosszabb a hibánál, mert az alagút egészségesnek látszik.

Másodszor ellenőrizze külön az útvonalat és a fordítást egy rövid diagnosztikai ablakkal magas részletességnél, majd tesztelje a tényleges szolgáltatást ping helyett. Harmadszor erősítse meg, hogy a helyi útválasztó és a távoli erőforrás megkülönböztethető marad az ügyféltől, mert ez volt az eredeti cél.

Ha az ügyfél nem tudja elvégezni a fordítást, kérjen segítséget az átjáró oldalától, vagy fogadja el az újraszámozást. További útvonalak hozzáadása ugyanahhoz a címhez nem tervezés.